On Thu, Feb 11, 2010 at 11:19 AM, Jonathan Petersson <[email protected]> wrote: > Hi all, > > I've a few selected servers on which I've started getting issues with > mod_fcgi on. All of these servers are generally overloaded which partially > is the source of this issue. > > Anyhow to break down the problem there's multiple portions we have the > following: > - "Normal"/"Simple" PHP-scripts (we're talking Hello World) are sticking > around and utilizes the full IdleTimeout even though they've finished > processing before exiting
Isn't that Working as Designed? Idle apps aren't subject to termination until after IdleTimeout? (perhaps I misunderstood you) > - On numerous occasions mod_fcgi segfaults returns: [notice] child pid <pid> > exit signal Segmentation fault (11), I take it that this happens when a > mod_fcgi wrapper terminates, however something tells me it shouldn't > segfault on exit A fix for an httpd child process crash in mod_fcgid was recently committed; the crash occurred when the FastCGI app didn't write any response headers or body before closing the connection. I don't know if any of your apps could do that. Can you get a coredump and backtrace from the crash? > - mod_fcgi drops MaxProcessCount to 0 [notice] mod_fcgid: too many > processes (current:0, max:0), skip the spawn request, prior to this the > server generally says [notice] mod_fcgid: <path>/<script>.php total process > count 120 >= 120, skip the spawn request (again due to overload) Those messages have different meanings. The one with "total process count" is based on FcgidMaxProcesses (MaxProcessCount). The one that shows bad data is based on FcgidMaxProcessesPerClass (DefaultMaxClassProcessCount). I don't see what is corrupting FcgidMaxProcessPerClass. Just maybe the segfaults occurred while initializing the data structure where that was picked up, but I don't think that is likely. > > 1 and 2 is survivable but once MaxProcessCount drops we have to restart > apache to get things rollin again which isn't all that great. > > Here's the config I'm using, we have the exact same on multiple servers on > which we don't have any issues with. > > <IfModule mod_fcgid.c> > AddHandler fcgid-script .fcgi > SharememPath /var/lib/fcgid/shm > SocketPath /tmp/fcgid_sock > IdleTimeout 60 > ProcessLifeTime 7200 > MaxProcessCount 120 > IPCCommTimeout 300 > IPCConnectTimeout 8 > DefaultMaxClassProcessCount 5 > DefaultMinClassProcessCount 0 > </IfModule> That looks reasonable to me, though perhaps it would perform better with a higher DefaultMaxClassProcessCount? Are apps getting terminated frequently and replaced shortly thereafter? --/-- I think the best plan is to try to solve the segfault then proceed from there.
