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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Syd | 2004-01-16 02:29:24 | IDE/SCSI disk tools to turn off write caching |
Previous Message | Richard Huxton | 2004-01-16 00:17:42 | Re: shared_buffer value |