Linux

Ah point taken.

The system has 64 gigs of memory, and probably was using 30% of it before someone/something used it all up. What would emacs be doing?

I know it is possible in vi, since I once did a substitute command in vi on a big file and drained the memory.

---------- Post updated at 08:55 ---------- Previous update was at 08:50 ----------

I tried looking for the eps() command on my box, RHEL, but couldn't find it. Is it available on RHEL or just SCO Unix?

I think you misunderstood corona.

When a Linux box runs out of memory it starts killing processes (I think randomly) to free memory. In this case emacs was just prey. As corona said too, you can't see by this messages, which other processes were using up all memory, causing this behaviour (killing other processes).

So you might want to, as already said, just write a little script and place it in the crontab, that takes a snapshot with ps and pmap every hour or 10 minutes or whatever and compare them and have a look which of them rises in memory usage between a fresh reboot and when it is about time it should start doing this.

Checking the source, it's got a complex scoring system to measure a process' "badness". It preferentially kills:But it can only measure the stats, and gauges what's safe to kill as much as what should be killed.

This doesn't rule out emacs, either! It might have been killed because it was consuming too much memory. Or it might have been killed to make way for a runaway process that had higher priority or access privileges than it, which the OOM killer preferentially keeps.

I just answered a previous note about memory usage and pointed the user at collectl. There are a couple of things worth noting - collectl is VERY lightweight, on the order of using <0.1% of the cpu when sampling system data every 10 seconds! When trying to track down something tricky you ALWAYS need fine grained time or you never see those spikes that so ofter offer at the least expected time. In fact if you want to sample once a second you're still <1%.

But back to the problem at hand. While you can certainly run ps from cron every hours there are 2 reasons why you might not want to. First of all, sampling once an hour isn't really going to help much unless you get real lucky. Second, even if ps did tell you something you might also want to get other things that happened at the time in question like CPU, memory usage, open files, etc. but you don't have access to it because you didn't think to ask ahead of time.

With collectl, you just start it running as a daemon and it will collect more than you thought of to ask. It will even collect info on your slab usage and a runaway allocation of slab memory can certainly trigger the out-of-memory killer.

Just note that collectl only monitors slabs/processes once a minute because there are high load tasks...

-mark

Thanks Mark! collectl seems to be the type of monitor tool I need to use to keep track of events; certainly as you have pointed out a much better solution than cron and ps. I'll give it a go. Cheers!

Dave