8

I'm having some intermittent issues that appear to be related to the oomkiller purging some child processes, but I can't see why.

Is there a convenient way that I can suppress all oomkiller activity through sysctl?

I've found some instructions that say these should work, but they do not exist for me.

sysctl -w memory.oom_control=1
sysctl -w vm.oom-kill=0

I have also seen these two being suggested, but the oom killer carries right on.

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_kbytes=0
3
  • 2
    Completely disabling memory overcommit on Linux can have some unexpected side effects as poorly-coded applications may just assume that memory overcommit will always be available so they'll obtain massively excessive amounts of anonymous virtual memory from the kernel. With memory overcommit disabled, those massive requests for anonymous virtual memory will require dedicated swap space. With memory overcommit disabled, for example, a malloc() call for 10 GB won't succeed unless there's 10 GB of free swap space available, which will then be reserved even if that 10 GB is never used. Nov 18, 2019 at 10:31
  • 1
    and in that is the brain deadness - if the app is bad, then complain to the developer(s), not try and make them work and thus breaking systems - being an Infrastructure operator, it's pains me everytime this happens as it's always the process/application that is crucial that got badly killed ;(
    – Hvisage
    Nov 21, 2021 at 9:29
  • The problem is, Chrome and Edge browsers require memory overcommit to work. It is just not possible for a modern system to work without at least one of these browsers, and complaining to Google will result in being ignored. I learned this the hard way.
    – Nicolay77
    Mar 25 at 8:06

2 Answers 2

5

You could use /proc/sys/vm/overcommit_memory (see proc(5)), e.g.

echo 2 > /proc/sys/vm/overcommit_memory

as root to disable it. See also the kernel's Documentation/vm/overcommit-accounting

(If you are running an old kernel, consider upgrading it)

1
  • 3
    Shouldn't that be echo 2 > /proc/sys/vm/overcommit_memory? The linked documentation states 2 - Don't overcommit. Nov 18, 2019 at 10:26
2

Although this question is rather old, it came up when I was doing some reading today.....

sysctl -w memory.oom_control=1

You almost NEVER want to do this. Out of the box, most Linux distributions default to a setting of '0' meaning the kernel guesses how much to overcommit memory. '1' means it will always overcommit. If you are getting OOM errors on a (near) homeostatic machine, you should be using a value of 2. This does not disable overcommit! it merely sets a limit on ho much memory the kernel will promise to programs. That limit is determined by overcommit_ratio or overcommit_kbytes. Unfortunately the this document does not indicate how conflicting values in each of these are resolved. But if you look at this...

Setting one disables the other (which then appears as 0 when read).

What the right value for the overcommit ratio is depends on how the machine is used. The default (RAM + SWAP * 1.5 = 50) might make sense for a desktop machine but is rather high IME for a server. Having a server in swap is usually a bad thing.

Hence the short version is:

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=20

...and try lower values for the ratio if you are still seeing OOM killer.

1
  • How does setting memory.oom_control affect overcommit? Or did you just mis-read the line you quoted? May 10, 2023 at 16:33

You must log in to answer this question.

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