Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers - Mailing list pgsql-hackers

From Benedikt Grundmann
Subject Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id CADbMkNNtMaoRpEeA5uoGzjUWDxnWUQSnJTfsRPLJd-HK2gfQxw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Josh Berkus <josh@agliodbs.com>)
Responses Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
List pgsql-hackers



On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus <josh@agliodbs.com> wrote:
All,

>> Well, the problem of "find out the box's physical RAM" is doubtless
>> solvable if we're willing to put enough sweat and tears into it, but
>> I'm dubious that it's worth the trouble.  The harder part is how to know
>> if the box is supposed to be dedicated to the database.  Bear in mind
>> that the starting point of this debate was the idea that we're talking
>> about an inexperienced DBA who doesn't know about any configuration knob
>> we might provide for the purpose.

For what it is worth even if it is a dedicated database box 75% might be way too high. I remember investigating bad performance on our biggest database server, that in the end turned out to be a too high setting of effective_cache_size. From reading the code back then my rationale for it being to high was that the code that makes use of the effective_cache_size tries very hard to account for what the current query would do to the cache but doesn't take into account how many queries (on separate datasets!) are currently begin executed (and competing for the same cache).  On that box we often have 100+ active connections and many looking at different big datasets.

Cheers,

bene

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Extra XLOG in Checkpoint for StandbySnapshot
Next
From: Pavel Stehule
Date:
Subject: inconsistent behave of boolean based domains in XML functions