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 по дате отправления: