Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: David Gould <daveg@sonic.net>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Anand Ranganathan <arangana@adobe.com>, Alex Eulenberg <aeulenbe@adobe.com>, Ashokraj M <ashokraj@adobe.com>, Hari <hari@adobe.com>, Elein Mustain <mustain@adobe.com>
Date: 2012-12-14T20:39:44Z
Lists: pgsql-hackers
On Wed, Dec 12, 2012 at 8:29 AM, David Gould <daveg@sonic.net> wrote: > We lose noticable performance when we raise fill-factor above 10. Even 20 is > slower. Whoa. > During busy times these hosts sometimes fall into a stable state > with very high cpu use mostly in s_lock() and LWLockAcquire() and I think > PinBuffer plus very high system cpu in the scheduler (I don't have the perf > trace in front of me so take this with a grain of salt). In this mode they > fall from the normal 7000 queries per second to below 3000. I have seen signs of something similar to this when running pgbench -S tests at high concurrency. I've never been able to track down where the problem is happening. My belief is that once a spinlock starts to be contended, there's some kind of death spiral that can't be arrested until the workload eases up. But I haven't had much luck identifying exactly which spinlock is the problem or if it even is just one... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company