[Catalyst] Memory leak under FastCGI?

[Dave Howorth]

Matt S Trout wrote:
> 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.

Child1 starts the cycle, child2 & child3 receive SIGUSR1 and both soon
hit request limit (they're all fed by round-robin, perhaps). Manager
sends SIGUSR2. Both child2 and child3 send SIGUSR1 and die. Even if the
protocol is fixed to avoid this race I suspect there will be 'convoys'
unless some randomisation is introduced.

Can I suggest a different approach? The requirement is to make sure each
child dies regularly to avoid problems from memory leaks. So have the
manager just tell each child to die in turn based on a timer. Simple and
fixed overhead. It doesn't matter if children die 'too early' in light
load conditions.

Cheers, Dave