Re: Setting Shared Buffers , Effective Cache, Sort Mem
| От | Tom Lane |
|---|---|
| Тема | Re: Setting Shared Buffers , Effective Cache, Sort Mem |
| Дата | |
| Msg-id | 6798.1082775014@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Setting Shared Buffers , Effective Cache, Sort Mem (Ron Mayer <rm_pg@cheapcomplexdevices.com>) |
| Ответы |
Re: Setting Shared Buffers , Effective Cache, Sort Mem
|
| Список | pgsql-performance |
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> [ on setting shared_buffers = half of RAM ]
> One minor detail... You wouldn't really cache the _exact_ same blocks
> because cache-hits in shared-buffers (on the most frequently accessed
> pages) would let the OS cache some other pages in it's cache.
> But in my experience Manfred's right that there's no benefit and
> some penalty to making shared_buffers so large it takes a significant
> piece away from the OS's caching.
True, it'd probably not be the *exact* worst case. But it'd be a good
approximation. In practice you should either bet on the kernel doing
most of the caching (in which case you set shared_buffers pretty low)
or bet on Postgres doing most of the caching (in which case you set
shared_buffers to eat most of RAM).
The conventional wisdom at this point is to bet the first way; no one
has shown performance benefits from setting shared_buffers higher than
the low tens of thousands. (Most of the mail list traffic on this
predates the existence of pgsql-performance, so check the other list
archives too if you go looking for discussion.)
It's possible that Jan's recent buffer-management improvements will
change the story as of 7.5. I kinda doubt it myself, but it'd be worth
re-running any experiments you've done when you start working with 7.5.
regards, tom lane
В списке pgsql-performance по дате отправления: