Oomer

... before you go any further: OOMER IS A WORK IN PROGRESS. It is not necessarily the best way to do things, and I expect it to be buggy and probably somewhat annoying at the moment. On the other hand, ooms are very very annoying, which IMO justifies releasing it in its current state.

Download oomer 0.1 (March 21st, 2010)

Unfortunately, on a 64-bit machine, running several large applications simultaneously all-too-often causes the system to slow to a crawl as multiple web browsers compete to see who has the better implementation of the CSS use-all-system-memory-and-then-some property and the user attempts to get enough of an xterm to swap back in that they can killall firefox-bin before the oomkiller destroys something they actually want.

Oomer checks periodically to see if available memory* has fallen below a user-defined threshhold, and, if so, kills or freezes user-defined target processes with user-defined signals, thus keeping your system nice and responsive while you go and free up some memory. The default target list (obviously, you may want to change it) is:

Memory  signal  process
<512M   KILL    gtk-gnash
<400M   STOP    firefox-bin
<384M   STOP    konqueror
<256M   STOP    gimp

Xoomer (included with oomer) is a GUI app that starts oomer and displays a little popup announcement whenever oomer kills something, as it would be rather annoying to have my web browser just freeze with no explanation.

Oomer keeps track of processes it kills and refuses to send the same signal to the same pid more than once every thirty seconds (by default), so if you want to, you can killall -CONT konqueror and have time to bookmark a page or two before quitting it. Oomer will stop sending kill signals once available memory rises above the threshhold for a given process; however, oomer will not automatically unpause processes that it's paused.

* 'Available memory', from oomer's perspective, is free memory + memory in buffers + cached memory. My system doesn't need much actually FREE memory; it DOES need a reasonable amount of space for buffers+cache if I want reasonable performance.

Oomer is only really useful if your problem is reigning in a few bloated applications that misbehave relatively predictably. Any malicious app wanting to hog memory can get around oomer by renaming itself to something innocuous.

CONFIGURATION:

At the moment, configuration is hardcoded into oomer.c - edit it and change the kill_by_name() entries in main() .

FUTURE PLANS:

Xoomer probably should take a few more configuration options and offer you the ability to unfreeze processes from the GUI. Possibly the ability to see more than the last four kills, as well.

Oomer should read a config file instead of requiring a recompile for every process list change.

Kill by memory use, uid, or more-complex matching rules.

Condition blocks, so you could say kill all processes run by a given user exceeding a given memory threshhold.

User-configurable and runtime-configurable process protection - at the moment I only protect pid 1.

renice or edit oom_adj instead of killing the target.

Oomer would be a lot more efficient running in kernel space; there is a possibility that some future version will be an LKM using netlink to communicate with xoomer.

For questions and comments and patches, contact me.

For more of my programs, go here.