Re: Processes not yielding, and lockf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I used the server-status handler with extended status to see what was happening. I have also reduced the KeepAliveTimeout to 4 seconds. I placed session_write_close() within my scripts.

Currently all 256 requests (that is MaxClients) are being processed.
Every single one of them is stuck on "Sending Reply".
The server now has 980 KB free, but I feel certain that just including more RAM won't get rid of the problem.

The SS field (Seconds since beginning of most recent request) looks as though it averages about 3000 seconds.

The Req field (milliseconds to process last request) is actually 0 for all except about 15 or so which have values such as 2032313583 (an unrealistically high number, considering the server was last rebooted 5 hours ago).

So, my next question is: what would cause the connection to be stuck on Sending Reply?

Thanks.

An excerpt of the server-status:

SrvPIDAcc MCPU SSReqConnChildSlotClientVHostRequest
0-08080/11/11W 0.39657000.00.590.59 64.208.172.177mydomain.comGET /more.php?pid=25&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878
1-048760/11/45W 0.21151600.00.410.79 64.208.172.177mydomain.comGET /comments.php?wid=1126&PHPSESSID=a4b917d6f7a2ec3c6da2058f51
2-034860/19/42W 1.39104700.00.851.39 64.208.172.177mydomain.comGET /comments.php?wid=1133&PHPSESSID=a4b917d6f7a2ec3c6da2058f51
3-035170/1/22W 0.30901200.00.011.01 64.208.172.177mydomain.comGET /index.php?PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 HTTP/
4-035180/2/17W 0.27760700.00.020.30 64.208.172.177mydomain.comGET /more.php?pid=9&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878
5-029940/7/17W 1.35619500.00.210.71 64.208.172.177mydomain.comGET /more.php?pid=29&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878
6-09000/50/50W 1.81578900.01.041.04 64.208.172.177mydomain.comGET /more.php?pid=36&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878
7-035190/13/34W 0.47385900.00.150.48 64.208.172.177mydomain.comGET /detail.php?pid=41&PHPSESSID=a4b917d6f7a2ec3c6da2058f51df87

SrvChild Server number - generation
PIDOS process ID
AccNumber of accesses this connection / this child / this slot
MMode of operation
CPUCPU usage, number of seconds
SSSeconds since beginning of most recent request
ReqMilliseconds required to process most recent request
ConnKilobytes transferred this connection
ChildMegabytes transferred this child
SlotTotal megabytes transferred this slot






On 12/14/06, Richard Lynch < ceo@xxxxxxxxx> wrote:
On Wed, December 13, 2006 10:43 pm, Kevin Jones wrote:
> What do lockf and sbwait mean? Are the processes just idling?

This answer falls more under the realm of Voodoo than Debugging, but
it's possible that the lockf processes are waiting on PHP to finish
its locked session storage.

It's very very very common to develop a web application that does this:

<?php
  session_start();
  $inputs = $_SESSION['inputs'];
  //very long process here with SQL etc
  //note that we are NOT actually reading/changing $_SESSION here
?>

PHP has to keep the session file locked the whole time because you
might change the data in it, and in order to avoid race conditions, it
cannot allow another process to write to that particular session
cache.

This is not an issue, unless your IMG tags, your iframes, your Ajax-y
elements and so on all are trying to utilize the same session data...

At which point a single page load, instead of doing the main document,
IMGages, iframes, and Ajax stuff in parallel, has to end up doing them
sequentially as PHP locks, processes, and unlocks the session data for
each individual request.

Inserting a http://php.net/session_write_close after your last usage
of $_SESSION in every script is a fairly quick and easy way to
minimize your current time-window of session lock-age.

Consolidating $_SESSION activity into one portion of a script, instead
of scattered willy-nilly, can be a long-term task, but give
significant performance boost, as I understand it.

Disclosure:
I'm merely parroting what has been posted to PHP lists/forums here,
and have not actually had to do this (yet) for any sites.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL: http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux