Hello all, I've been trying to track down a problem with mpm_worker and memory utilization for a few weeks now. I think I've narrowed it down (with the help of Novell) to newer versions of glibc. I'm currently running Apache 2.2.4 (but the problem exhibits itself on 2.0.58 as well) on Suse Linux Enterprise Server 10, SLES 9, Redhat AS 2.1, and Fedora Core 7. Novells suggestion is to just add more ram to the system, but that answer doesn't seem very elegant and I can't imagine I'm the first person to discover this issue. All of the systems are using the following Apache tuning settings, and Apache was complied from the source at apache.org. ServerLimit 80 ThreadLimit 64 StartServers 5 MaxClients 2000 MinSpareThreads 25 MaxSpareThreads 125 ThreadsPerChild 25 MaxRequestsPerChild 0 On the SLES 9 and Red Hat systems (glibc 2.3), 'ps -ea -o "pcpu,vsz,args,pagein" | grep -i httpd | grep -v grep' reveals that apache is using apx 313MB of ram. No problem here, about 2.5MB per thread. On the SLES 10 system (glibc 2.4), same Apache build and settings, I find that Apache is using apx 1179MB of ram, or about 9.25MB per thread. A 370% increase in memory utilization. This memory utilization can also be confirmed via top, free, or whatever other flavor of utility you would like to use. It gets even worse on Fedora Core 7 (glibc 2.6), as Apache is using 1425MB pf ram, or 11.4MB or ram per thread, a 456% increase over glibc 2.3. Google seaches using the various combinationsof the keywords Apache 2, glibc, and mpm_worker either return thousands of hits or nearly none. Is there a way to lower the memory utilization on newer versions of glibc (assuming the problem is glibc) beyond just lowering the number of spare threads Apache keeps alive? Thanks in advance, -Tim --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|