Hi all,
On Wed, 19 Jan 2000, Gerald Richter wrote:
> in the long term, the solution that you have prefered in previous
> mail, not to unload modperl at all, maybe the better one
As I understand it with Apache/mod_perl:
1. The parent (contains the Perl interpreter) fires up, initialises
things and launches some children. Any memory it leaks stays
leaked until restart. That could be weeks away. Apart from
making copies of it, most of the time it doesn't do much with the
interpreter. More waste.
2. The children occasionally get the coup de grace, so we recover
any memory they leaked. They do lots with the interpreter.
3. When the parent fork()s a new child it can fork some leaked memory
too, which gradually will become unshared, so the longer this goes
on the closer we get to bringing the whole system to its knees.
So in the longer term, is there a reason the parent has to contain the
interpreter at all? Can't it just do a system call when it needs one?
It seems a bit excessive to put aside a couple of megabytes of system
memory just to run startup.pl. If one could get around any process
communication difficulties, the children could be just the same as
they are now, but exec()ed instead of fork()ed by a (smaller) child
process which has never leaked any memory. The exec() latency isn't
an issue because of the way that Apache preforks a pool of processes
and the overhead will be minimal if the children live long enough.
Please tell me if I have got this all around my neck.
73,
Ged.
