Re: [EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-15 Thread Joshua Slive

On 12/15/06, Kevin Jones [EMAIL PROTECTED] wrote:

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.


Ok.  So my guess about KeepAlive was wrong.  Your problem is that the
php scripts are blocking on something or other.  Could still be the
session file, or could be something else.  You'd probably have better
luck asking on a php list, since the problem has nothing directly to
do with apache.

Joshua.

-
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: [EMAIL PROTECTED]
 from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-15 Thread Richard Lynch
On Fri, December 15, 2006 10:59 am, Joshua Slive wrote:
 On 12/15/06, Kevin Jones [EMAIL PROTECTED] wrote:
 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.

 Ok.  So my guess about KeepAlive was wrong.  Your problem is that the
 php scripts are blocking on something or other.  Could still be the
 session file, or could be something else.  You'd probably have better
 luck asking on a php list, since the problem has nothing directly to
 do with apache.

As a super-quick stupid hack, try adding:
?php exit; ?

to the end of the PHP scripts, if you can...

Again, more in the realm of Voodoo than debugging, but easy to test,
and may get you through until you can really fix the true problem.

Check settings in php.ini for ignore_user_abort and session time out
settings.

Do post to php-general, and be specific about your versions of
everything.

I seem to recall an issue with the session-writer and how it
serialized data in PHP, but it was very version-specific.

-- 
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: [EMAIL PROTECTED]
  from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-14 Thread Joshua Slive

On 12/13/06, Kevin Jones [EMAIL PROTECTED] wrote:

I'm running an Apache server on a FreeBSD server with 494 MB of RAM and an
Intel Celeron 2.4 GHz CPU.
A recent surge of traffic to my PHP site has been causing the server to come
to its knees.

The first symptom is that the server won't return my page when I access it
through the browser. The connection times out.

In researching, I found out that my available RAM had become cripplingly low
(about 1 meg) because Apache had spawned over 100 different processes of
itself.

So, I figured the way to fix this was to limit how many processes Apache
would start up max, so I edited the httpd.conf and set MaxClients to 40 (I'm
using the prefork MPM) and KeepAliveTimeout to 15.

That's fine, but now it runs out of available processes to handle requests
very soon. I run top to see what's happening, and I see that most of the
apache processes are in the lockf state. And a few are in sbwait. I run
ps, and see that most of the apache processes are idle or sleeping.

What do lockf and sbwait mean? Are the processes just idling?
How do I get the Apache processes to die?


The best way to figure out what is really going on is to use the
server-status handler provided by mod_status.

You'll probably find that most of your processes are waiting on
keep-alive connections.  For a server with inadequate resources, a
KeepAliveTimeout of 15 is way too high.  You want to consider
something under 5 seconds, and perhaps even turning off keepalive
entirely depending on your load characteristics.

Joshua.

-
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: [EMAIL PROTECTED]
 from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-14 Thread Richard Lynch
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: [EMAIL PROTECTED]
  from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-13 Thread Kevin Jones

I'm running an Apache server on a FreeBSD server with 494 MB of RAM and an
Intel Celeron 2.4 GHz CPU.
A recent surge of traffic to my PHP site has been causing the server to come
to its knees.

The first symptom is that the server won't return my page when I access it
through the browser. The connection times out.

In researching, I found out that my available RAM had become cripplingly low
(about 1 meg) because Apache had spawned over 100 different processes of
itself.

So, I figured the way to fix this was to limit how many processes Apache
would start up max, so I edited the httpd.conf and set MaxClients to 40 (I'm
using the prefork MPM) and KeepAliveTimeout to 15.

That's fine, but now it runs out of available processes to handle requests
very soon. I run top to see what's happening, and I see that most of the
apache processes are in the lockf state. And a few are in sbwait. I run
ps, and see that most of the apache processes are idle or sleeping.

What do lockf and sbwait mean? Are the processes just idling?
How do I get the Apache processes to die?

Thanks for any help.


Re: [EMAIL PROTECTED] Processes not yielding, and lockf

2006-12-13 Thread Ravi Menon

It is been a while since I last worked on FreeBSD but if I recall correctly:

'lockf' - sleeping on a flock() or fcntl() equivalent on some file fd somewhere.

'sbwait' - socket buffer wait - a wait due to recv or send buf size
for socket fds'.

Attaching a gdb on such child pids and getting a backtrace might help narrow
down where it could be occuring - maybe it is a deadlock.

Also 494MB of ram sounds awfully less these days - increasing it might help.

Ravi


On 12/13/06, Kevin Jones [EMAIL PROTECTED] wrote:

I'm running an Apache server on a FreeBSD server with 494 MB of RAM and an
Intel Celeron 2.4 GHz CPU.
A recent surge of traffic to my PHP site has been causing the server to come
to its knees.

The first symptom is that the server won't return my page when I access it
through the browser. The connection times out.

In researching, I found out that my available RAM had become cripplingly low
(about 1 meg) because Apache had spawned over 100 different processes of
itself.

So, I figured the way to fix this was to limit how many processes Apache
would start up max, so I edited the httpd.conf and set MaxClients to 40 (I'm
using the prefork MPM) and KeepAliveTimeout to 15.

That's fine, but now it runs out of available processes to handle requests
very soon. I run top to see what's happening, and I see that most of the
apache processes are in the lockf state. And a few are in sbwait. I run
ps, and see that most of the apache processes are idle or sleeping.

What do lockf and sbwait mean? Are the processes just idling?
How do I get the Apache processes to die?

Thanks for any help.



-
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: [EMAIL PROTECTED]
 from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]