up vote 3 down vote favorite
share [g+] share [fb]

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
0

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?

link|improve this question
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
feedback

1 Answer

up vote 2 down vote

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 :-)

link|improve this answer
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
feedback

Your Answer

 
or
required, but never shown
discard

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