From: | Benedikt Grundmann <bgrundmann(at)janestreet(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Date: | 2013-01-09 08:38:25 |
Message-ID: | CADbMkNNtMaoRpEeA5uoGzjUWDxnWUQSnJTfsRPLJd-HK2gfQxw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2013-01-09 08:45:10 | inconsistent behave of boolean based domains in XML functions |
Previous Message | Amit Kapila | 2013-01-09 08:34:32 | Re: Extra XLOG in Checkpoint for StandbySnapshot |