0

Is there any way to prevent Linux from ever swapping out anything but rather go right to the OOM killer if it runs out of physical RAM?

Background

I have a Linux workstation that every once in a while runs out of RAM. When this happens, it becomes unrecoverable. (This is true regardless of if swap is enabled or not, I've seen it happen both ways.)

What I want to happen in that case is to have the OOM killer start killing processes and keep doing so until the system recovers or crashes (either, or anything in between, is preferable to an indefinite hang). Interestingly, even with swap disabled this doesn't happen but rather the system gives indications it's swapping (stuff works, just orders of magnitude more slowly).

My current theory is that Linux is still swapping out data that it considers to be backed by disk, e.g. readonly pages from executables and mmap'ed files.

Note: I've already spend some effort and exhausted multiple techniques for limiting memory usage. I can't do much if any more of that without hindering normal operation. I really am looking for a "kill them all, and let the user sort it out" solution.

0

I do not know if this works on all distributions of Linux.

Make a process less likely to get killed off. nnn = pid

echo -15 > /proc/nnn/oom_adj

We can make the OOM killer more likely to kill the nnn process by doing the following.

echo 10 > /proc/nnn/oom_adj

However.

This does not sound like a great solution to me. I would do something about limiting resources on processes long before considering this kind of thing. ulimit is there for exactly this reason. This does not invalidate your current approach if you've already done that. But it does answer the question, I guess. It would require you to:

monitor things and take action to enable kill off

take this kill approach a priori if you 'know' you can live without something. Which raises the question - why is that process running if you can live without it?

  • Regarding ulimit: 1) I end up running a few dozen processes that each normal use ~1% of RAM but need to on occasion use ~10%, just not all at the time time. 2) a significant fraction of the time the triggering process is "something random" and there are to many of them to find valid limits for. – BCS Nov 8 '14 at 16:39
  • I do this for a living - I find your approach to be kinda unorthodox. If you are (for example) running physics models for your own research -- This approach is cool. If this is some kind of production box, not cool. On production systems you have to find the root cause/process and remediate it, even if it means recoding/refactoring something. I have gone to isolating processes into their own virtual machine to watch them in isolation. – jim mcnamara Nov 8 '14 at 16:52
  • For my case, if it's on my workstation, it's by definition non-production. – BCS Nov 10 '14 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.