huge httpd processes

huge httpd processes

am 28.09.2009 21:19:03 von Justin Wyllie

This is a multi-part message in MIME format.

------=_NextPart_000_00BE_01CA4078.EBF16740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I've been attempting to fine-tune my server.

The apache/mod_perl processes are around 90 Mbs - to start with.=20

I've preloaded a lot of code in the startup file and that makes the =
shared memory space about 6 Mb. I can now see how my processes do not =
grow due to code being loaded when it is requested.=20

But I'm struggling to understand why my processes are so huge. Using top =
with the DATA field that shows that almost all the 90 mbs is data not =
executable code. If this is the correct interpretation of that? (Indeed =
it looks like it is swapping straight away as in some cases the data is =
greater than the resident memory and must therefore be in virtual =
memory).=20

There is some convoluted code which loads 16 mbs of data into memory =
when it serves a request - which I have not yet tracked down. (It is a =
complicate custom searching application ....) but the processes start at =
90 Mb even before this.

I'm wondering if anyone can advise me on how I could go about trying to =
understand where this 90 Mbs is comming from? Some of it must be the =
mod_perl and apache binaries - but how much should they be, and apart =
from the 6mb in shared memory for my pre-loaded modules, where is it all =
comming from?

many thanks

Justin Wyllie
------=_NextPart_000_00BE_01CA4078.EBF16740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



http-equiv=3DContent-Type>





Hi

 

I've been attempting to fine-tune my=20
server.

 

The apache/mod_perl processes are =
around 90 Mbs -=20
to start with.

 

I've preloaded a lot of code in the =
startup file=20
and that makes the shared memory space about 6 Mb. I can now see =
how my=20
processes do not grow due to code being loaded when it is requested.=20

 

But I'm struggling to understand why my =
processes=20
are so huge. Using top with the DATA field that shows that almost all =
the 90 mbs=20
is data not executable code. If this is the correct interpretation of =
that?=20
(Indeed it looks like it is swapping straight away as in some cases the =
data is=20
greater than the resident memory and must therefore be in virtual =
memory).=20

 

There is some convoluted code which =
loads 16 mbs of=20
data into memory when it serves a request - which I have not yet tracked =
down.=20
(It is a complicate custom searching application ....) but the processes =
start=20
at 90 Mb even before this.

 

I'm wondering if anyone can advise =
me on how I=20
could go about trying to understand where this 90 Mbs is comming=20
from?
 Some of it must be the =
mod_perl and=20
apache binaries - but how much should they be, and apart from the 6mb in =
shared=20
memory for my pre-loaded modules, where is it all comming =
from?

 

many thanks

 

Justin =
Wyllie


------=_NextPart_000_00BE_01CA4078.EBF16740--

Re: huge httpd processes

am 28.09.2009 21:31:30 von Igor Chudov

--0015175d026c42001b0474a85896
Content-Type: text/plain; charset=ISO-8859-1

Justin, I cannot have a good suggestion how to find out what hogs the
memory.

However, I want to mention that with the use of a good reverse proxy server,
you will not need to have very many apache instances running, because the
proxy server would take care of the slow interaction with the client's
browser.

I use perlbal and I am happy, but there are other alternatives. During
evening, when I get 35 or so object requests per second, I rarely see more
than 1-2 instances of apache actually working at any given moment. At the
same time, my reverse proxy is talking to perhaps 10-50 clients, but apache
does not know.

Igor

--0015175d026c42001b0474a85896
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Justin, I cannot have a good suggestion how to find out what hogs the memor=
y.

However, I want to mention that with the use of a good reverse p=
roxy server, you will not need to have very many apache instances running, =
because the proxy server would take care of the slow interaction with the c=
lient's browser.


I use perlbal and I am happy, but there are other alternatives. During =
evening, when I get 35 or so object requests per second, I rarely see more =
than 1-2 instances of apache actually working at any given moment. At the s=
ame time, my reverse proxy is talking to perhaps 10-50 clients, but apache =
does not know.


Igor


--0015175d026c42001b0474a85896--

Re: huge httpd processes

am 28.09.2009 21:39:12 von Perrin Harkins

On Mon, Sep 28, 2009 at 3:19 PM, Justin Wyllie
wrote:
> But I'm struggling to understand why my processes are so huge. Using top
> with the DATA field that shows that almost all the 90 mbs is data not
> executable code. If this is the correct interpretation of that?

Probably not. Perl code looks like data to the OS.

> There is some convoluted code which loads 16 mbs of data into memory when=
it
> serves a request - which I have not yet tracked down. (It is a complicate
> custom searching application ....) but the processes start at 90 Mb even
> before this.

Loading data from files or a database often accounts for large process
sizes. You may need to learn more about how your DBD driver uses RAM.
Most of them will load the entire result set into local RAM unless
you tell them not to.

> I'm wondering if=A0anyone can advise me on how I could go about trying to
> understand where this 90 Mbs is comming from?

Do a binary search on your modules, i.e. comment out pre-loading for
half of them, and then half again until you zero in on what's causing
the size. You might start by not pre-loading anything and see what
your baseline size is for apache/mod_perl.

- Perrin

Re: huge httpd processes

am 29.09.2009 10:38:05 von Clinton Gormley

Hi Justin

>
> I'm wondering if anyone can advise me on how I could go about trying
> to understand where this 90 Mbs is comming from? Some of it must be
> the mod_perl and apache binaries - but how much should they be, and
> apart from the 6mb in shared memory for my pre-loaded modules, where
> is it all comming from?

You don't mention what platform you are on, but if it is linux, then
check out this blog

http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps. html

and specifically this script

http://www.contrib.andrew.cmu.edu/%7Ebmaurer/memory/smem.pl


which will give you a much more accurate idea about how much memory is
shared and where it is being used.

As Perrin said, Perl data and code both go on the heap, so you won't be
able to separate those two out with this tool, but combining smem.pl
with loading modules one by one will get you a long way to a diagnosis.

clint

Re: huge httpd processes

am 29.09.2009 11:06:10 von torsten.foertsch

On Tue 29 Sep 2009, Clinton Gormley wrote:
> > I'm wondering if anyone can advise me on how I could go about
> > trying to understand where this 90 Mbs is comming from? Some of it
> > must be the mod_perl and apache binaries - but how much should they
> > be, and apart from the 6mb in shared memory for my pre-loaded
> > modules, where is it all comming from?
>
> You don't mention what platform you are on, but if it is linux, then
> check out this blog
>
> =A0 =A0http://bmaurer.blogspot.com/2006/03/memory-usage-with-sma ps.html
>
> and specifically this script
>
> =A0 =A0http://www.contrib.andrew.cmu.edu/%7Ebmaurer/memory/smem. pl
>
>
> which will give you a much more accurate idea about how much memory
> is shared and where it is being used.

But keep this in mind:

http://search.cpan.org/~opi/Linux-Smaps-0.06/lib/Linux/Smaps .pm#A_special_n=
ote_on_copy_on_write_measurements

There is another device that could be helpful. On newer kernels (don't=20
remember when) there is a "Referenced" field in /proc/PID/smaps. It=20
counts the kilobytes accessed since the last write=20
to /proc/PID/clear_refs (or since the start of the program).

Torsten

=2D-=20
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net