Messages in this thread | | | Date | Sun, 9 Jul 2000 08:01:59 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Useful solution to some OOM probs (was Re: OOM in 2.2.14) |
| |
On Sat, 8 Jul 2000, Tom Sightler wrote:
>> >When talking about slow mem leaks and such, I agree with Mike >> >A. Harris. There should be a userland daemon to track free >> >memory and, if it falls below a critical level, add more swap. >> >> This solution however, is a userland issue - a potentially useful >> application (daemon), not really a kernel solution. I think it >> will be a decent solution to my problem though. > >I guess most people know this but there are already several >'swapd' programs out there. Just do a search on freshmeat or >Google. I've never used any, but they seem to have the basic >functionality to create and remove swap files on demand.
I've got one now, and it works very well after a bit of tweaking. Instead of testing it with benchmarks, I ran several apps that I normally might have running, and opened decent sized files with them. I kept pushing things to the point of excessiveness, but to which my system would normally handle anyways, and then I ran multiple "find /"'s about 10 seconds apart, followed by a few updatedb's and then tried to replicate the condition that caused the OOM the other day.
I watched with top on a console as the system swap slowly disappeared by the meg. I had a 1s update going to keep a good eye out. swapd was set to trigger at 20M free point and add another 32Mb swap. The extra swap didn't kick in until 10Mb, but I could tell there was little danger since I scheduled swapd as a realtime process, so when it decided it wanted to go, it virtually took-over the system for 3 seconds while top paused showing it was running, and then 32Mb of swap showed up right on time. I continued to bash the hell out of the system by opening large tar.gz files interactively, and PINE mailboxes containing 20000 messages.
The system was fairly responsive considering the bashing going on. NO OOM occured. My swap started at 72Mb (my partition size), and shot up 32Mb at a time to 200Mb+ as needed. As apps died off or I shut them down, the swap slowly trickled off back to my default 72Mb.
In short: Just what the doctor ordered. Now I have a base with which to add my improvements to. Anyone having lots of OOM problems might consider this approach on their workstations. I've got plenty of swap for normal conditions, so the extra swap doesn't degrade system performance unless something is wrong - and even then it was quite snappy even with fragmented swapfiles.
So, this solution will likely be quite useful to many others experiencing similar probs.
Take care, TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate
... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |