On Wed, Oct 15, 2008 at 7:55 AM, Lars Eilebrecht <[EMAIL PROTECTED]> wrote: > Hi, > > The first odd thing is that I would have expected that Apache > uses all child processes about equally. Especially I would > have expected that there are at least 25 threads for the second > process in state "_" (waiting for connection), because the > MinSpareThread directive is set to 25.
requests check in, but they don't check out -- but only for this process. That would explain the backlog here, the other two processes are not ignores they're just doing their work in a timely fashion. > The second odd thing is that the connections/threads in W state > seem to be hanging, i.e., no data is being transferred over the > connection and these threads/connection time out after about 256 > seconds. However, the general Timeout setting is 30s so why > isn't the connection killed after 30s? This timeout only applies to an individual read/write, and the meter isn't running if we're not talking to the client (e.g. cgi chugging away) > > What happens during peek times is that all threads of one > child process end up in state W, then Apache starts using > another child process, etc. and at some point basically > all threads are in state W and we are hitting the MaxClients > limit which makes the server unusable. take a few pstack snapshots of one of those spinning processes? -- Eric Covener [EMAIL PROTECTED]
