[rt-devel] Severe Memory Leak
Simon Talbot
simont at nse.co.uk
Wed Sep 24 16:02:56 EDT 2003
I hear what you say, but this would not account for the system getting
to a point where it runs out of physical and virtual memory and you end
with a kernel oops -- something is definitely leaking and of course you
can fix it by brute force, but isolating the errant module/area of code
has to be preferable. This certainly does provide me with another
workaround whilst we investigate further,
Thanks,
Simon
----------------------------
Simon Talbot MEng, ACGI
(Chief Engineer)
Net Solutions Europe Limited
Tel: 01206 274210
Fax: 01255 233305
----------------------------
-----Original Message-----
From: Vivek Khera [mailto:khera at kcilink.com]
Sent: 24 September 2003 19:42
To: rt-devel at lists.fsck.com
Subject: Re: [rt-devel] Severe Memory Leak
>>>>> "ST" == Simon Talbot <simont at nse.co.uk> writes:
ST> The system is lightly loaded with perhaps 50 tickets in total. If a
ST> browser is left with 'Support at a glance' page showing, and auto
ST> refresh set to every 2 minutes, the system leaks memory every
refresh --
ST> anywhere between 100 bytes and 4 or 5k per refresh.
Perhaps switching to a process model where the processes are not
persistent for so long will help. The thing with mod_perl is that the
perl interpreter is persistent, so any memory it allocates will not be
released to the system upon termination of the request. This is not a
memory leak -- it is just how it works. The perl process has gotten
the memory from the system and can reuse it many times to satisfy the
memory allocation needs of the code.
Your options are to either reduce the number of requests each mod_perl
process handles (MaxRequests in httpd.conf) or to use something like
speedy cgi with a kill idle processes after X minutes of idle time so
that the memory is released back to the system.
_______________________________________________
rt-devel mailing list
rt-devel at lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
More information about the Rt-devel
mailing list