Re: Improving connection scalability: GetSnapshotData()
От | Konstantin Knizhnik |
---|---|
Тема | Re: Improving connection scalability: GetSnapshotData() |
Дата | |
Msg-id | 114aeac6-8e11-1015-005e-11e25d070043@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Improving connection scalability: GetSnapshotData() ("Andres Freund" <andres@anarazel.de>) |
Список | pgsql-hackers |
On 07.09.2020 23:45, Andres Freund wrote: > Hi, > > > On Mon, Sep 7, 2020, at 07:20, Konstantin Knizhnik wrote: >>>> And which pgbench database scale factor you have used? >>> 200 >>> >>> Another thing you could try is to run 2-4 pgench instances in different >>> databases. >> I tried to reinitialize database with scale 200 but there was no >> significant improvement in performance. > If you're replying to the last bit I am quoting, I was talking about having four databases with separate pbench tablesetc. To see how much of it is procarray contention, and how much it is contention of common buffers etc. > Sorry, I have tested hypothesis that the difference in performance in my and you cases can be explained by size of the table which can have influence on shared buffer contention. Thus is why I used the same scale as you, but there is no difference compatring with scale 100. And definitely Postgres performance in this test is limited by lock contention (most likely shared buffers locks, rather than procarray locks). If I create two instances of postgres, both with pgbench -s 200 database and run two pgbenches with 100 connections each, then each instance shows the same ~1million TPS (1186483) as been launched standalone. And total TPS is 2.3 millions. >> Attachments: >> * pgbench.svg > What numactl was used for this one? > None. I have not used numactl in this case. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: