Re: ***UNCHECKED*** Re: memory leak occur when disconnect database

On Tue, 2009-07-21 at 19:39 +0900, tanjunhua wrote:
> I'm sorry for the twice action. because the mail server reject my response.
> I should compress it with ciper code(111111) and the execute program is
> compressed also.

When I build your example from source I see no indication of anything
wrong here, just the usual tls services cache. I can't run your supplied
binary as my libpq and libecpg aren't binary compatible with Pg 8.1's .

I'm a bit confused, though. Your top results don't show your "test"
program at all, nor do they show valgrind. Did you run it under a
different name? Or are you saying something else is leaking _because_ of
your test program? Is there any chance that you are referring to a
memory leak in the BACKEND (postgresql its self) rather than your test
program?

There is no evidence in the valgrind report you provided for any
significant memory leak in your test program. See the summary:

==27043== LEAK SUMMARY:
==27043==    definitely lost: 36 bytes in 1 blocks.
==27043==    indirectly lost: 120 bytes in 10 blocks.
==27043==      possibly lost: 0 bytes in 0 blocks.
==27043==    still reachable: 34,535 bytes in 27 blocks.
==27043==         suppressed: 0 bytes in 0 blocks.

I'm a bit puzzled about why you have three "postmaster" instances shown
as running. If that's really the case then something is horrifically
badly broken. How do you stop and start PostgreSQL? How did you install
it - from Debian packages provided as part of etch, or some other way?

$ grep postgres top_result_after_1_hour
2436 postgres 25 0 17928 3628 3128 S 0.0 2.0 3:01.17 postmaster
2444 postgres 15 0 17928 6756 6224 S 0.0 3.8 0:00.00 postmaster
2787 postgres 17 0 18492 2704 1812 S 0.0 1.5 0:00.00 postmaster

Your processes also have weird priority values. You're on Debian 4.1
(etch), and I wouldn't expect to see any funky process priorities there.
Do you know why they are set the way they are? Have you customised the
Etch install in any weird ways?

Right now, you've just got me confused. I don't see evidence of a leak
in the valgrind report you sent, your postmasters(!!) aren't increasing
in memory use over time, and I have absolutely no idea what is
supposedly leaking.

If you mean the fact that "top" shows:

Mem:    177744k total,   125064k used,    52680k free,     5936k buffers

then later:

Mem:    177744k total,   130884k used,    46860k free,    10240k buffers

that's because Linux is using more memory for cache. (Also, what kind of
database server is this thing, with only 192MB of RAM? Some kind of
embedded device?)

On my laptop for example, top shows:

Mem:   3613212k total,  3505200k used,   108012k free,   103344k buffers

but I promise I don't have 3.5 GB of programs and program data resident
in memory. Rather, as `free -m' shows, Linux is using most of this
memory for cache:

craig@ayaki:~/Desktop/x/memory leak/output$ free -m
         total       used       free     shared    buffers     cached
Mem:      3528       3426        101          0        100       2853
-/+ buffers/cache:    473       3055
Swap:      956          1        955

so in fact the machine has 3055 MB of RAM "free" for use if a program
requires it, though in the mean time the kernel is using most of it to
cache programs and other files from the disk. The "free" number will
decrease continuously from its high point when the system has just
booted until it reaches a point where the kernel decides it has enough
cached and wants to keep a little bit of memory really free in case
something needs it.


I also want to pre-empt another common question while we're talking
about memory use. You may later notice a postgres backend consuming more
and more memory during a long-lived connection even if that connection
regularly commits / rolls back and returns to idle. This is NORMAL - and
the backend isn't really using more memory at all, it's just how Linux
reports the memory usage of programs that use shared memory.


(In your valgrind report, rather than the absent leak what's more
interesting is the list of errors valgrind reports. Your name service
switch looks like it might be doing something unsafe, though it's
presumably getting away with it or you'd REALLY know about it. It's not
related, in any case.)

--
Craig Ringer