Re: hung backends stuck in spinlock heavy endless loop
От | Andres Freund |
---|---|
Тема | Re: hung backends stuck in spinlock heavy endless loop |
Дата | |
Msg-id | 20150113235404.GB22986@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: hung backends stuck in spinlock heavy endless loop (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: hung backends stuck in spinlock heavy endless loop
|
Список | pgsql-hackers |
On 2015-01-13 15:49:33 -0800, Peter Geoghegan wrote: > On Tue, Jan 13, 2015 at 3:21 PM, Andres Freund <andres@2ndquadrant.com> wrote: > > My guess is rather that it's contention on the freelist lock via > > StrategyGetBuffer's. I've seen profiles like this due to exactly that > > before - and it fits to parallel loading quite well. > > I'm not saying you're wrong, but the breakdown of _bt_moveright() > relative to _bt_relandgetbuf() calls seems a bit fishy to me. The hierarchical profile definitely doesn't look like my guess was right. > I don't remember seeing _bt_moveright() or _bt_compare() figuring so > prominently, where _bt_binsrch() is nowhere to be seen. I can't see a > reference to _bt_binsrch() in either profile. Well, we do a _bt_moveright pretty early on, so that actually might be cache misses we're primarily seing. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: