2

I am running Ubuntu 16.04.1 LTS, with a 4.4.0-36 kernel. I don't think that this matters a lot though, because I've seen terrible kernel behaviour across many distributions/kernel versions.

Consider the following starting point:

  • My system has let's say 4GB of memory and a swap partition of 4GB.
  • I am running a desktop environment with GNOME, a Browser and an IDE currently open.
  • I'm doing some programming, and in the course of that, I introduce a bug which causes my program to allocate an infinite amount of memory.

So far so good, this is a situation that I should recover from, right? Here's what I want to happen:

  1. My operating system realizes that the program that I wrote is rogue and not behaving correctly.
  2. It kills my program, possibly with a helpful debug or log message
  3. I am able to resume my activities

But this is not what happens with a more or less default install of Ubuntu. what happens is this:

  1. The buggy program is allowed to run "indefinitely"
  2. Eventually, when all the physical memory is exhausted, the system starts swapping.
  3. As the buggy program claims more and more memory, all the pages of my desktop programs are pushed out to the swap. My hard drive ist starting to make very very scary sounds
  4. My user-interface becomes completely unresponsive. Clicks are registered minutes after they happened, mouse movement is often ignored.
  5. Any access to the machine effectively grinds to a halt. This includes changing virtual terminals, logging in via virtual terminals and logging in via SSH.
  6. If I do manage to somehow kill the offending program, not everything is fine. Far from it.
  7. All of the user interface and system services are now swapped out, and start to get slowly swapped back in to the physical ram. My hard drive is still going crazy at this point.
  8. It takes about 0.5 - 1 hour for my system to "calm down".

Rebooting the machine without pushing the reset button also takes forever. Who would have thought that something simple as running out of memory causes such a cataclysmic event?

I have several questions:

  • Who thought that using swap on a desktop system would be a good idea and why??
  • Should I simply disable swap? What are the reasons not to?
  • Is there a better way than disabling swapping? For example, is there a way to limit the swapping to the rogue program and retain my system services and user interface in physical memory?
3
  • 1
    Since you're a programmer, you can suggest an actual kernel patch that would deal with such a case, but I honestly doubt that you'll be able to differentiate between a badly written program like yours and a program that simply requires lots of resources. Aug 30, 2016 at 14:51
  • @JuliePelletier I do not presume to know a better solution to OOM than dozens of smart kernel people. What I am asking for is a distinction between a program that requires lots of resources and the interfaces that let me control the system where it's running or. Or even more simply: I'm asking for my system to not be unusuable for hours during such an event.
    – fat-lobyte
    Aug 30, 2016 at 15:00
  • My point was that what you're asking is not possible. Disabling swap might certainly improve your situation, or at least get the system to crash faster. Aug 30, 2016 at 15:02

2 Answers 2

4

You can limit the swap, physical memory or both of them with cgroups. The more primitive way is to use ulimit, but nowadays cgroups are standard. (I won't copypaste the whole cgroups documentation) With cgroups you can also specify the cpu and disk i/o usage limit per program in a hierarchy, so you can set higher priority for your important tasks.

1
  • Thanks for the tips, cgroups in combination with systemd magic might be the cleanest and "best" solution. In my case, I think I will stick with turning off the swap.
    – fat-lobyte
    Sep 2, 2016 at 8:47
0

You might want to tweak your swappiness sysctl, and set it to 1 or 0 to avoid using the disk when memory is exhausted.

3
  • 1
    It seems that the swappiness does not effect behaviour when memory is exhausted, I just tested it with the stress program. It's necessary to turn off swap completely with swapoff -a.
    – fat-lobyte
    Sep 2, 2016 at 8:46
  • Setting swappiness to zero only keeps kernel waiting until Out of Memory (OOM) event would happen and it will then happily keep using swap. In practice I think it will be better to totally disable swap and trust OOM killer if you don't want to use swap. Feb 11, 2018 at 14:01
  • Basically setting swappiness to zero is only sensible if you want to use swap but your swap device wears considerably during use (e.g. most cheap SSD drives). Setting swappiness to high value is usually better because a copy of your RAM contents is written to swap and RAM can be freed faster if needed (because there's already extra copy in swap). This requires writing RAM contents to swap before swapping is actually needed and may never be needed for real. Feb 11, 2018 at 14:06

You must log in to answer this question.

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