HotSpot has a handy command line option for this issue: `-XX:+AlwaysPreTouch`, which forces the OS to actually assign memory and thus increases the likelihood to expose such issues.
> The truth is that if you're having issues with default overcommit configuration your application probably sucks and you have to actually diagnose it and fix it.
An alternative interpretation of the issue would be that if your OS allows a single process to overcommit more than the sum of total RAM+SWAP on the system, then maybe it is it who sucks.
It is a hen and egg situation. The OS has to do this because many applications have learned to rely on the behaviour and will pre-allocate huge amounts of memory that they never use. Linux practically forces applications into this because the only way to start a new process is to fork yourself which will instantly double virtual memory usage for no reason. There's also the problem that a lack of overcommit tends to lead to underutilization. I'm eagerly waiting for the day that I no longer have to size my workloads manually on kubernetes.
Re:Linux Memory Overcommit (2007)
by heavenlyblue on Monday August 19, 2024 @03:41PM
(#41294001)
How is forking related to overcommit?
When you fork then a complete copy of the parent process is created, including all its memory. This memory is not actually copied until it is changed, but it still doubles the virtual memory usage. So without overcommit, even starting bash through a fork would immediately cause an OOM if your process uses more than 50% of physical memory.
Re:Linux Memory Overcommit (2007)
by heavenlyblue on Tuesday August 20, 2024 @08:25AM
(#41299411)
That's an incorrect assumption though. Overcommit is for pages that have not been accessed yet, however when forking a valid use case is to share pre-loaded, mostly read-only memory between processes.
Re:Linux Memory Overcommit (2007)
by matheusmoreira on Tuesday August 20, 2024 @05:29AM
(#41298346)
> the only way to start a new process is to fork yoursel
Not at all. Linux supports the clone system call which allows applications complete control over this. Linux user space chooses not to take advantage of it.
"We run a pretty java-heavy environment, with multiple large JVMs configured per host. The problem is that the heap sizes have been getting larger, and we were running in an overcommitted situation and did not realize it. The JVMs would all start up and malloc() their large heaps, and then at some later time once enough of the heaps were actually used, the OOM killer would kick in and more or less randomly off one of our JVMs."
I know that 2007 may have been different times, but I'd argue that max heaps for all your JVMs running on a system probably shouldn't exceed around 88% of the total system memory. (percentage goes up as the total system memory goes up from 128GB -> 256GB -> 512GB)