httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Tonhofer, m-plify S.A." <d.tonho...@m-plify.com>
Subject Re: [users@httpd] Serious Memory Leak Problem
Date Fri, 21 Oct 2005 16:57:29 GMT
I really don't know what the problem could be but let's
start a discussion:

1) How many children are there?
2) What is the sum of the processes RSS size?
3) What is the sum of the processes VSIZE size?

In other words, run this:




#!/usr/bin/perl -w

###################################################################################
# Hashtable holding the result of /proc inspection
###################################################################################

%extendedStatus = ();
$extendedStatus{"minor_faults"} = 0; # Sum over minor faults
$extendedStatus{"major_faults"} = 0; # Sum over major faults
$extendedStatus{"utime"}        = 0; # Sum over user time jiffies burnt
$extendedStatus{"stime"}        = 0; # Sum over kernel time jiffies burnt
$extendedStatus{"vsize"}        = 0; # Sum over virtual memory size in byte
$extendedStatus{"rss"}          = 0; # Sum over resident set sizes in byte (orig. in pages
= 4KB)
$extendedStatus{"children"}     = 0; # Will receive number of apache children

###################################################################################
# Subroutine that calls syslog, then calls die
###################################################################################

sub croak {
  my($msg) = @_;
  die "$msg\n";
}

###################################################################################
# Query the /proc filesystem. Return 1 if all went well, 0 otherwise. If a major
# problem occurs, the problem is logged to syslog, then die is called.
# Upon successful return, all the obtained values have been filled into
# %extendedStatus.
###################################################################################

sub obtainFromProc {
   my($server)  = @_;
   my($pidfile) = "/var/run/httpd.pid"; # System-specific
   if (!(-f $pidfile)) {
      croak("Could not find pidfile '$pidfile' - maybe the Apache server is not running?");
   }
   my($apachePid) = `cat $pidfile` or croak("Could not cat the pidfile '$pidfile': $!");
   chomp($apachePid);
   #
   # Obtain mother process values, using the same method as for the children
   #
   handleChild($apachePid);
   #
   # Apache does not use a threading model; instead it has a number of children that are
   # processes. Let's find all the processes that have as parent $pid and sum the required
   # values over these. We get the PIDs of these processes using an appropriate pd line
   #
   if (!open(PS,"ps --no-headers -eo ppid,pid |")) {
     croak(LOG_ERR,"Could not open pipe from 'ps'");
   }
   my(@ps) = <PS>;
   if (!close(PS)) {
     croak(LOG_ERR,"Could not close pipe from 'ps'");
   }
   my($line);
   foreach $line (@ps) {
     chomp($line);
     if ($line =~ /^\s*$apachePid\s+(\d+)/) {
       my($childPid) = $1;
       $extendedStatus{"children"}++;
       handleChild($childPid);
     }
   }
}

###################################################################################
# Process an apache child process.
# The values in %extendedStatus are updated
###################################################################################

sub handleChild {
   my($childpid) = @_;
   my($statfile) = "/proc/$childpid/stat";
   open(STATS,$statfile) or return; # Could happen that the process dies before we can read
   my($statline) = <STATS>;
   close(STATS) or return; # Could happen that the process dies before we can read
   chomp($statline);
   # Decompose the line of 'stat' into an array of values
   my(@statline) = ();
   while ($statline =~ /^\s*(\S+)(.*)$/) {
      push(@statline,$1);
      $statline = $2;
   }
   # Extract and add
   $extendedStatus{"vsize"}        += $statline[22]; # Virtual memory size in byte
   $extendedStatus{"rss"}          += $statline[23]*4*1024; # Resident set size in byte (orig.
in pages = 4KB)
   $extendedStatus{"minor_faults"} += $statline[9];
   $extendedStatus{"major_faults"} += $statline[11];
   $extendedStatus{"utime"}        += $statline[13];
   $extendedStatus{"stime"}        += $statline[14];
}

#
# Gather from /proc as needed, may die - or fills in %extendedStatus
#

obtainFromProc();
print $extendedStatus{"minor_faults"} . " minor faults so far\n";
print $extendedStatus{"major_faults"} . " major faults so far\n";
print $extendedStatus{"utime"}        . " user time jiffies burnt so far\n";
print $extendedStatus{"stime"}        . " kernel time jiffies burnt so far\n";
print $extendedStatus{"vsize"}        . " bytes of allocated virtual memory\n";
print $extendedStatus{"rss"}          . " bytes of resident memory allocated\n";
print $extendedStatus{"children"}     . " children active right now\n";






--On Friday, October 21, 2005 9:19 AM -0700 Marc Perkel <marc@perkel.com> wrote:

> I've asked about this before and never got an answer. I used to run my server on a dual
xeon computer and it was very memory efficient. I moved to the 64 bit version of of Fedora
Core 4 and now it's filling up memory really fast.
>
> Both servers had 4 gigs of ram. And basically the same configuration file using the same
modules for both. It is especially bad where perl is involved.
>
> Now I have to set MaxRequestsPerChild to no more than 10 to keep ram from filling up.
 The server is rather busy serving 67 requests per second.  If I set MaxRequestsPerChild to
30 - it quickly fills up another gig of ram.
>
> I really need to fix this. Sure could use some help on trying to figure out where the
problem is.
>
> Thanks in advance.
>


---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message