Date: Mon, 2 Jun 97 21:11:46 -0400 From: Garance A Drosehn <gad@mlor.its.rpi.edu> To: hackers@FreeBSD.ORG Subject: Re: vm problems on 2.2, 2.1.7 works Message-ID: <9706030111.AA01950@mlor.its.rpi.edu> References: <199705261412.QAA07764@zibbi.mikom.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 26th, John Hay <jhay@zibbi.mikom.csir.co.za> wrote:
> This looks a lot like the problem I have on my news server. It
> will run ok for a while and then suddenly start to use up all of
> the swap. According to top and ps no process is using that memory,
> but if I kill innd quick enough all will be ok. So now I have a
> script that runs every minute and kill and restart innd as soon
> as the swap usage go over some value. Not nice, but it works
> until someone find this thingy.
Does INND call fork() for some of it's processing?
If so, this sounds somewhat similar to a vm problem that exists
in NeXTSTEP, and which (IIRC) used to exist in FreeBSD, but had
been fixed earlier. It might have been in one of the other BSD
variants, though.
In any case, the problem comes up when:
1) some of the original process gets paged out
2) that process forks
3) the child causes the paged-out memory to get paged back in.
4) the parent does things which either just pages the same
memory in, or which actually modifies those pages (I was
never quite clear if the modify was part of this). Note
that it *is* important (to this bug) that the child does
not modify those pages.
5) the child dies. All pages that the child paged in would not
get released, because the child didn't modify them and thus
no "copy on write" was done, and thus the memory is assumed
to be the same as the parent process. However, the parent
process already has those same pages (perhaps in modified
form), and thus it isn't looking at the old copy which the
child paged in.
The child is gone, and the memory in question is kept around by
the virtual memory system. However, there is no task which really
owns that memory, so your swapfile size keeps growing even though
you never see any process with a large VM size. Once you do kill
and restart the original task, all that memory is released and your
swapfile usage will shrink. So, if this is the problem, than the
worst thing for it would be a single very large process which runs
"forever", and which occasionally forks off a child to do some
processing.
I know that in the case of NeXTSTEP 3.2, I can end up with a swapfile
of 500 Meg (after running for six months straight), even though
there is no process that's over 40 meg. If this is the problem,
then increasing the amount of RAM in your machine can dramatically
slow down the rate that your swapfile grows.
Of course, I have absolutely no idea if this is the problem you
(and others) are apparently seeing with FreeBSD 2.2. I suspect
it is not, but maybe this description will give you some ideas
of things to check for.
---
Garance Alistair Drosehn = gad@eclipse.its.rpi.edu
Senior Systems Programmer (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute; Troy NY USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9706030111.AA01950>