DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11460>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11460 httpd consuming all CPU time Summary: httpd consuming all CPU time Product: Apache httpd-2.0 Version: 2.0.39 Platform: PC OS/Version: FreeBSD Status: NEW Severity: Major Priority: Other Component: Core AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] I was running FreeBSD 4.6-RELEASE on one of my machines, with Apache 2.0.39. It worked flawlesly until recently, when I had upgraded my system do 4.6-STABLE (cvsupped Aug the 1th). I've noticed that from time to time one of the httpd processes starts consuming all CPU power; lsof'ing such process showed that it is not any kind of script, but just a normal request for some .zip file. Then I ran truss on it. Here's the result: writev(0x14,0x0,0x0) = 0 (0x0) writev(0x14,0x0,0x0) = 0 (0x0) writev(0x14,0x0,0x0) = 0 (0x0) writev(0x14,0x0,0x0) = 0 (0x0) writev(0x14,0x0,0x0) = 0 (0x0) ... and so on, like in some kind of infinite loop. writev() should return amount of written bytes.. in this case, writev() fails somehow to write anything (socket died?), but httpd seems to loop forever trying to send something. I do not handle .zip files in any special way, so I think it's rather a coincidence that it gets on them.. or maybe just becouse they tend to be big. I thought it may be a problem with some libraries, so I recompiled Apache - but it does not help in any way. The intriguing thing is that I cannot reproduce the bug - I ran 'ab' with 20 concurrent connections and 100k requests (for big .zip files) and it worked smoothly. I'm not sure what are the required contidions for that. I gcore'd the running httpd (it does not SEGV; it just runs). It's avalaible for download here: http://violent.dream.vg/stuff/smieci/httpd.core gdb httpd httpd.core didn't reveal anything particulary interesting. Just: #0 0x28256d08 in writev () from /usr/lib/libc.so.4 Which is what I already knew. I have log level set do "debug", but there's nothing special in error log - just the usufal stuff, like "socket not connected".. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
