Re: Memory Leakage Problem - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Memory Leakage Problem
Date
Msg-id 1133891282.11803.7.camel@state.g2switchworks.com
Whole thread Raw
In response to Memory Leakage Problem  (Kathy Lo <kathy.lo.ky@gmail.com>)
List pgsql-performance
On Tue, 2005-12-06 at 03:22, Kathy Lo wrote:
> Hi,

>
> In this program, it will access this database server using simple and
> complex (joining tables) SQL Select statement and retrieve the matched
> rows. For each access, it will connect the database and disconnect it.
>
> I found that the memory of the databaser server nearly used up (total 2G RAM).
>
> After I stop the program, the used memory did not free.

Ummmm.  What exactly do you mean?  Can we see the output of top and / or
free?  I'm guessing that what Tom said is right, you're just seeing a
normal state of how unix does things.

If your output of free looks like this:

-bash-2.05b$ free
      total       used       free     shared    buffers     cached
Mem:6096912    6069588      27324          0     260728    5547264
-/+ buffers/cache:     261596    5835316
Swap:      4192880      16320    4176560

Then that's normal.

That's the output of free on a machine with 6 gigs that runs a reporting
database.  Note that while it shows almost ALL the memory as used, it is
being used by the kernel, which is a good thing.  Note that 5547264 or
about 90% of memory is being used as kernel cache.  That's a good thing.

Note you can also get yourself in trouble with top.  It's not uncommon
for someone to see a bunch of postgres processes each eating up 50 or
more megs of ram, and panic and think that they're running out of
memory, when, in fact, 44 meg for each of those processes is shared, and
the real usage per backend is 6 megs or less.

Definitely grab yourself a good unix / linux sysadmin guide.  The "in a
nutshell" books from O'Reilley (sp?) are a good starting point.

pgsql-performance by date:

Previous
From: Ameet Kini
Date:
Subject: postgresql performance tuning
Next
From: Tom Lane
Date:
Subject: Re: TSearch2 vs. Apache Lucene