Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
От | Andres Freund |
---|---|
Тема | Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) |
Дата | |
Msg-id | 20220525034655.c6jy4yegagz666l3@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Improving connection scalability (src/backend/storage/ipc/procarray.c) (Ranier Vilela <ranier.vf@gmail.com>) |
Ответы |
Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
|
Список | pgsql-hackers |
Hi, On 2022-05-24 12:28:20 -0300, Ranier Vilela wrote: > Linux Ubuntu 64 bits (gcc 9.4) > ./pgbench -M prepared -c $conns -j $conns -S -n -U postgres > > conns tps head tps patched > 1 2918.004085 3190.810466 > 10 12262.415696 17199.862401 > 50 13656.724571 18278.194114 > 80 14338.202348 17955.336101 > 90 16597.510373 18269.660184 > 100 17706.775793 18349.650150 > 200 16877.067441 17881.250615 > 300 16942.260775 17181.441752 > 400 16794.514911 17124.533892 > 500 16598.502151 17181.244953 > 600 16717.935001 16961.130742 > 700 16651.204834 16959.172005 > 800 16467.546583 16834.591719 > 900 16588.241149 16693.902459 > 1000 16564.985265 16936.952195 17-18k tps is pretty low for pgbench -S. For a shared_buffers resident run, I can get 40k in a single connection in an optimized build. If you're testing a workload >> shared_buffers, GetSnapshotData() isn't the bottleneck. And testing an assert build isn't a meaningful exercise either, unless you have way way higher gains (i.e. stuff like turning O(n^2) into O(n)). What pgbench scale is this and are you using an optimized build? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: