Re: Shared Memory Sizing - Mailing list pgsql-general

From Jan Wieck
Subject Re: Shared Memory Sizing
Date
Msg-id 3D1B2EE5.88906741@Yahoo.com
Whole thread Raw
In response to Re: Shared Memory Sizing  (Curt Sampson <cjs@cynic.net>)
Responses Re: Shared Memory Sizing  (Andrew Sullivan <andrew@libertyrms.info>)
Re: Shared Memory Sizing  (Curt Sampson <cjs@cynic.net>)
List pgsql-general
Curt Sampson wrote:
>
> On Thu, 27 Jun 2002, Jan Wieck wrote:
>
> > Can you please enlighten us what the optimum is? And please don't escape
> > into the mmap solution if you cannot give that answer in diff format.
>
> Well, first of all, let me note that this is all theoretical work on my
> part so far. If someone is actually doing some real testing of this, I'd
> be interested in the results. If the results are different from what I
> think they should be, something strange is going on.

Since none of us actually has done real benchmarks in this area, we are
all just debating out of the blue. So please don't take that personal,
okay?

> The optimum will depend on the number of connections you have and the
> type of workload you have. At this point, I'm not even sure about how to
> go about determining precisely what would be better and worse; it would
> be a lot of work. (Probably a lot more than it's worth, given the prices
> of memory these days.)

Sure, the optimum will depend on the application and it's usage profile.
But that's fine tuning, not a rough rule of thumb for general purpose,
and I think we where looking for the latter.

> I'd say, at a rough estimate, go for a number of buffers 2-3 times the
> maximum number of connections you allow. Or less if you anticipate
> rarely ever having that many connections.

Here I disagree. The more shared buffer cache you have, the bigger the
percentage of your database that neither causes read()'s nor memory
copying from the OS buffer cache.

Whatever, we can debate that forever without some numbers. Let's
continue that discussion when we have at least some benchmarking
results.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-general by date:

Previous
From: "Markus Wollny"
Date:
Subject: Re: One source of constant annoyance identified
Next
From: mordicus
Date:
Subject: Re: pg_dump / consistent snapshot / backup