Simon,
<lots of good stuff clipped>
> If you draw a graph of speedup (y) against cache size as a
> % of total database size, the graph looks like an upside-down "L" - i.e.
> the graph rises steeply as you give it more memory, then turns sharply at a
> particular point, after which it flattens out. The "turning point" is the
> "sweet spot" we all seek - the optimum amount of cache memory to allocate -
> but this spot depends upon the worklaod and database size, not on available
> RAM on the system under test.
Hmmm ... how do you explain, then the "camel hump" nature of the real
performance? That is, when we allocated even a few MB more than the
"optimum" ~190MB, overall performance stated to drop quickly. The result is
that allocating 2x optimum RAM is nearly as bad as allocating too little
(e.g. 8MB).
The only explanation I've heard of this so far is that there is a significant
loss of efficiency with larger caches. Or do you see the loss of 200MB out
of 3500MB would actually affect the Kernel cache that much?
Anyway, one test of your theory that I can run immediately is to run the exact
same workload on a bigger, faster server and see if the desired quantity of
shared_buffers is roughly the same. I'm hoping that you're wrong -- not
because I don't find your argument persuasive, but because if you're right it
leaves us without any reasonable ability to recommend shared_buffer settings.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
