Re: heavily contended lwlocks with long wait queues scale badly
От
Jonathan S. Katz
Тема
Re: heavily contended lwlocks with long wait queues scale badly
Дата
Msg-id
8680af2d-44ca-8d5e-d246-0db590b00a02@postgresql.org
Ответ на
Re: heavily contended lwlocks with long wait queues scale badly (Andres Freund)
Список
Дерево обсуждения
heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Dilip Kumar <dilipbalaut@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Robert Haas <robertmhaas@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Robert Haas <robertmhaas@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly "Jonathan S. Katz" <jkatz@postgresql.org>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly "Jonathan S. Katz" <jkatz@postgresql.org>
Re: heavily contended lwlocks with long wait queues scale badly Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly "Jonathan S. Katz" <jkatz@postgresql.org>
Re: heavily contended lwlocks with long wait queues scale badly Nathan Bossart <nathandbossart@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Michael Paquier <michael@paquier.xyz>
Re: heavily contended lwlocks with long wait queues scale badly "Jonathan S. Katz" <jkatz@postgresql.org>
Re: heavily contended lwlocks with long wait queues scale badly Michael Paquier <michael@paquier.xyz>
Re: heavily contended lwlocks with long wait queues scale badly "Jonathan S. Katz" <jkatz@postgresql.org>
Re: heavily contended lwlocks with long wait queues scale badly Michael Paquier <michael@paquier.xyz>
Re: heavily contended lwlocks with long wait queues scale badly Michael Paquier <michael@paquier.xyz>
Re: heavily contended lwlocks with long wait queues scale badly Jakub Wartak <jakub.wartak@enterprisedb.com>
Re: heavily contended lwlocks with long wait queues scale badly Michael Paquier <michael@paquier.xyz>
Re: heavily contended lwlocks with long wait queues scale badly Zhihong Yu <zyu@yugabyte.com>
Re: heavily contended lwlocks with long wait queues scale badly Andres Freund <andres@anarazel.de>
Re: heavily contended lwlocks with long wait queues scale badly Zhihong Yu <zyu@yugabyte.com>
Re: heavily contended lwlocks with long wait queues scale badly Pavel Borisov <pashkin.elfe@gmail.com>
Re: heavily contended lwlocks with long wait queues scale badly Alexander Korotkov <aekorotkov@gmail.com>
On 11/1/22 1:41 PM, Andres Freund wrote: >> Andres: when you suggested backpatching, were you thinking of the Nov 2022 >> release or the Feb 2023 release? > > I wasn't thinking that concretely. Even if we decide to backpatch, I'd be very > hesitant to do it in a few days. Yeah this was my thinking (and also why I took a few days to reply given the lack of urgency for this release). It would at least give some more time for others to test it to feel confident that we're not introducing noticeable regressions. > > > > I tested with browser etc running, so this is plenty noisy. I used the best of > the two pgbench -T21 -P5 tps, after ignoring the first two periods (they're > too noisy). I used an ok-ish NVMe SSD, rather than the the expensive one that > has "free" fsync. > > synchronous_commit=on: > > clients master fix > 16 6196 6202 > 64 25716 25545 > 256 90131 90240 > 1024 128556 151487 > 2048 59417 157050 > 4096 32252 178823 > > > synchronous_commit=off: > > clients master fix > 16 409828 409016 > 64 454257 455804 > 256 304175 452160 > 1024 135081 334979 > 2048 66124 291582 > 4096 27019 245701 > > > Hm. That's a bigger effect than I anticipated. I guess sc=off isn't actually > required, due to the level of concurrency making group commit very > effective. > > This is without an index, serial column or anything. But a quick comparison > for just 4096 clients shows that to still be a big difference if I create an > serial primary key: > master: 26172 > fix: 155813 🤯 (seeing if my exploding head makes it into the archives). Given the lack of ABI changes (hesitant to say low-risk until after more testing, but seemingly low-risk), I can get behind backpatching esp if we're targeting Feb 2023 so we can tests some more. With my advocacy hat on, it bums me that we may not get as much buzz about this change given it's not in a major release, but 1/ it'll fix an issue that will help users with high-concurrency and 2/ users would be able to perform a simpler update to get the change. Thanks, Jonathan
В списке pgsql-hackers по дате отправления
От: Andrew Dunstan
Дата:
От: Alvaro Herrera
Дата: