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.