josh@agliodbs.com (Josh Berkus) wrote:
> I've been trying to peg the "sweet spot" for shared memory using
> OSDL's equipment. With Jan's new ARC patch, I was expecting that
> the desired amount of shared_buffers to be greatly increased. This
> has not turned out to be the case.
That doesn't surprise me.
My primary expectation would be that ARC would be able to make small
buffers much more effective alongside vacuums and seq scans than they
used to be. That does not establish anything about the value of
increasing the size buffer caches...
> This result is so surprising that I want people to take a look at it
> and tell me if there's something wrong with the tests or some
> bottlenecking factor that I've not seen.
I'm aware of two conspicuous scenarios where ARC would be expected to
_substantially_ improve performance:
1. When it allows a VACUUM not to throw useful data out of
the shared cache in that VACUUM now only 'chews' on one
page of the cache;
2. When it allows a Seq Scan to not push useful data out of
the shared cache, for much the same reason.
I don't imagine either scenario are prominent in the OSDL tests.
Increasing the number of cache buffers _is_ likely to lead to some
slowdowns:
- Data that passes through the cache also passes through kernel
cache, so it's recorded twice, and read twice...
- The more cache pages there are, the more work is needed for
PostgreSQL to manage them. That will notably happen anywhere
that there is a need to scan the cache.
- If there are any inefficiencies in how the OS kernel manages shared
memory, as their size scales, well, that will obviously cause a
slowdown.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/internet.html
"One World. One Web. One Program." -- MICROS~1 hype
"Ein Volk, ein Reich, ein Fuehrer" -- Nazi hype
(One people, one country, one leader)
