os-windows/4758: Apache grabs 100% CPU on Windows NT.

[Apache BugReporter <ap...@iname.com>]

>Number:         4758
>Category:       os-windows
>Synopsis:       Apache grabs 100% CPU on Windows NT.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Jul 23 10:10:02 PDT 1999
>Last-Modified:
>Originator:     apachebug@iname.com
>Organization:
apache
>Release:        1.3.6
>Environment:
Windows NT Server 4.0 SP4
System runs:
Apache 1.3.6 for regular web access (400,000 hits/day)
FastTrack for secure access (probably 20,000 hits/day)
Oracle Client for dbase access.
Note:
1) All html web page accesses are handled by CGI, responses are
typically 6Kbytes - 30Kbytes, but can occasionally go up to 
200Kbytes.
2) Secure web page accesses are handled by CGI, which typically
connects to dbase.
>Description:
Similar problems reported in PR #4245, PR #4430, PR #4753.

Previous versions of Apache did not have this problem, but 1.3.6
can grab 100% of the CPU and hold it forever, after running for
a period of time (I haven't seen it do this without running fine for at
least half an hour before).  Oddly enough I've gone through 
periods of days without this occurring, but then it'll start
happening several times a day, forcing me to kill Apache and start
it again.  When Apache has 100% of the CPU, web accesses are typically
delayed by 2 to 3 seconds, but continue to get served.

Responding to comments in PR #4245, PR #4430, PR #4753:
Q: What is MaxRequestsPerChild set to? I suggest you set it to 0.
A: It is set to 0.

Q: How much data does each CGI serve up, in the typical case? in the extreme case?
A: Typical: 6K - 30K.  Extreme: 200K.

Q: How many concurrent clients are active at once? If you find 
you are have about as many concurrent clients as your ThreadsPerChild 
setting, you should 1. increase ThreadsPerChild and 2. decrease 
KeepAliveTimeout or disable it entirely and see if that helps.
A: Several concurrent clients.  ThreadsPerChild is much higher at 128.

Q: How much data do your CGI's typically serve? Are they invoked
in response to a POST (FORM submit)? If so, how much data is
POST'ed?  
A: Answered above.  Some are in response to post (most with very
little data, a few dozen bytes).  A very few (less than a dozen
posts per day) are for larger amounts, at most 6Kbytes.

Q: When the problem is encountered, does Apache quite serving 
ALL requests, or just the request that is hanging? 
A: I don't know if it stops serving a particular request (when
the problem occurred first for example), but it does continue
serving requests.

Q: What is MaxRequestsPerChild set to? Do you notice the 
problem after doing a restart (apache -k restart)?
A: MaxRequestsPerChild is set to 0.  The problem just occurred
now, I have Apache 1.3.6 running in a command window, executed
as "apache -s".  I started up performance monitor.  The parent
process seems to have one thread, the child process 129.
I then ran "apache -k restart" in a separate command window.  The
child threads dropped from 129 down to 2.  Apache was still grabbing
100% CPU.  There are now three Apache processes visible in the 
Task Manager.  After 2 or 3 minutes, Apache returned to 129 threads,
and the CPU dropped to normal levels (bobbing between 5-25% CPU),
and the third Apache process disappeared, leaving just two Apache
processes.  Oddly enough, when Apache dropped down to 2 threads,
the site was still processing requests, and using my browser indicated
no obvious problems in access (other than the 2-3 second delay due
to the 100% CPU).
>How-To-Repeat:
It repeats continually on my server... :-(
No, I don't know how to repeat it deterministically.
>Fix:
It looks like a thread or two is grabbing the CPU.
The problem doesn't seem to exist in previous 1.3.X versions
of Apache, since the identical site was running on
them without problem.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]