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 /usr/lib/hpux64/libc.so.1 (gdb) bt #0 0xc000000000306850:0 in _semop_sys+0x30 () from /usr/lib/hpux64/libc.so.1 #1 0xc000000000314b50:0 in semop+0xb0 () from /usr/lib/hpux64/libc.so.1 #2 0xc000000001b73220:0 in proc_mutex_sysv_acquire+0x70 () from /opt/hpws/apache/lib/libapr-0.sl.9 #3 0xc000000001b73fc0:0 in apr_proc_mutex_lock+0x60 () from /opt/hpws/apache/lib/libapr-0.sl.9 #4 0xc000000001b72950:0 in apr_global_mutex_lock+0x90 () from /opt/hpws/apache/lib/libapr-0.sl.9 #5 0xc000000001cf37d0:0 in do_post+0x780 () from /opt/hpws/apache/modules/mod_specweb99.so #6 0xc000000001cf3d10:0 in specweb99_quick_handler+0x270 () from /opt/hpws/apache/modules/mod_specweb99.so #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/libapr-0.sl.9 #15 0xc0000000000a21a0:0 in __pthread_unbound_body+0x490 () from /usr/lib/hpux64/libpthread.so.1 Any ideas ? -Madhu >-----Original Message----- >From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED] >Sent: Tuesday, December 02, 2003 9:07 AM >To: 'dev@httpd.apache.org'; [EMAIL PROTECTED] >Subject: RE: Regarding Apache 2.0.48 and specweb99 > > > >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >[SNIP] > >>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 >here. > >>If that doesn't show a problem, perhaps we >>should have multiple cgid daemons running in parallel for best >>throughput. >>Someone brought up that idea a while back on [EMAIL PROTECTED]; >>cross-posting there. > >That's a pretty neat idea - I'll have to think about it. > >-Madhu >
