On Thu, 2004-10-14 at 16:57 -0700, Josh Berkus wrote:
> 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?
    In a past life there seemed to be a sweet spot around the
working set.   Performance went up until you got just a little larger
the cache needed to hold the working set and then went down.  Most of
the time a nice looking hump.    It seems to have to do with the
additional pages
not increasing your hit ratio but increasing the amount of work to get a
hit in cache.    This seemed to be independent of the actual database
software being used. (I observed this running Oracle, Informix, Sybase
and Ingres.)

> 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.
Timothy D. Witham - Chief Technology Officer - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton OR, 97005
(503)-626-2455 x11 (office)    (503)-702-2871     (cell)
(503)-626-2436     (fax)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to