apache22 - lockf

M

Mayhem30

Is it normal for most apache processes to be in 'lockf' state?

Code: 
 4260 www         1  20    0   238M 53444K lockf   0   0:06  0.00% httpd
 4251 www         1   4    0   238M 46600K kqread  1   0:04  0.00% httpd
 4520 www         1  20    0   238M 42904K lockf   1   0:04  0.00% httpd
 4680 www         1  20    0   238M 41996K lockf   0   0:03  0.00% httpd
 4577 www         1  20    0   238M 39548K lockf   2   0:03  0.00% httpd
 4984 www         1  20    0   238M 38708K lockf   2   0:02  0.00% httpd
 5034 www         1  20    0   238M 37108K lockf   1   0:02  0.00% httpd
 5161 www         1  20    0   238M 34112K lockf   2   0:01  0.00% httpd
 5124 www         1  20    0   238M 33536K lockf   1   0:01  0.00% httpd
 5274 www         1  20    0   237M 30360K lockf   0   0:00  0.10% httpd
74935 root        1  44    0   235M 19588K select  0   0:14  0.00% httpd

I'm using FreeBSD 7.3, AMD64 kernel. I've read on some blogs that 'lockf' is not a "good thing" - but none had any advice on how to fix it.
 
Its normal for httpd to be in a lockf state if you have it configured to listen on more than one port. For example, if you have it listen on both port 80 and 443. If memory serves me right, httpd uses lockf to block the worker processes when no work is needed to be done.
 
That's probably correct. I have an Apache running on 80 and 443 (and on several IPs), and with no active sessions it says:

Code: 
  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
50814 www         1  44    0 77932K 32272K lockf    0:20  0.00% httpd
15046 www         1  44    0 78956K 29884K lockf    0:11  0.00% httpd
34991 www         1  44    0 77932K 28988K lockf    0:05  0.00% httpd
17134 www         1  44    0 77932K 29216K lockf    0:05  0.00% httpd
46106 www         1  44    0 77932K 28776K lockf    0:03  0.00% httpd
48862 www         1  44    0 77932K 28900K kqread   0:03  0.00% httpd
57916 www         1  54    0 76908K 25260K lockf    0:01  0.00% httpd
57874 www         1  44    0 74860K 12456K lockf    0:00  0.00% httpd
57878 www         1  44    0 73836K 12284K lockf    0:00  0.00% httpd
58030 www         1  44    0 73836K 12204K lockf    0:00  0.00% httpd
 
My processes stay on 'lockf' even if they are active or not. Only the rare odd time do I see a "kqread".

That's what has me concerned.
 
How are you determining if they are active? Keep in mind the prefork mpm auto-tunes itself to keep a number of spare, currently inactive workers around. Do you actually have a (measured) performance concern with your services?
 
I'm using top -I to watch the active processes. I do not have any measured performance cconcern, but from what I have been reading is that 'lockf' is bad.

I've also read some articles (like what you mentioned above) to listen to port 80 only - that way the process will show as "accept" - which is the most optimized way for it to run.
 
I just wanted to follow up that I was able to resolve this issue. Apache "STATE" should always be in 'select' or 'accept' mode.

Code: 
10163 www         1   4    0   236M 34396K accept  1   0:06  0.20% httpd
10686 www         1   4    0   236M 34260K accept  1   0:03  0.10% httpd
10313 www         1   4    0   236M 33468K accept  2   0:05  0.00% httpd
10750 www         1   4    0   236M 32396K accept  3   0:04  0.00% httpd
10845 www         1   4    0   236M 30824K accept  1   0:03  0.00% httpd
10655 www         1   4    0   236M 32508K accept  1   0:03  0.00% httpd
10864 www         1   4    0   235M 30404K accept  3   0:03  0.00% httpd

In the httpd.conf file, do not add more than (1) "Listen" directive.

What I did wrong was add a seperate directive (port) for each of my sites.

Code: 
Listen 127.0.0.1:81
Listen 127.0.0.1:82
Listen 127.0.0.1:83

This was done because I use nginx in front of apache to handle all the static content. I was using ip based virtualhosts in my configs - when I should have been using name based virtualhosts.

Ideally you should run servers without multiple Listen statements if you want the highest performance.
Click to expand...

(source) http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
 
You must log in or register to reply here.
Back
Top