Marko Tiikkaja wrote: > On the test server I'm running on, it doesn't look quite as bad as the > profiles we had in production, but s_lock is still the worst offender in the > profiles, called from: > > - 80.33% LWLockAcquire > + 48.34% asyncQueueReadAllNotifications > + 23.09% SIGetDataEntries > + 16.92% SimpleLruReadPage_ReadOnly > + 10.21% TransactionIdIsInProgress > + 1.27% asyncQueueAdvanceTail > > which roughly looks like what I recall from our actual production profiles.
So the problem is in the bad scalability of LWLock, not in async.c itself? In master, the spinlock there has been replaced with atomics; does that branch work better? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
