I have a rather old Linux machine with 2GB of ram, no swap, and it's working very well, with the system using every unused piece of memory for caching with great effect.
However, when I'm close to stressing out memory (e.g., >1950MB allocated), it slows to a crawl; I suspect that's because there are no disk buffers left. I know that the OOM killer would soon go into effect, but it doesn't usually get there — it's becoming so slow that loads shoots to 30-40, no process makes any progress (thus doesn't allocate more memory), and I have to restart it.
When I try to just kill one process to get the machine to respond, e.g. by going to the console (via Alt-F1, logging in, and just doing a "killall badprocess"), it usually works, except that I have to wait ~10 minutes between user/password and getting a prompt — all while there is disk activity.
Again, there's no swap, so it isn't swapping — it's just thrashing because it has no buffers left.
I would much have 100MB or so dedicated exclusively to disk buffers, which would trigger the OOM killer earlier (less memory for programs, after all) but on the other hand would leave the machine responsive at all times.
Is there a way to do that? I haven't been able to find a /proc/kernel or /sys/vm entry that does this kind of thing.
Best Answer
Have a look at /proc/sys/vm/min_free_kbytes. It's the limit of free kbytes that triggers the oom-killer. Also it would be good to check at the logs for the keyword oom-killer in order to know what is being killed {propably you don't want to kill ssh, you it's better to renice it}