Hi clint
Yes. Linux and this script looks good. We've think that part of the problem
is in the modules Apache is loading so this will be useful.
I also have another couple of questions:
I have found the errant code where our process jumps by 13 Mbs. One part
does something like this:
$file_handle->read($s, $length); #$s is about 1/2 Mb
@data = unpack($format , $s);
##at this point memory usage jumps by 8 Mbs (measured using GTop->size() )
while (@data) {
push @data2, [shift @data, shift @data, shift @data] ; # this isn't exact
but it looks like each element of @data2 becomes a reference to a 3 element
array - i.e the binary data was stored in triplets
}
#this loop causes another jump of 4 Mbs
return \...@data2;
I tried undef'ing @data just before the return as it is no longer used but
this only gained me 1/2 Mb. I would have expected to get all 8Mbs back. I
don't understand why not.
Also - in general terms if you do something like this (simplified):
package MyHandler;
use MyClass;
sub handler {
my $obj = MyClass->new();
}
.......
package MyClass;
our $var;
sub new() {
$var = "hello world";
}
\Since the module containing the package MyClass is loaded into the
apache/mod_perl process does $var ever go out of scope once set? I think
not - and it's memory is never freed? if this is correct and I used my
instead even then would it go out scope ?
Thank you for your patience.
regards
Justin
> 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
