perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Wyllie <>
Subject huge httpd processes
Date Wed, 30 Sep 2009 14:00:03 GMT
Hi clint

This script looks helpful. I don't completely understand (even after looking at the documentation
for Linux::Smaps) it though

Looking at this output:

##before a bit hit on an expensive part of the web site
VMSIZE:     119472 kb
RSS:         96184 kb total
             94904 kb shared
               176 kb private clean
              1104 kb private dirty

##after said hit
VMSIZE:     120408 kb
RSS:         98876 kb total
             89136 kb shared
               324 kb private clean
              9416 kb private dirty

What this seems to tell me is:

i. The total VIRT size of the process before was 119 Mb
ii. Before - the process shared 94 Mb with other processes
iii. After - shared has gone down and private dirty up - does this mean that this process
now 'owns' this memory and it can't be used by other processes?

The other thing which confuses me is that this seems to be completely different from TOP.

16210 apache    16   0  117m  97m 4788 S  0.0  9.6   0:01.04 httpd

In particular TOP'S concept of SHR seems to be completely different from Smap's.

Do either of these bear any relation to mod_perl's shared memory which you can use by preloading
modules at startup?

Sorry; I am  a complete beginner at this


(ps this is sent from my work account for this mailing list )

> 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
> and specifically this script
> 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
> with loading modules one by one will get you a long way to a diagnosis.
> clint

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

View raw message