[Catalyst] Memory leak under FastCGI?

[Matt Pitts]

> -----Original Message-----
> From: Matt S Trout [mailto:dbix-class at trout.me.uk]
> Sent: Friday, April 11, 2008 1:23 PM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Memory leak under FastCGI?
> 
> On Fri, Apr 11, 2008 at 11:20:53AM -0400, Matt Pitts wrote:
> > > The accept() happens in the child in normal situations though, so
> the
> > > parent can't know how many requests a given child has handled
> without
> > > additional complication.
> >
> > Yeap. My version of the "additional complication" is a lite IPC
> > messaging system using DBM::Deep. I override post_dispatch in the
> > children to send a message to the queue that says "I just finished
> > handling a request" and then the manager iterates the message queue
> > during each daemon loop and keeps track of each child's request
> count.
> 
> Yuck.
> 
> Seems much simpler to me to do something like:
> 
> Child1 hits request count, sends SIGUSR1 to proc manager, starts
> exiting
> 
> Manager sends SIGUSR1 to all other children
> 
> (child may take a while to clean up, exit happens somewhen)
> 
> Other children go into "must not die" mode
> 
> Manager spawns new child once it gets SIGCHLD
> 
> New child sends SIGUSR2 to proc manager once it's starting its
accept()
> loop
> 
> Proc manager sends SIGUSR2 to all children to indicate they're allowed
> to
> die now if they want to
> 
> Seems a lot more unixy to me, and likely much less overhead as well.

Neat. I like this approach, especially if the only process limitation is
MaxRequestsPerChild. My original motivation behind a message queue was
to make it easier to add additional management facilities, but as of now
MaxRequestsPerChild is the main one I'm interested in. Although I had
thought about using SIGUSR1 or 2 to implement a simple ping to make sure
that a child is still "there". I'll definitely keep your approach in
mind if I decide to only implement MaxRequestsPerChild.

Going the SIGUSR approach I think I'd still want the manager to be the
one sending SIGTERM to the children and have the children trap SIGTERM
and set a flag to exit(0) at the end of the current request during
post_dispatch. This way if the manager "wants" to kill multiple children
in a short time period it can.

Thanks for the input!

v/r
-matt pitts