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.


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
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

Thanks

Justin
(ps this is sent from my work account for this mailing list 
justin.wyl...@sophos.com )









> 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

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

Reply via email to