Re: Cpu usage 100% on slave. s_lock problem.
От | Merlin Moncure |
---|---|
Тема | Re: Cpu usage 100% on slave. s_lock problem. |
Дата | |
Msg-id | CAHyXU0x3G3my-L5Yy=Qrp8XFPc_7MOQEWao47W-opF44O9WP0g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Cpu usage 100% on slave. s_lock problem. (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Cpu usage 100% on slave. s_lock problem.
|
Список | pgsql-performance |
On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-09-17 08:18:54 -0500, Merlin Moncure wrote: >> Do you think it's worth submitting the lock avoidance patch for formal review? > > You mean the bufmgr.c thing? Generally I think that that code needs a > good of scalability work - there's a whole thread about it > somewhere. But TBH the theories you've voiced about the issues you've > seen haven't convinced me so far. er, no (but I share your skepticism -- my challenge right now is to demonstrate measurable benefit which so far I've been unable to do). I was talking about the patch on *this* thread which bypasses the s_lock in RecoveryInProgress() :-). > Quick question: Do you happen to have pg_locks output from back then > around? We've recently found servers going into somewhat similar > slowdowns because they exhausted the fastpath locks which made lwlocks > far more expensive and made s_lock go up very high in the profle. I do. Unfortunately I don't have profile info. Not sure how useful it is -- I'll send it off-list. merlin
В списке pgsql-performance по дате отправления: