Skip site navigation (1) Skip section navigation (2)

Re: First set of OSDL Shared Mem scalability results, some wierdness ...

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...
Date: 2004-10-09 02:10:19
Message-ID: m31xg8zlo4.fsf@wolfe.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
josh(at)agliodbs(dot)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)

In response to

Responses

pgsql-performance by date

Next:From: Kevin BrownDate: 2004-10-09 11:20:48
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...
Previous:From: Josh BerkusDate: 2004-10-08 23:31:41
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...

pgsql-hackers by date

Next:From: Joe ConwayDate: 2004-10-09 03:13:45
Subject: Re: Inability to cast regclass is too restrictive
Previous:From: Bruce MomjianDate: 2004-10-09 01:29:24
Subject: Re: [HACKERS] Log line prefix on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group