Messages in this thread | | | Date | Tue, 17 Oct 2000 10:02:52 -0400 (EDT) | From | Byron Stanoszek <> | Subject | OOM Test Case - Failed! |
| |
I am very unimpressed with the current OOM killer. After 10 days of online time, I decided to try compiling gcc again, the very culprit that killed my last system using 2.4.0-test8 Friday night (to which I was unable to reset the system until Monday morning).
GCC started compiling normally, until it reached the command: ./genattrtab ../../gcc/config/i386/i386.md > tmp-attrtab.c
At this time, genattrtab started to accumulate 70+ Megabytes of memory. For comparison, I only have 32MB of RAM and 64MB of swap space. Also during this time were several daemon and user-level programs running, using at most 4MB of ram each and running peacefully in the background.
The system slowed down to a crawl. 5 minutes later, the OOM killer finally kicked in and killed 5 processes: <httpd>. I figure, okay, httpd doesn't need to run, I'd rather give the GCC-compilation the extra RAM it needs to finish its 'genattrtab' program.
10 minutes pass and the system does not get better. Then all of a sudden, the console flashes with more <httpd> processes killed. "What is going on here," I thought to myself. There were only 6 httpd processes running when I first started the compilation. It appears that the OOM killer destroyed only the children of the Apache web daemon, and not the daemon itself! The web daemon just spawned more httpd processes to fill in the children that it lost earlier.
Meanwhile, genattrtab continued to consume RAM in the background. After 10 more minutes of waiting on the OOM killer, I come back to a console that is filled with 'Killing process <httpd>' messages. It never had the bright idea to kill the parent or any process OTHER than httpd.
The expected process to kill here would be ./genattrtab, which at the time was consuming more RAM than available and had only started 25 minutes prior...
root 1099 63.6 61.5 71424 18740 pts/0 R 09:39 1:22 ./genattrtab
This was my first OOM killer test, run on 2.4.0-test9-final with Rik's VM patches that went into test10-pre1. My prognosis is that the VM runs almost 2x as fast when there is memory available and swapping occurs, compared to the old VM. However, when memory runs out, it takes up to 5 minutes for the OOM killer to start killing processes, and does a bad job at that.
Granted, the random OOM killer in 2.2 was better at its job than this because it brought back a usable system. Even something that killed the process that's using the most RAM or the process that allocates the most space in a set period of time would be good in this case. We need to decide on a better algorithm, albeit simple, that will alleviate this problem before 2.4.0 final comes out.
Regards, Byron
-- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: bstanoszek@comtime.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |