I do not want my computer to swap data to disk. I have no swap partition:

$ free
             total       used       free     shared    buffers     cached
Mem:       3841912    3670012     171900          0      74980     699652
-/+ buffers/cache:    2895380     946532
Swap:            0          0          0

Back in the day (maybe as recently as kernel 2.4?) this used to work. Memory-hungry processes would be killed by the oom killer and I would restart them. But now (Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64) google-chrome (13.0.782.24 beta) regularly sends my machine into a death-spiral of swapping. Or at least something that feels like swapping: X windows take forever to update, disk drive whirs, gnome panel memory chart hits the ceiling, and I see this message in the syslog:

rtkit-daemon[1771]: The canary thread is apparently starving. Taking action.
rtkit-daemon[1771]: Demoting known real-time threads.

But, according to syslog, the kernel does not run the oom killer. For good measure, I set swappiness to 0:

$ cat /proc/sys/vm/swappiness

My workaround is to use ctrl-alt-sysrq-f when this starts to happen. Anyone have a recipe for configuring Linux to run oom_kill on its own, in this situation?

  • 1
    Are you sure that the OOM Killer is actually not running? It's certainly possible that Chrome dodges the OOM killer. Run the second program here to see if the OOM killer is working or not. – new123456 Jun 18 '11 at 2:33
  • I am sure the OOM Killer is not running as soon as I would like it to. The only time I see "invoked oom-killer" in syslog is when I invoke it manually -- after more than a minute of swapping. – Joe Jun 18 '11 at 16:46
  • Update: I'm on kernel 3.0.0 (and new hardware) and the problem remains. I have to be proactive about killing google-chrome, because once it gets deep into the death-spiral, even the magic sysrq key fails to revive the system. – Joe Sep 23 '11 at 7:31
  • What I don't understand about this question is: If you had no swap space configured, how were you swapping? – Michael Hampton Jul 28 '12 at 20:32
  • Well, as mentioned in the question, it felt like swapping in that the machine would slow way down and it would be hard to get apps to respond but they would, eventually. It may have really been the kernel waiting for chrome to release memory or something. – Joe Jul 29 '12 at 23:16

OOM doesn't necessarily kill the process you think it will. Read about it here: http://lwn.net/Articles/317814/

I suspect what is happening is that because chrome uses a different process for each page, it's confusing the OOM-killer's heuristics and other processes are being killed rather than the parent chrome process.

According to this, the OOM-killer likes to kill niced processes. So try setting chrome to a niceness of greater than 0.. might make it more of a target :-)

  • I think your suspicion about chrome is on the right track. It seems to operate in a way that confuses the OOM-killer's heuristics. The first program on the page new123456 links to confuses my kernel in the same way: It allocates lots of memory and makes the system unresponsive, but the OOM killer doesn't kill it (at least not within a minute or so). – Joe Jun 27 '11 at 0:50

I have come to the conclusion that modern linux doesn't like to run without virtual memory. Maybe getting rid of swap made sense in the days of slow hard drives / older VM algorithms / etc. Or maybe you could jump through some hoops to configure the oom killer...

But I've been running with a swap file for the past few months and I'm much happier with my machine's low-memory behavior. It slows down a bit at the limits, but it's easy to intervene and kill memory-hungry processes to get things back on track.

  • But how does the system behave when it's low on memory? – Aaron Franke Jun 5 '19 at 10:04

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.