From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Дмитрий Дегтярёв <degtyaryov(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Cpu usage 100% on slave. s_lock problem. |
Date: | 2013-09-17 13:32:30 |
Message-ID: | CAHyXU0x3G3my-L5Yy=Qrp8XFPc_7MOQEWao47W-opF44O9WP0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-09-17 13:35:46 | Re: Cpu usage 100% on slave. s_lock problem. |
Previous Message | Andres Freund | 2013-09-17 13:24:39 | Re: Cpu usage 100% on slave. s_lock problem. |