On 2013-09-17 08:32:30 -0500, Merlin Moncure wrote: > On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund <andres@xxxxxxxxxxxxxxx> 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() :-). Ah, yes. Sorry confused issues ;). Yes, I think that'd made sense. > > 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. Great. The primary thing I'd like to know is whether there are lots of non-fastpath locks... If you ever get into the situation I mistakenly referred to again, I'd strongly suggest recompling postgres with -fno-omit-frame-pointer. That makes hierarchical profiles actually useful which can help tremendously with diagnosing issues like this... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
