Thanks to all those who helped, especially John Eisenschmidt. I spoke with our resident Solaris guru (who runs a system here with ~25,000 user accounts) and he suggested lowering the MaxRequestsPerChild and MaxKeepAliveRequests directives to around 100 each (from my previous values of 300 and 200). The server is cycling through lots of http processes but the memory usage is nice and steady with no spikes. The apache processes don't live long enough to cause a problem anymore. Here's my original message: I'm probably overreacting, but one of my apache processes which peaked at 25% cpu usage (per top) still has as its "size" and "res" memory (per top) 3.6GB and 3.1GB respectively and vmstat is shoing intermittent high values (like 12976) in the "sr" field which according to the cockroft book is bad. Is this a memory leak in apache? I went deep into swap (3 GB) until I just killed that apache process, at which point all of its memory was freed up. Everything is happy again. This is on a 420r with 4gb of ram, 4x450 mhz running apache/mod_ssl/mod_perl/weblogic. This app does some very bulky things, like copy a 250MB directory on the filesystem to another directory at the will of the user, repeatedly, all day long. The apache process got out of control at about the same time that someone was doing this copy. One problem is that I'm just using the internal 36gb drives, mirrored with disksuite. I'm sure things would be faster with an A1000. At the rate that disk space is disappearing, I'm going to need something very soon. Anyway, what could have caused that apache process to take over all of the ram and a lot of CPU? Is there a workaround? Dave Lowenstein Programmer/Analyst Instructional Technology Services San Diego State University (619)594-0270 http://www-rohan.sdsu.edu/dept/its _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Sep 11 15:54:08 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:54 EST