Received: (qmail 14214 invoked by uid 500); 11 Jun 2000 21:14:52 -0000 Message-Id: Date: Sun, 11 Jun 2000 16:14:40 -0500 (EST) From: David Ernst To: james@jamesarmstrong.com, apbugs@apache.org Cc: Michael Chui , info@bloomington.in.us Subject: Problem, possibly related to ticket 4642 >Number: 6176 >Category: os-linux >Synopsis: Large memory growth, followed by occaisonal server failures >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sun Jun 11 14:20:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: james@jamesarmstrong.com >Release: 1.3.6 (default version for redhat 6.0) >Organization: apache >Environment: Standard out-of-the-box RedHat Linux 6.0. Apache is the version delivered with RH 6.0. >Description: We have observed that the version of apache that was installed with RedHat 6.0 will experience growth of the shared memory segment; we have seen shared segments in sizes exce eding 100 Mbytes in less than 5 hours of operation. Nightly, when we rotate logs, we would perform a kill -HUP to start a new logfile; this would freeze or crash the server (Dell Pentium Pow eredge 4300 single processor with 256 MBytes RAM, 512 MByte configured swap, 18 Gbytes RAID 5 using RedHat drivers.) I did not see anything in the bug database for this, although I did see some si milar on Solaris. >How-To-Repeat: If needed, I can provide a copy of our httpd.conf file, we do virtual hosting f or several domains. >Fix: >Release-Note: >Audit-Trail: >Unformatted: Hello, we've been having quite a bit of trouble with our apache v 1.3.6 running on redhat linux 6.0. The problem sounds a great deal like what is being described below. We believe we have learned something about the problem, and that is that sending multiple HUP signals to httpd in relatively rapid succession seems to cause httpd to grow very quickly in size, in many cases causing the machine to effectively crash and require reboot. We first discovered this through a monthly log rotating script which we wrote ourselves and used happily on our redhat 5.1 system. The script rotates over 100 httpd access logs (doing some log analysis on each one) and sends a HUP to httpd for EVERY ONE of the log files. Once we had the suspicion, I sat at my command line as root and repeatedly typed killall -HUP httpd Perhaps I sent two of these commands per second for about 10 seconds. Sure enough, ps aux started reporting that httpd had doubled in size. If I left it alone, it would not grow any further. But as soon as I started sending it HUP signals again, the memory would grow furthermore. Naturally, stopping the daemon and restarting it "fixed" the problem, ie, ps aux once again showed the standard httpd footprint. We have modified our scripts to send fewer HUPs, and I suspect we will no longer have any problem with this. All the same, it would be nice to know that someone is addressing it, and that we may have played a part in getting it fixed. Thanks, David Ernst HoosierNet, Inc. ---------------------------------------------------------------------- Full text of PR number 4642: Received: (qmail 15143 invoked by uid 2012); 24 Jun 1999 00:33:01 -0000 Message-Id: <19990624003301.15142.qmail@hyperreal.org> Date: 24 Jun 1999 00:33:01 -0000 From: James@hyperreal.org, C.Armstrong@hyperreal.org, Jr. Reply-To: james@jamesarmstrong.com To: apbugs@hyperreal.org Subject: Large memory growth, followed by occaisonal server failures X-Send-Pr-Version: 3.2 [In order for any reply to be added to the PR database, you need] [to include 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! ]