You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
Y
What operating system and processor architecture are you using?
amd64
I'm trying to run a service that allocates lots of memory per request in Kubernetes pod w/ limited memory on a machine with lots of memory available - and service grows RES mem under load until it is killed due OOM. Service does not leak memory - running same binary with same load on a real machine with physical RAM of the same size yields stable RES mem graph.
It seems that memory allocator (or GC?) do not respect cgroups memory limits when deciding if GC should be ran aggressively and/or if unused res mem pages should be released.
The text was updated successfully, but these errors were encountered:
@ALTree: yup, I saw those two. ulimit works independently of cgroups I believe, didn't check yet if cgroups are covered by #16843. Feel free to close the issue if it is.
The current Go memory allocator does not respect any sort of memory limits at all. The current work on #16843 assumes that the user is going to explicitly tell the runtime package approximately how memory to allocate, with the understanding that the runtime may overshoot that number. Any attempt to set that limit automatically based on ulimit or whatever is going to be a later and longer discussion.
I don't think there is any purpose to be served by keeping this issue open at this time, so I am going to close it.
What version of Go are you using (
go version
)?1.9
Does this issue reproduce with the latest release?
Y
What operating system and processor architecture are you using?
amd64
I'm trying to run a service that allocates lots of memory per request in Kubernetes pod w/ limited memory on a machine with lots of memory available - and service grows RES mem under load until it is killed due OOM. Service does not leak memory - running same binary with same load on a real machine with physical RAM of the same size yields stable RES mem graph.
It seems that memory allocator (or GC?) do not respect cgroups memory limits when deciding if GC should be ran aggressively and/or if unused res mem pages should be released.
The text was updated successfully, but these errors were encountered: