So, I thought this would be a pretty simple thing to locate: a service / kernel module that, when the kernel notices userland memory is running low, triggers some action (e.g. dumping a process list to a file, pinging some network endpoint, whatever) within a process that has its own dedicated memory (so it won't fail to fork() or suffer from any of the other usual OOM issues).
I found the OOM killer, which I understand is useful, but which doesn't really do what I'd need to do.
Ideally, if I'm running out of memory, I want to know why. I suppose I could write my own program that runs on startup and uses a fixed amount of memory, then only does stuff once it gets informed of low memory by the kernel, but that brings up its own question...
Is there even a syscall to be informed of something like that? A way of saying to the kernel "hey, wake me up when we've only got 128 MB of memory left"?
I searched around the web and on here but I didn't find anything fitting that description. Seems like most people use polling on a time delay, but the obvious problem with that is it makes it way less likely you'll be able to know which process(es) caused the problem.
sar
, and that may help you do perform a post-mortem. Continually reporting on that locally generated data would be pretty expensive on the network, though. Are you planning to keep the data local (or via something like NFS) much like kdump?sar
is pretty cool. Thanks for the recommendation. Tend to usehtop
or regulartop
, though they're resource-hungry on a good day, so... maybe not the best tool for the job. :P