On Fri, 29 May 2009, Diego d'Ambra wrote:
Jared Johnson wrote:
> What's orphaned is not a child process, but a shared mem hash record for
> a
> process which no longer exists. I suspect that code is racy.
Hrm, then if we're getting a whole lot of these, does this mean child
processes are going away at a high rate? I wouldn't expect such a
condition using prefork with relatively low concurrency, maybe this
reflects a problem during the end of the connection..
Are you running latest version of prefork?
IIRC there was an issue with calculation of needed children, so if your
current running children are all terminated at once, it could take some time
before the parent notice this and spawns new.
Even if you're not near max children the parent will only spawn max idle
children, then it sleeps until an event, wake-up and see if more children are
needed. Debug log should give some clue, if this is the reason.
Latest version of prefork also handles a possible race better, the parent
will detect a lock and reset shared memory.
While what you say may be true, I think there is further improvement to be
made. Child processes should remove themselves from the shared memory
hash, rather than do it by the parent via sigchild.
is there someone who is the 'design authority' on this aspect of the
prefork daemon?
---
Charlie
