From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Michael van Rooyen <mvanr(at)bigfoot(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Kernel cache vs shared_buffers |
Date: | 2007-05-12 16:55:41 |
Message-ID: | 20070512165540.GD52939@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, May 12, 2007 at 03:28:45PM +0100, Heikki Linnakangas wrote:
> >In the case of it being disk-block based, my
> >inclination would be to let the kernel do the buffering. In the case of
> >the cache being table-row-based, I would expect it to be much more
> >space-efficient and I would be inclined to give the memory to the pg.
> >In that case, is it feasible to set shared_buffers to something like
> >500000 x 8k blocks? We make extensive use of indexes on the larger
> >tables and would seldom, if ever, do sequential scans.
>
> A common rule of thumb people quote here is to set shared_buffers to 1/4
> of available RAM, and leave the rest for OS cache. That's probably a
> good configuration to start with.
If you really care about performance it would be a good idea to start
with that and do your own benchmarking. Much of the consensus about
shared_buffers was built up before 8.0, and the shared buffer management
we have today looks nothing like what was in 7.4. You might find that
shared_buffers = 50% of memory or even higher might perform better for
your workload.
If you do find results like that, please share them. :)
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-05-13 01:32:29 | Re: Automatic adjustment of bgwriter_lru_maxpages |
Previous Message | Jim C. Nasby | 2007-05-12 16:51:18 | Re: estimating the need for VACUUM FULL and REINDEX |