On Tue, Nov 20, 2012 at 10:50 AM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: > On Tue, Nov 20, 2012 at 8:03 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >> On Tue, Nov 20, 2012 at 9:02 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote: >>> On 11/16/2012 02:31 PM, Merlin Moncure wrote: >>> >>>> no single thing really stands out -- contention is all over the place. >>>> lwlock, pinbuffer, dynahash (especially). I am again suspicious of >>>> bad scheduler interaction. any chance we can fire up pgbouncer? >>> >>> >>> Just want to throw it out there, but we've been having really bad luck with >>> the scheduler recently. But only when we use 8GB (on our 72GB system) for >>> shared_buffers. Cut that down to 4GB, and everything is fine and dandy. >>> >>> I think the kernel devs have added in some overzealous scheduler code on us. >> >> Shared buffer manipulation changing contention is suggesting you're >> running into free list lock issues. > > I wouldn't expect so. Increasing shared_buffers should either fix > free list lock contention, or leave it unchanged, not make it worse. AIUI, that is simply not true (unless you raise it to the point you're not churning them). I'm looking at StrategyGetBuffer() for non-scan cases. It locks "BufFreelistLock" then loops the free list, and, if it finds nothing, engages a clock sweep. Both of those operations are dependent on the number of buffers being managed and so it's reasonable to expect some workloads to increase contention with more buffers. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
