You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Perrin Harkins <pe...@elem.com> on 2004/10/06 18:39:35 UTC

Re: [SumsaultRT #1249][mp1] text-book forking code still producing zombies

On Wed, 2004-10-06 at 16:56, Mark Stosberg wrote:
> At your recommended, I installed strace and ran it on the hung process.
> It doesn't work.

Hmm, maybe it's time to add some logging to your forked processes to
find out where they are getting stuck.

> Could setting MaxRequestsPerChild be a meaningful solution here? It
> would seem that this would cause the Apache child processes to
> periodically get re-created, killing related zombies in the process. 

If you aren't using MaxRequestsPerChild or something like
Apache::SizeLimit, you definitely should be.

By the way, I'm loving your CGI::Application::ValidateRM (and
Data::FormValidator) module.

- Perrin


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: [SumsaultRT #1249][mp1] text-book forking code still producing zombies

Posted by Mark Stosberg <ma...@summersault.com>.
On 2004-10-06, Mark Stosberg <ma...@summersault.com> wrote:
>
>>> Could setting MaxRequestsPerChild be a meaningful solution here? It
>>> would seem that this would cause the Apache child processes to
>>> periodically get re-created, killing related zombies in the process. 
>>
>> If you aren't using MaxRequestsPerChild or something like
>> Apache::SizeLimit, you definitely should be.
>
> Great, We'll start using that. 

Setting MaxRequestsPerChild to 100 seemed to be a sufficient solution in
this case. We are now seeing a zombie count that hovers between 20 to
30, very acceptable number for us. 

Thanks to Stas and Perrin for your help!

	Mark

-- 
http://mark.stosberg.com/ 


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: [SumsaultRT #1249][mp1] text-book forking code still producing zombies

Posted by Mark Stosberg <ma...@summersault.com>.
On 2004-10-06, Perrin Harkins <pe...@elem.com> wrote:
> On Wed, 2004-10-06 at 16:56, Mark Stosberg wrote:
>> At your recommended, I installed strace and ran it on the hung process.
>> It doesn't work.
>
> Hmm, maybe it's time to add some logging to your forked processes to
> find out where they are getting stuck.

We did add some logging and found the child is getting all the way to
the end of code block-- it logs just before calling "CORE::die". I just 
double-checked the logs and it looks we are always getting to
"CORE::die",  but zombies don't seem to happen every time. 

I also see the zombie count fluctuate a little bit. Some times it goes
down by just 1 or 2 on it's own. 

>> Could setting MaxRequestsPerChild be a meaningful solution here? It
>> would seem that this would cause the Apache child processes to
>> periodically get re-created, killing related zombies in the process. 
>
> If you aren't using MaxRequestsPerChild or something like
> Apache::SizeLimit, you definitely should be.

Great, We'll start using that. 

> By the way, I'm loving your CGI::Application::ValidateRM (and
> Data::FormValidator) module.

Great! If you don't follow the CGI::Application list, you may be
interested to know there are several other "plugins" like ValidateRM
that have appeared recently:

http://search.cpan.org/search?query=CGI%3A%3AApplication%3A%3APlugin&mode=module

I'll soon release an update to the "DBH" plugin that supports multiple
database handles. 

	Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark@summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html