Re: BUG #4996: postgres.exe memory consumption keeps going up

On 19/08/2009 11:50 PM, Shivesh Wangrungvichaisri wrote:
>
> The following bug has been logged online:
>
> Bug reference:      4996
> Logged by:          Shivesh Wangrungvichaisri
> Email address:      sbw@appsig.com
> PostgreSQL version: 8.3.7

I ran your test program on 8.4.0 (not 8.3.7 as you used), and didn't
find any sign of a leak in the backends (postgres.exe).

Interestingly, though, the test program does appear to be leaking - at
least, the peak working set slowly climbs. It's all private working set.
Not sure why yet since the memory use looks like it _should_ be constant.

Re the backends, the shared working set on each postgres.exe backend
goes up until each backend has touched all the shm it'll ever touch, at
which point the backends' usage stabilizes. I see no sign of a leak.

Have you perhaps tried to configure WAY too much shared memory? How much
RAM does your test machine have? Can you post all uncommented lines from
your postgresql.conf ?

For the next thing you need to check you'll need Process Explorer.
Install it and the rest of the sysinternals suite if you don't have it
yet, it's a VITAL windows admin tool:

http://technet.microsoft.com/en-gb/sysinternals/bb842062.aspx


Please launch Process Explorer and then your test program. Double-click
on the postgres.exe backends to open info windows for them and do the
same for the test program. Take a screenshot (windows-prtscrn) and save
it. Let the test run a while and do the same thing occasionally to keep
a record. If/when a backend crashes save the windows event log and the
postgresql log. Upload the lot as a zip file somewhere accessible and
post a report on what happened.

I'll try to figure out why your test program appears to be leaking (or
just using more memory with time). libpq and friends were built with
MSVC7 and I'm using MSVC9 for the test program so there are two
different runtimes linked to the program, but there aren't any FILE
pointers being passed around, no memory is allocated in one module and
freed in another, etc, so I'm not sure where it's going yet. Valgrind
doesn't support Windows and all the Windows leak-checking tools cost
$LOTS so I can't just hook it up to a heap analyzer / leak checker. Sigh.

--
Craig Ringer