I’m the other way. I’d rather have battery life on cell phones, and turn the refresh rate down.
On a desktop, where the power usage is basically irrelevant, then sure, I’ll crank the refresh rate way up. One of the most-immediately-noticeable things is the mouse pointer, and that doesn’t exist on touch interfaces.
OOMs happen because your system is out of memory.
You asked how to know which process is responsible. There is no correct answer to which process is “wrong” in using more memory — all one can say is that processes are in aggregate asking for too much memory. The kernel tries to “blame” a process and will kill it, as you’ve seen, to let your system continue to function, but ultimately, you may know better than it which is acting in a way you don’t want.
It should log something to the kernel log when it OOM kills something.
It may be that you simply don’t have enough memory to do what you want to do. You could take a glance in
top
(sort by memory usage with shift-M). You might be able to get by by adding more paging (swap) space. You can do this with a paging file if it’s problematic to create a paging partition.EDIT: I don’t know if there’s a way to get a dump of processes that are using memory at exactly the instant of the OOM, but if you want to get an idea of what memory usage looks at at that time, you can certainly do something like leave a
top -o %MEM -b >log.txt
process running to get a snapshot every two seconds of process memory use.top
will print a timestamp at the top of each entry, and between the timestamped OOM entry in the kernel log and the timestamped dump, you should be able to look at what’s using memory.There are also various other packages for logging resource usage that provide less information, but also don’t use so much space, if you want to view historical resource usage. sysstat is what I usually use, with the
sar
command to view logged data, though that’s very elderly. Things like that won’t dump a list of all processes, but they will let you know if, over a given period of time, a server is running low on available memory.