httpd-2.0.54 on AIX5.2 with mod_status and ExtendedStatus on. Almost all traffic is generated by a custom module rather than static pages. Total traffic got up to at least 133GB and then quickly dropped to 114GB and then later to 76GB before the instance was restarted for module upgrade. I first suspected some sort of overflow condition, but value dropped many times more quickly than it went up so that's probably not the cause. Perhaps this is related to 25656, but doesn't quite seem to be the same either.
My initial report was a bit misleading in that one could assume I was implying that the traffic counter was going backwards. That is not the case. The traffic value seemed to be going up normally when watched for a short period of time, but at some point (overnight perhaps) would take significant downward jumps resulting in a quick overall downward trend. Thus the 133GB down to 76GB over perhaps 3 days. The Totals Accesses count seemed accurate. The server uses a piped logger for rotation so graceful restarts are not a factor.
This is a 64-bit build?
32 bit build. Compiler: IBM VAC 5.0.2. Worker MPM. Pretty stripped down configuration: just mod_status and mod_access plus our own module. Using piped logging.
Isn't this a limitation with all server-wide mod_status measurements, including CPU usage? As soon as a child process exits, such as when load subsides, that process's contribution to the server-wide measurements are lost.
That doesn't appear to be the case -- due to traffic spikes, processes are cycling on a regular basis and the Total Accesses and Total Traffic values were both going up normally, until Total Traffic reached somewhere around 133GB. The actual point at which it started going down is probably several GB (3-5 perhaps) higher. 133 is the last snapshot I have before it showed lower numbers. Even after the Total Traffic value went down, the Total Access count still appeared accurate causing the Average KB/request value to drop. I have verified that the processes are cycling as we log the PID -- Normally 1 worker process handles the load, but sometimes a second process is present in the log file for a while and then the original disappears. I'm not aware of any core dumps occurring.
Here's a couple snapshots from mod_status output showing the problem; this is actually after the value already dropped once from 50+GB: Current Time: Monday, 05-Dec-2005 19:48:59 CST Restart Time: Sunday, 20-Nov-2005 01:59:00 CST Parent Server Generation: 0 Server uptime: 15 days 17 hours 49 minutes 59 seconds Total accesses: 13150551 - Total Traffic: 33.3 GB CPU Usage: u19.11 s15.27 cu0 cs0 - .00253% CPU load 9.67 requests/sec - 25.7 kB/second - 2718 B/request 3 requests currently being processed, 12 idle workers Current Time: Tuesday, 06-Dec-2005 06:12:16 CST Restart Time: Sunday, 20-Nov-2005 01:59:00 CST Parent Server Generation: 0 Server uptime: 16 days 4 hours 13 minutes 15 seconds Total accesses: 13375508 - Total Traffic: 6.4 GB CPU Usage: u67.97 s50.52 cu0 cs0 - .00848% CPU load 9.57 requests/sec - 4932 B/second - 515 B/request 2 requests currently being processed, 13 idle workers Looks like some of the individual slot values are negative; Slot is the last column I've pasted here below: Srv PID Acc M CPU SS Req Conn Child Slot 0-0 - 0/0/419417 . 94.85 2103 32 0.0 0.00 -1983.29 0-0 - 0/0/419054 . 94.85 2103 101 0.0 0.00 -1965.49 0-0 - 0/0/419501 . 94.85 2103 103 0.0 0.00 -2001.22
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.