4

I don't have any swap partition/file on my machine, and only 2GB of RAM.

Sometimes it happens that the memory gets saturated by some process (Xorg+browser+compiler+...) and the system hangs indefinitely, and the only way to restart it (other than hard reset) is with SysRq.

I understood that the Out Of Memory Killer won't help me because when the memory is completely full, kernel cannot allocate the OOM Killer itself.

Is there any way to preload the OOM Killer, so that it can actually work when memory is completely full?
Or is it possible to tweak the kernel so that OOM Killer gets activated when my ram is full at ${TOTAL_RAM} - 10MB?

Community
  • 1
peoro
  • 3,778
  • You should configure a swap partition or swap file. It won't get used unless necessary, and when it is necessary, it will give you more breathing room for recovery. – mattdm Feb 08 '11 at 15:54
  • You may also want to consider running the web browser (usually the main culprit, right?) under a ulimit constraining it to a reasonable fraction of your RAM. – mattdm Feb 08 '11 at 15:54
  • @mattdm: yes, I should, but when I set up this system (3 years ago or so) I thought 2GB of memory were enough (and they were, at the time), and now I prefer avoid to change my partition table. The idea of limiting browser max memory is good, I'll do that. – peoro Feb 08 '11 at 16:12
  • 1
    You don't need to change your partition table — you can create a file with dd, run mkswap on it, and just use that. There isn't a significant performance penalty for doing so (and anyway any such penalty would be lost under the weight of "they both are terribly slow"). – mattdm Feb 08 '11 at 16:24

4 Answers4

7

I'm fairly sure that the kernel reserves some memory for itself, i.e. for launching the oom_killer.

(What use would a oom_killer be if it fails to load due to lack of memory?)

chris
  • 1,142
  • hum, somebody on IRC a few days ago told me the problem could be that OOM Killer could have not enough memory to start up. If this is not the case why ain't I getting the browser (or something else) killed when my system memory is full? The system just slow down like if I had run a forkbomb (even the mouse pointer takes seconds just to move). – peoro Feb 08 '11 at 14:39
  • 2
    The oom killer just tries to guess who's responsible for being out of memory. You could set the browsers oomadj value to make sure it gets killed by the oom (/proc//oomadj). – chris Feb 08 '11 at 14:49
  • well, nothing gets killed, not even the wrong process, at the moment (or at least that's what it seems to happen. I should use oom_adj, but that's no so easy (don't want to do that by hand any time I start my browser, should write a wrapper that runs the browser and set that parameter), especially if the browser uses many processes (chromium)... Maybe I should open a new question asking how to do that. – peoro Feb 08 '11 at 16:16
6

The kernel does allocate a minimal amount of free space for itself. You can see this value with:

$ sysctl vm.min_free_kbytes
vm.min_free_kbytes = 2842

$ cat /proc/sys/vm/min_free_kbytes
vm.min_free_kbytes = 2842

This value depends on the amount of RAM (512MB in the case above), you can try to increase it, but I don't think this will solve your problem (further will it increase the chance of getting OOM'd sooner).

The OOM killer should have enough free memory to kill applications, else it would miss the purpose of having one (like chris already pointed out).

Edit: Just as a side-note, I don't think it's the best way to solve a problem concerning user-space programs, just by modifying kernel parameters (OOM values). The kernel has best knowledge on what's going on and how to handle certain situations. Rather than playing with those values, try to fix the memory problems the user-space programs (Xorg, browser) generate. Also, see the comment on the mm/oom_kill.c source file, not even the kernel developers think that the OOM killer should have a lot of work to do in a well configured environment.

wag
  • 35,944
  • 12
  • 67
  • 51
  • Thanks, I'll try to play raise min_free_kbytes (although it's already set to 3798 on my system). I commended to chris answer about why I was thinking kernel cannot find enough memory to load the OOM Killer. – peoro Feb 08 '11 at 14:41
2

One way to avoid this would be to turn off the heuristic overcommit handling and set it to not overcommit: set the sysctl vm.overcommit_memory=2, and then lower vm.overcommit_ratio. Read up on this in the kernel docs.

You can also target specific PIDs for preferential treatment by the OOM by modifying /proc/$PID/oom_adj.

jsbillings
  • 24,406
  • 1
    Thanks. I already tried to change the overcommit variables a couple of days ago, but that didn't work well: it killed my most memory-hunger applications when a big portion of my memory was still free (by a big portion I mean like 50%). I think that's because some applications (say Firefox) allocate a lot more memory than what they actually use. – peoro Feb 08 '11 at 14:48
  • @peoro if you're willing to test suitable overcommit_ratio value, you can adjust the system to allow all RAM to be used for real for your programs. The problem is that will require setting ratio over 100 and you're no longer quaranteed to never run out of memory. The only real fix would be to fix all user mode programs to allocate only as much memory as needed and then run with overcommit_memory = 2. – Mikko Rantalainen Dec 17 '17 at 17:13
0

the system hangs indefinitely

If you want to know why it hangs see the answer to a similar question.

If you want to prevent it from hanging and just trigger OOM-killer almost instantly when it's needed, you could try the clumsy kernel patch from the EDIT section of this question (note: it requires recompiling kernel).