lkml.org 
[lkml]   [2000]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectUseful 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site