I had problem with a process spawning very many threads due to a bug, eating up memory, causing heavy swapping to the swap partition. Thus, I switched off swap – which is recommended in server clusters anyway – to let the buggy program fail early. To my surprise, this didn't improve things at all! Similarly, setting vm.swappiness to 0 didn't help. iotop revealed heavy reading from disk (almost no writing).

I suspect that the Linux kernel is still swapping code pages in memory, and re-reads overwritten code pages from disk when they are needed. When RAM is very low, this happens very frequently, causing thrashing, making the computer almost unresponsive.

How can one prevent this unfortunate and potentially dangerous situation? I tried switching off swap, cgroups for memory and CPU constraints for that process, and ulimit for max. 30 processes. Nothing even improved the situation. (Well, this is not entirely true: a RAM limit which left hundreds of MB permanently unused did help.)

In particular: Can I prevent swapping code segments in memory, and let the RAM-requesting process simply get a NULL for their next malloc?

1 Answer 1


How about tuning the memory overcommit accounting and setting it to option 2 (do not overcommit) instead of the default option 0 (heuristic overcommit)? The description for that states

Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as

The above snippet is from kernel documentation

The policy can be set with vm.overcommit tunable.

  • Setting overcommit to 2 made Chromium crash. This sounds odd, but this how it should be in my opinion. Mar 4, 2018 at 11:22
  • This sounded promising (my aim being to avoid crazy read IO when very low on memory - presumably due to filesystem cache repeatedly evicted) however in my case cat /proc/meminfo under normal usage showed Committed_AS > MemTotal so setting vm.overcommit_memory=2 even with vm.overcommit_ratio=99 immediately resulted in the system being overcommitted & refusing any more allocations, despite having >900MB free RAM (presumably due to allocated but unused memory). Is there a different way to avoid the IO cache thrash and prefer that OOM killer steps in sooner instead?
    – sparrowt
    Jun 6, 2023 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .