Skip site navigation (1) Skip section navigation (2)

Re: shared_buffer value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Anjan Dave" <adave(at)vantage(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffer value
Date: 2004-01-16 00:51:55
Message-ID: 25927.1074214315@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Anjan Dave" <adave(at)vantage(dot)com> writes:
> Question is, does the 80MB buffer allocation correspond to ~87MB per
> postmaster instance? (with about 100 instances of postmaster, that will
> be about 100 x 80MB =3D 8GB??)

Most likely, top is counting some portion of the shared memory block
against each backend process.  This behavior is platform-specific,
however, and you did not tell us what platform you're on.

> Interestingly, at one point, we vacuumed the database, and the size
> reported by 'df -k' on the pgsql slice dropped very
> significantly...guess, it had been using a lot of temp files?

"At one point"?  If your setup doesn't include *routine* vacuuming,
you are going to have problems with file bloat.  This isn't something
you can do just when you happen to remember it --- it needs to be driven
off a cron job or some such.  Or use the contrib autovacuum daemon.
You want to vacuum often enough to keep the database size more or less
constant.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: SydDate: 2004-01-16 02:29:24
Subject: IDE/SCSI disk tools to turn off write caching
Previous:From: Richard HuxtonDate: 2004-01-16 00:17:42
Subject: Re: shared_buffer value

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group