DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39079>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39079 Summary: thread eats 100% CPU, presumably spinning in futex Product: Apache httpd-2 Version: 2.2.0 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: mod_cache AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] We run a number of reverse caching proxies. Basically mod_cache + mod_disk_cache + mod_proxy + mod_proxy_http, doing ProxyPass all in the worker mpm. compiled using: ./configure --prefix=/software/apache-cache-2.2.0 --with-mpm=worker --enable-cache --enable-mem-cache --enable-disk-cache --enable-proxy --enable-proxy-http --enable-proxy-ajp --enable-proxy-balancer --enable-rewrite --enable-mods-shared=all --enable-nonportable-atomics Recently we upgrade from 2.0.X to 2.2.0 In some of the webserver instances we see processes consuming 100% CPU time. When interrogated with ptrace, such a thread appears to be in a futex: Process 8329 attached - interrupt to quit futex(0xa83c9bf8, FUTEX_WAIT, 8361, NULL <unfinished ...> The webserver does not hang. I assume because it spawns another process that handles all new requests. apache status shows only 2 active threads in the old process: R.......W....................................................... I guess that 1 thread (the one you canb see in ptrace) is halted on the futex system call, and the other thread is spinning in the usermode part of a futex (and hence is not visible from ptrace) Unfortunately I cannot reproduce the bug, all I can do is wait until it happens again on a production server. However I've done some testing. Here are the results: * compiling with --enable-nonportable-atomics does nor make a differerence * using mem_cechc or disk_cache does not make a difference * compiling with the prefork mpm DOES appear to make a difference, I haven't seen prefork mpm's behaving like this (yet) Also, out of the 5 instances we run, 1 instance does not appear to have this problem (it has been running for ~3 weeks, whereas the others will show the problem within a couple of hours). Alle instances are moderately busy with anything between 100.000 and 10.000.000 hits per day. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
