This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Jon Molin <Jon.Molin@resfeber.se> From: Stas Bekman <stas@stason.org> Subject: Re: tracing memory problem Date: Fri, 7 Sep 2001 18:36:51 +0800 (SGT) On Fri, 7 Sep 2001, Jon Molin wrote: > Hi list, > > I have a memory leak in a script or module, the problem is that i've > resently added many scripts and modules and can't easily isolate the > problem. Is there a way besides strace to see what the httpd process is > up to? > 9869 httpd 0 0 21188 19M 2424 S 0 12.2 3.8 0:13 httpd > doesn't help me too much... Please explain what do you mean by 'what the httpd process is up to'? It's not an easy task to find the offending code that causes memory leaks. Using GTop.pm for easier memory debugging printing helps a lot, Devel::Peek is useful too, try also Devel::Leak and their Apache:: friends: Apache::Peek and Apache::Leak. You can find some notes on using these in the mod_perl guide. Apache::VMonitor can be very useful too. Otherwise you will probably have to play the halving game: remove half of your modules/scripts and test. If nothing comes up return a half of the removed half, and so on. It's not always working like that, since some code may leak when it interacts with some specific code. In the meantime, use Apache::SizeLimit to prevent the processes from growing. See the guide or the manpage for the details. === To: Jon Molin <Jon.Molin@resfeber.se> From: Stas Bekman <stas@stason.org> Subject: Re: tracing memory problem Date: Fri, 7 Sep 2001 18:57:06 +0800 (SGT) On Fri, 7 Sep 2001, Jon Molin wrote: > Stas Bekman wrote: > > > > On Fri, 7 Sep 2001, Jon Molin wrote: > > > > > Hi list, > > > > > > I have a memory leak in a script or module, the problem is that i've > > > resently added many scripts and modules and can't easily isolate the > > > problem. Is there a way besides strace to see what the httpd process is > > > up to? > > > 9869 httpd 0 0 21188 19M 2424 S 0 12.2 3.8 0:13 httpd > > > doesn't help me too much... > > > > Please explain what do you mean by 'what the httpd process is up to'? > > > > sorry, what i meant was what script was accessed by the httpd process. > That's the first problem, locating what set of scripts(modules) it can > be and after that start looking... you can use Apache::VMonitor or a trick with SIGUSR2 http://perl.apache.org/guide/debug.html#Using_the_Perl_Trace > > It's not an easy task to find the offending code that causes memory leaks. > > Using GTop.pm for easier memory debugging printing helps a lot, > > Devel::Peek is useful too, try also Devel::Leak and their Apache:: > > friends: Apache::Peek and Apache::Leak. You can find some notes on using > > these in the mod_perl guide. Apache::VMonitor can be very useful too. > > > > Otherwise you will probably have to play the halving game: remove half of > > your modules/scripts and test. If nothing comes up return a half of the > > removed half, and so on. It's not always working like that, since some > > code may leak when it interacts with some specific code. > > > > In the meantime, use Apache::SizeLimit to prevent the processes from > > growing. See the guide or the manpage for the details. > > ok, i'll look into that. I've been using RLimitMEM and RLimitCPU in > httpd.conf: > RLimitMEM 15728640 15728640 > RLimitCPU 600 600 > and haven't got them to work very good: > 10314 httpd 13 0 67824 66M 5572 R 0 17.9 13.1 4:19 httpd > 10313 httpd 13 0 69984 68M 5580 R 0 17.7 13.5 4:33 httpd Hmm, that's from Apache core, have never tried using these. Anybody? try using BSD::Resource/Apache::Resource and Apache::SizeLimit instead. These work. But you have to solve the leaking problem anyhow. > but i guess that's fairly OT on the mod_perl list. On the opposite, this is very ontopic, since it's very tricky to find a problem when you have many modules and scripts running in the same interpreter. So if during the search you come up with some nice technique we all be very grateful :) === To: "Jon Molin" <Jon.Molin@resfeber.se>, "Stas Bekman" <stas@stason.org> From: "Perrin Harkins" <perrin@elem.com> Subject: Re: tracing memory problem Date: Fri, 7 Sep 2001 10:11:41 -0400 > ok, i'll look into that. I've been using RLimitMEM and RLimitCPU One thing to be aware of is that using rlimit will kill your process harshly when it goes over the limit. It's better to use Apache::SizeLimit for basic size control, and use rlimit as a backup safety measure to catch runaway processes. Apache::SizeLimit will detect processes that are getting too big and make them cleanly exit after they finish the current request. ===