Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
От | Robert Haas |
---|---|
Тема | Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors |
Дата | |
Msg-id | CA+TgmoY+zKLqBuWqV3Bej5XDtxFDE28CJhs34v9CYKfQNBM_mw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors (David Gould <daveg@sonic.net>) |
Ответы |
Re: Re: bulk_multi_insert infinite loops with large rows
and small fill factors
|
Список | 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
В списке pgsql-hackers по дате отправления: