httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <>
Subject RE: Regarding Apache 2.0.48 and specweb99
Date Tue, 02 Dec 2003 23:49:34 GMT
I enabled the POST transactions, and all of a sudden, the apache process is
now hung (this is first time I'm seeing this behaviour).. The stack is :

(gdb) t 21
[Switching to thread 21 (system thread 29207)]
#0  0xc000000000306850:0 in _semop_sys+0x30 () from
(gdb) bt
#0  0xc000000000306850:0 in _semop_sys+0x30 () from
#1  0xc000000000314b50:0 in semop+0xb0 () from /usr/lib/hpux64/
#2  0xc000000001b73220:0 in proc_mutex_sysv_acquire+0x70 ()
   from /opt/hpws/apache/lib/
#3  0xc000000001b73fc0:0 in apr_proc_mutex_lock+0x60 ()
   from /opt/hpws/apache/lib/
#4  0xc000000001b72950:0 in apr_global_mutex_lock+0x90 ()
   from /opt/hpws/apache/lib/
#5  0xc000000001cf37d0:0 in do_post+0x780 ()
   from /opt/hpws/apache/modules/
#6  0xc000000001cf3d10:0 in specweb99_quick_handler+0x270 ()
   from /opt/hpws/apache/modules/
#7  0x4000000000059a80:0 in ap_run_quick_handler+0xc0 ()
#8  0x400000000004eb30:0 in ap_process_request+0x30 ()
#9  0x4000000000042610:0 in ap_process_http_connection+0x230 ()
#10 0x4000000000074670:0 in ap_run_process_connection+0xd0 ()
#11 0x4000000000074f00:0 in ap_process_connection+0xa0 ()
#12 0x4000000000051d40:0 in process_socket+0x200 ()
#13 0x4000000000052e90:0 in worker_thread+0x3b0 ()
#14 0xc000000001b6e2d0:0 in dummy_worker+0x50 ()
   from /opt/hpws/apache/lib/
#15 0xc0000000000a21a0:0 in __pthread_unbound_body+0x490 ()
   from /usr/lib/hpux64/

Any ideas ?

>-----Original Message-----
>From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) []
>Sent: Tuesday, December 02, 2003 9:07 AM
>To: '';
>Subject: RE: Regarding Apache 2.0.48 and specweb99
>>-----Original Message-----
>>From: []
>>I'm glad you're making progress.  But I'm wondering why 
>>raising the mod_cgid 
>>Listen backlog was so important.  If 100 mod_cgid connections 
>>wasn't enough at 
>>some point, either the workload is spikey or the steady state 
>>arrival rate of 
>>CGI requests is too fast for one daemon + your SPECweb99 CGI 
>>program to keep up.
>I was probably driving the server pretty hard for CGI's. The 
>avg. number of
>forks per second were around 15..20 - but often, the forks went up to
>35..40. It was a few times that the no. of forks went as high 
>as 90 - and
>soon, I started getting the 503 messages.
>I think the CGI daemon listen backlog can also be a 
>configurable number - I
>can post a patch if people think itz useful.
>>If the latter is true, you should see more and more CGI 
>>requests building up 
>>over time in server-status with ExtendedStatus on, and a big 
>>improvement in 
>>throughput if you set DYNAMIC_CGI_GET=0 in the SPEC rc file.
>Your evaluation is correct - the throughput definitely 
>improved when I set
>DYN_CGI to 0.. AND some cgi requests took as high as 900 ms 
>(the static file
>took 0.0 ms!!). 
>>Then it would be 
>>worthwhile using tusc/strace/truss with some timing options 
>>set to look for 
>>unnecessary delays in mod_cgid. 
>I can capture the tusc output from cgi daemon on the next run 
>and post it
>>If that doesn't show a problem, perhaps we 
>>should have multiple cgid daemons running in parallel for best 
>>Someone brought up that idea a while back on dev@httpd; 
>>cross-posting there.
>That's a pretty neat idea - I'll have to think about it.

View raw message