NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "adjusting" / control Swapping



Greg Troxel wrote:
"Niels Dettenbach" <nd%syndicat.com@localhost> writes:

volume of 5 GB swap. The swap is needed as there are peaks of required
memory sometimes (once or twice a month) where the system stops with
out of mem otherwise. In most time the swap is not required, but used
(I assume i.e. for file caching). If i restart several of that
mem-pigs / deamons (i.e. once a day) within the system the swap was
wiped out and the sytsm seems to run faster (with less load). There
are daemons who doenst offer control of their caching or mem-usage
behaviour byself.

As others said, your problem is badly-behaved daemons.  Daemons that
intend to run forever should not accumulate memory usage.  So if they
do, add a cron job to restart them daily.

If it's apache, you might try an hourly reload and a daily restart.
apache might be ok but with embedded python it can get leaky.  reload is
nice in that child server processes are allowed to finish and new ones
are started, but the main process remains, so there is no losss of
service.  However it does not recover from leaks in the main process.

I'm not totally convinced the problem is badly-behaved daemons. If you have something that exercises the file caching a lot, your daemons will be pushed out to swap, even if they behave nicely. Killing them will of course remove them from swap. Restarting them will once more place them in memory, throwing away some file caches instead, since they are older.

Thus observing the same pattern, even though the processes are behaving nicely.

Personally, I have the following in my /etc/sysctl.conf on just about any machine I run:
vm.filemin=5
vm.filemax=10
vm.anonmin=5
vm.anonmax=80
vm.execmin=5
vm.execmax=50
vm.bufcache=5

not saying that this is ideal for all situations, but it much improved the systems for me at the time I was hunting around this thing, many years ago... I've left it at that since then, and it still produces a more responsive system in my experience.

        Johnny


Home | Main Index | Thread Index | Old Index