Re: [users@httpd] Serious Memory Leak Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux