APM: Debugging memory leak

Mark Lehmann mlehmann at marklehmann.com
Wed Jul 9 15:56:10 CDT 2003


That's a good idea if performance of the job is not an issue.  If this is an
often repeated operation (several times a second), the forks could slow
things down.  However, the forking solution is pretty sweet.

>>>>> "BR" == Bill Raty <bill_raty at yahoo.com> writes:

BR> Mark,
BR> Couldn't one do a fork for those sections of code that are used
BR> temporarily and might alloc lots of mem?  

BR> Regards,

BR> -Bill

BR> --- Mark Lehmann <mlehmann at marklehmann.com> wrote:
>> Remember that Perl (like other VM based languages) don't give
>> memory back
>> once they've requested it from the operating system.  So a
>> one time load of
>> data from disk to memory and back to disk again might request
>> memory from the
>> OS and keep it if the disk to disk copy needed more memory
>> temporarily.
>> 
>> In those cases you need to use things like sysread and read
>> which take byte
>> sizes and only process a small chunk at a time.  It can be
>> inconvenient to
>> code that way if you want to parse data.
>> 
>> >>>>> "WW" == Wayne Walker <wwalker at broadq.com> writes:
>> 
WW> I don't know of any memory monitoring stuff in perl, but
>> it may be
WW> there.
>> 
WW> I would start by generating log output that prints a line
>> every time you
WW> use significant memory.
>> 
WW> While looking at the code to see where you use
>> significant memory you
WW> may find the culprit.
>> 
WW> Otherwise you may see in the log that something you
>> thought wasn't
WW> called often is.
>> 
WW> On Tue, Jul 08, 2003 at 11:48:25PM -0500, Evan Harris
>> wrote:
>> >> 
>> >> Is there a way to track where memory is being used in a
>> large
>> >> long-running perl program?
>> >> 
>> >> I have a program that after about 6 hours has leaked about
>> 200meg of memory,
>> >> and I can't figure out why.  It started doing this after
>> an upgrade from
>> >> perl 5.6.1 to 5.8.
>> >> 
>> >> I'd like to be able to get some sort of stats on which
>> modules what amount
>> >> of the memory is being used in, so I can figure out where
>> to start trying to
>> >> fix it.
>> >> 
>> >> Any suggestions would be appreciated.
>> >> 
>> >> Evan
>> >> 
>> >> _______________________________________________
>> >> Austin mailing list
>> >> Austin at mail.pm.org
>> >> http://mail.pm.org/mailman/listinfo/austin
>> 
WW> -- 
>> 
WW> Wayne Walker
>> 
WW> www.broadq.com :)  Bringing digital video and audio to
>> the living room
WW> _______________________________________________
WW> Austin mailing list
WW> Austin at mail.pm.org
WW> http://mail.pm.org/mailman/listinfo/austin
>> 
>> -- 
>> Mark Lehmann
>> email mlehmann at marklehmann.com | phone 512 689-7705
>> _______________________________________________
>> Austin mailing list
>> Austin at mail.pm.org
>> http://mail.pm.org/mailman/listinfo/austin

BR> _______________________________________________
BR> Austin mailing list
BR> Austin at mail.pm.org
BR> http://mail.pm.org/mailman/listinfo/austin

-- 
Mark Lehmann
email mlehmann at marklehmann.com | phone 512 689-7705



More information about the Austin mailing list