I.e. is it more or less aggressive depending on what the OS tells it about available memory? Or does it do the same things regardless of the memory pressure. I’m asking because I’m not sure how to communicate that memory pressure in a containerized environment-- or if there is even a need to do so.
(Asking in the context of some OOMs I’m experiencing and trying to figure out how to respond-- increase memory limits, call GC.gc() manually more, or something else).
Related post: Memory consumption growth with many large MILP's in JuMP
To add a few details to my question: (cross-posted from #helpdesk on Slack):
in this case I can just bump the memory limit on my kuberbetes pod, but my question is more about the semantics of how Julia’s GC works with regards to memory pressure. E.g. if I set a memory limit of 16 Gb in kubernetes, it will kill the pod if it exceeds 16 Gb of memory used. But the processes run in a node that might have 60 Gb of memory-- and Sys.free_memory() will show plenty of free memory.
So my question is basically: is that a problem. I.e. if Julia’s GC works based on available memory, it might say: hey, there’s plenty of free memory, no need to waste time on a GC run now. But actually there’s this hidden limit of X amount and it will get killed if it exceeds it-- and raising the memory limit isn’t helping much bc maybe Julia will just GC even less.
If Julia’s GC is agnostic to what the system says, then the lack of communicating memory pressure to Julia is not the problem, and I need to either get GC to run more often or make less garbage or increase the memory limit etc.
It scales the GC rate with the available memory, yes. I think people who have studied memory allocators usually suggest a maximum ratio of about 1:5 for expected maximum memory to maximum physical memory. Beyond that, it starts to taking exponentially longer to allocate and free memory.
There is an open issue to improve uv_get_constrained_memory to support cgroup2, such that it works better on containerized systems.