Hello, everyone.
Benchmarks for the last version of patch are ready.
Executed on two 16CPU machines (AMD EPYC 7763), 5000 max_connections.
Staring from the 60th second, 30 seconds-long transaction was started
on primary. Setup is the same as in (1), scripts here - (2).
For most of the tests, simple-update and simple-select pgbench
scenarios were used on primary and standby.
For one of the tests - just “SELECT txid_current();” and “SELECT 1;”
accordingly.
The name of the line is KAX_COMPRESS_FREQUENCY value.
For 16 connections, 64, 128 and 256 are the best ones.
For 32 - 32, 64, 12, 256.
For 64 - a little bit tricky story. 128 and 256 are best, but
1024-4096 can be faster some small period of time with continuing
degradation. Still not sure why. Three different run sets in
attachment, one with start of long transaction on 20th second.
For 128 - anything < 1024 is good.
For “txid_current+select 1” case - the same.
Also, in all the cases, patched version is better than current master.
And for master (and some big values of KAX_COMPRESS_FREQUENCY) version
it is not possible for performance to recover, probably caches and
locking goes into some bad, but stable pattern.
So, I think it is better to go 128 here.
[1]:
https://www.postgresql.org/message-id/flat/CANtu0ohzBFTYwdLtcanWo4%2B794WWUi7LY2rnbHyorJdE8_ZnGg%40mail.gmail.com#379c1be7b8134ada5a574078d51b64c6
[2]: https://gist.github.com/michail-nikolaev/e1dfc70bdd7cfd1b902523dbb3db2f28
--
Michail Nikolaev.
