On 2013-12-05 11:33:29 +0200, Metin Doslu wrote: > > Is your workload bigger than RAM? > > RAM is bigger than workload (more than a couple of times).
> > I think a good bit of the contention > > you're seeing in that listing is populating shared_buffers - and might > > actually vanish once you're halfway cached. > > From what I've seen so far the bigger problem than contention in the > > lwlocks itself, is the spinlock protecting the lwlocks... > > Could you clarify a bit what do you mean by "halfway cached" Well, your stats showed a) fairly low lock counts overall b) a high percentage of exclusive locks. a) indicates the system wasn't running long. b) tells me there were lots of changes to the buffer mapping - which basically only happens if a buffer is placed or removed from shared-buffers. If your shared_buffers is big enough to contain most of the data you shouldn't see many exclusive locks in comparison to the number of shared locks. > and "spinlock protecting the lwlocks". Every LWLock has an internal spinlock to protect its state. So whenever somebody does a LWLockAcquire()/Release(), even if only in shared mode, we currently acquire that spinlock, manipulate the LWLocks state, and release the spinlock again. In lots of workloads that internal spinlock is the contention point, not the lenght over which the lwlock is held. Especially when they are mostly held in shared mode. Makes sense? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
