|more apache memory leaks||topic started 10/19/2006; 3:54:48 PM
last post 10/19/2006; 3:54:48 PM
|Gavin LaRose - more apache memory leaks
10/19/2006; 3:54:48 PM (reads: 136, responses: 0)
This may be a follow-up to Bob Byerly's existing discussion thread on apache memory leaks. Yesterday and today we went through a harrowing set of server crashes that appear to be due to growing apache processes, which leads me to reopen the discussion.
This is the first semester we've had a problem with this. Last term we were running WeBWorK on a two-processor Sparc with 8GB of RAM, running Solaris. This semester we've moved to a four (dual-core) processor 64bit Xeon with 12GB of RAM, running RedHat Enterprise 4. We're running WeBWorK out of CVS, slightly ahead of the 2.3 release. All of the problem sets are the same as last semester save for minor edits, though some of the problems are making more use of the Parser. We're running apache 1.3.34. We have about 1500 students taking gateway tests and about 3000 working on homework with staggered deadlines.
The system crashes occurred when apache httpd processes steadily grew in size until they exhausted both available memory and (8GB of) swap. By resetting MaxRequestsPerChild down to 100 (KeepAlive is On, with KeepAliveRequests = 100, so we're processing up to 10,000 http requests per child before terminating it) we appear to be fairly stable with httpd processes averaging between 60 and 100MB in size.
The thing that surprises me is that this became a problem when it wasn't before. Is anyone out there running on similar hardware/software configuration? If so, have you seen any similar problem? I wasn't aware of Linux having any significant trouble with this type of memory leak, so it caught me by surprise.
It could, of course, be that I've just got a bug in some problem that's being worked now, but in that we didn't see the problems last semester I'm not convinced that's what going on.
Any insight that anyone can offer would be welcomed! I'm hoping to avoid having to come in this evening to deal with another server crash.