Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Дата
Msg-id 20130910012907.GF32173@momjian.us
обсуждение исходный текст
Ответ на Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Thu, Sep  5, 2013 at 09:02:27PM -0700, Josh Berkus wrote:
> On 09/05/2013 03:30 PM, Merlin Moncure wrote:
> 
> >> Standard advice we've given in the past is 25% shared buffers, 75%
> >> effective_cache_size.  Which would make EFS *3X* shared_buffers, not 4X.
> >>  Maybe we're changing the conventional calculation, but I thought I'd
> >> point that out.
> > 
> > This was debated upthread.
> 
> Actually, no, it wasn't.  Tom threw out a suggestion that we use 4X for
> historical reasons.  That's all, there was no discussion.
> 
> So, my point stands: our historical advice has been to set EFS to 75% of
> RAM.  Maybe we're changing that advice, but if so, let's change it.
> Otherwise 3X makes more sense.

So, what do we want the effective_cache_size default to be?  3x or 4x?
We clearly state:
       If you have a dedicated database server with 1GB or more of RAM,       a reasonable starting value for
shared_buffersis 25% of the       memory in your system.  There are some workloads where even
 

If we make the default 4x, that means that people using the above
suggestion would be setting their effective_cache_size to 100% of RAM? 
If we go with 4x, which I believe was the majority opinion, what shall
we answer to someone who asks about this contradiction?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: New statistics for WAL buffer dirty writes
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII