From: | Sven Willenberger <sven(at)dmv(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: plperl doesn't release memory |
Date: | 2005-03-24 20:26:00 |
Message-ID: | 1111695960.11770.41.camel@lanshark.dmv.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2005-03-24 at 13:51 -0500, Tom Lane wrote:
> Sven Willenberger <sven(at)dmv(dot)com> writes:
> > On Thu, 2005-03-24 at 11:34 -0500, Tom Lane wrote:
> >> The first thing to figure out is whether the leak is inside Perl or in
> >> Postgres proper. If I were trying to do this I'd run the function a
> >> couple times, then attach to the (idle) backend with gdb and do
> >> call MemoryContextStats(TopMemoryContext)
>
> > Not sure entirely how to interpret the results ... a cursory examination
> > shows 516096 total in cachememory but I don't know if that reflects the
> > state of "unfreed" memory (or perhaps the 354728 used is unfreed?):
>
> That looks like the normal steady-state condition. The leak must be
> inside Perl then.
>
> [ thinks for a bit... ] Actually it seems possible that there's a
> problem with poor interaction between Postgres and Perl. During the SPI
> query they will both be making pretty substantial memory demands, and it
> could be that the underlying malloc library isn't coping gracefully and
> is ending up with very fragmented memory. That could result in
> out-of-memory problems when in fact neither package is leaking anything
> per se.
>
> What you probably ought to do next is build Postgres with a debugging
> malloc library to learn more about who's eating up what. I am not sure
> whether libperl will automatically use the malloc attached to the main
> executable or whether you need to whack it around too. (Come to think
> of it, doesn't Perl normally use its very own private malloc? Maybe
> there's an issue right there ...)
>
> regards, tom lane
>
Yes, on these systems, perl was build with -Dusemymalloc (and
concurrently -Ui_malloc) so there could very well be an issue with
malloc pools going awry. Doing a quick dig reveals that Linux tends to
build perl (by default) with the system malloc which may explain why
your script did not display this same behavior. I will try to rebuild
perl using system malloc and see how that affects things.
Sven
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Sugalski | 2005-03-24 20:36:46 | Re: plperl doesn't release memory |
Previous Message | Tom Lane | 2005-03-24 20:14:39 | Re: plperl doesn't release memory |