Re: shared_buffer value - Mailing list pgsql-performance

From Tom Lane
Subject Re: shared_buffer value
Date
Msg-id 25927.1074214315@sss.pgh.pa.us
Whole thread Raw
In response to shared_buffer value  ("Anjan Dave" <adave@vantage.com>)
List pgsql-performance
"Anjan Dave" <adave@vantage.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

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: shared_buffer value
Next
From: Syd
Date:
Subject: IDE/SCSI disk tools to turn off write caching