оттуда:
Каково содержание «транзакции», которую выполняет pgbench?

Программа pgbench выполняет тестовые скрипты, выбирая их случайным образом из заданного списка. В том числе это встроенные скрипты, заданные аргументами -b, и пользовательские скрипты, заданные аргументами -f. Для каждого скрипта можно задать относительный вес после @, чтобы скорректировать вероятность его выбора. Вес по умолчанию — 1. Скрипты с весом 0 игнорируются.

Стандартный встроенный скрипт (также вызываемый с ключом -b tpcb-like) выдаёт семь команд в транзакции со случайно выбранными aid, tid, bid и delta. Его сценарий написан по мотивам теста производительности TPC-B, но это не собственно TPC-B, потому он называется так.

BEGIN;

UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;

UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;

INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

END;

Кто пробовал в lxd schedule?
lxc config set u1804 snapshots.schedule "15 * * * *"

Кто нибудь кроме меня использует lxd для postgresql + 1c в контейнерах на zfs ?

1ый запуск полного  TPC-B (на "только селекты" ускорения от установки в off указанных переменных смысла нет)

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 99224.9 tps, lat 0.642 ms stddev 0.356
progress: 10.0 s, 103763.0 tps, lat 0.616 ms stddev 0.329
...
progress: 115.0 s, 77432.4 tps, lat 0.826 ms stddev 0.944
progress: 120.0 s, 76938.1 tps, lat 0.831 ms stddev 0.969
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 10918449
latency average = 0.703 ms
latency stddev = 0.715 ms
tps = 90955.989655 (including connections establishing)
tps = 90968.635488 (excluding connections establishing)

2ой запуск:

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 83469.3 tps, lat 0.763 ms stddev 2.892
progress: 10.0 s, 81950.7 tps, lat 0.781 ms stddev 1.098
...
progress: 115.0 s, 65336.5 tps, lat 0.979 ms stddev 1.274
progress: 120.0 s, 63531.5 tps, lat 1.007 ms stddev 1.205
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 9179268
latency average = 0.836 ms
latency stddev = 1.254 ms
tps = 76441.895492 (including connections establishing)
tps = 76452.255102 (excluding connections establishing)

3ий запуск:

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 85831.7 tps, lat 0.742 ms stddev 2.878
progress: 10.0 s, 84078.6 tps, lat 0.761 ms stddev 0.943
...
progress: 115.0 s, 63551.7 tps, lat 1.006 ms stddev 1.564
progress: 120.0 s, 63052.5 tps, lat 1.014 ms stddev 1.944
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 9308136
latency average = 0.824 ms
latency stddev = 1.427 ms
tps = 77545.030401 (including connections establishing)
tps = 77555.017145 (excluding connections establishing)

думаю что где-то плюсом 30-50% можно получить прирост на TPC-B. Насколько это ускорит работу именно с 1С - не знаю)

сейчас ещё включу HugePages и проверю с ними

Здорово, существенный результат.
Жаль у вас нет ext4 сравнить.
Развеять мифы измерениями.

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 99224.9 tps, lat 0.642 ms stddev 0.356
progress: 10.0 s, 103763.0 tps, lat 0.616 ms stddev 0.329
...
progress: 115.0 s, 77432.4 tps, lat 0.826 ms stddev 0.944
progress: 120.0 s, 76938.1 tps, lat 0.831 ms stddev 0.969
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 10918449
latency average = 0.703 ms
latency stddev = 0.715 ms
tps = 90955.989655 (including connections establishing)
tps = 90968.635488 (excluding connections establishing)

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 83469.3 tps, lat 0.763 ms stddev 2.892
progress: 10.0 s, 81950.7 tps, lat 0.781 ms stddev 1.098
...
progress: 115.0 s, 65336.5 tps, lat 0.979 ms stddev 1.274
progress: 120.0 s, 63531.5 tps, lat 1.007 ms stddev 1.205
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 9179268
latency average = 0.836 ms
latency stddev = 1.254 ms
tps = 76441.895492 (including connections establishing)
tps = 76452.255102 (excluding connections establishing)

root@hz:~# pgbench -U postgres -j 64 -c 64 -M prepared -T 120 -v -P 5 pgbench
starting vacuum...end.
starting vacuum pgbench_accounts...end.
progress: 5.0 s, 85831.7 tps, lat 0.742 ms stddev 2.878
progress: 10.0 s, 84078.6 tps, lat 0.761 ms stddev 0.943
...
progress: 115.0 s, 63551.7 tps, lat 1.006 ms stddev 1.564
progress: 120.0 s, 63052.5 tps, lat 1.014 ms stddev 1.944
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 5000
query mode: prepared
number of clients: 64
number of threads: 64
duration: 120 s
number of transactions actually processed: 9308136
latency average = 0.824 ms
latency stddev = 1.427 ms
tps = 77545.030401 (including connections establishing)
tps = 77555.017145 (excluding connections establishing)

А может отключить только synchronous_commit и повторить тест?

сейчас попробую.

Скорее всего основой прирост количества транзакций именно в этом параметре, но могу ошибаться

Я это понимаю, просто сам юзаю esxi , но там таких плюшек в виде zfs нету.. proxmox можно и на Линукс пакетом установить.. можно и отдельно... Но в чистый Линукс можно ещё чего доустановить, в вот proxmox нет

proxmox это Debian 10 + софт. Точно также можно установить и всё остальное

Мне centos ближе)

Я на ноуте тестировал. Сравнивал: чистый lvm-том, lvm-thin и zfs
Чистый lvm быстрее, чем два других. Подробности не помню.
Но меня больше интересовало падение производительности при снятых снапшотах. В итоге примерно одинаково показали lvm-thin и zfs.
Как ни крути, но накладные расходы на все прибамбасы будут, как ни крути.

Зато у zfs больше плюшек

Мне кажется вообще тестить чисто pg_bench и только постгрес нет смысла. Не факт, что будет куча мелких записей. А чтения все равно в кэше будут. Лучше было бы сравнить по тестам 1С. И если условно 1С будет одинаково работать на чистом ext4 и на zfs со снимками, то зачем тогда не использовать zfs? 😁

возможно что кто-то (например я) использует связку ZFS+PG не только для 1С

Ну при любом раскладе фишки zfs не "бесплатны" по процессору. И чистая ext4 всегда хоть немного, но будет быстрее.
Просто не факт, что при определённом "профиле" нагрузки на СУБД это будет важно.

Во-во, есть ли у кого *.epf , который измеряет в попугаях производительность?

разместил базы на lvm разделе, подскажите, как правильно бэкапить со снапшотов?

в этом плане да. Но если например вам нужно собрать массив из 10 дисков (raid10 к примеру), то у меня было бы больше доверия к такому массиву который я соберу на ZFS чем к связке mdadm+lvm+ext4