[dancer-users] Debugging memory leaks

[Zahir Lalani]

Confidential

Nice - thank you Andy

Z

> -----Original Message-----
> From: Andrew Beverley <andy at andybev.com>
> Sent: 30 March 2021 09:44
> To: Perl Dancer users mailing list <dancer-users at lists.preshweb.co.uk>
> Cc: Zahir Lalani <ZahirLalani at oliver.agency>; Perl Dancer users mailing list
> <dancer-users at dancer.pm>
> Subject: Re: [dancer-users] Debugging memory leaks
>
> On Mon, 29 Mar 2021 16:39:53 +0000 Zahir Lalani wrote:
> > That sounds like a memory leak, but I am not sure what tools can help
> > me in that regard. I assumed that Perl was quite good at cleanup, but
> > something is not right here.
>
> Have you tried to investigate whether it's a memory leak in the application
> itself? I've had a few of these over the years caused by circular references.
>
> They're tricky to debug, but generally I use Devel::Gladiator to dump the
> arena on each page request, and then compare them over time. If it's an
> application memory leak then you will see the counts consistently increasing
> for a particular object, which then helps to pin down the cause. If it's a Perl
> internal memory leak (which is
> unlikely) then the counts will remain consistent.
>
> The other thing to bear in mind, as I understand it, is that Perl will not release
> memory back to the operating system once used. It will, however, use it
> itself in the future. So if you have a process that uses a lot of memory and
> then releases it, the Perl process itself will not release that memory and
> instead it will be used for the application's other needs as it runs.
>
> Finally, you can dump the contents of the running process which may provide
> an insight into what is using the memory. You'll need to dump the contents
> with gdb:
>
>   gdb --pid=1234
>   (gdb) gcore
>   (gdb) detach
>   (gdb) exit
>
> Then see if something appears lots of times:
>
>   strings core.1234 | sort | uniq -c | sort -nr | less
>
> Andy