postgres бенчмарки. часть 2

Создадим таблицу помощнее
pgbench -i -s 30 -h 192.168.1.103 -U postgres tmp

На этот раз она занимает 456М

И пройдёмся теми же тестами
110тпс для одного клиента

pgbench -c 80 -U postgres -T 30 -h 192.168.1.103 tmp
При 80 клиентах получается 320тпс

Уже заметна нагрузка на базу в лице checkpoint process - база нахватывается транзакций, исполняет их и сохраняет, создавая нагрузку на диск. (в конце статьи поборем эту беду)

Локально получалось и до 420тпс разгонять. Возможно было удачное попадание в чекпойнт.

Таблица таже. Попробуем добавить --foreign-keys
300-320 tps

И без них или чуть хуже (?) или столько же

 -j 4 - в 4 потока. В пределах погрешности - 427
pgbench -c 80 -j4 -U postgres -T 30 -h 192.168.1.103 tmp
scaling factor: 30
query mode: simple
number of clients: 80
number of threads: 4
duration: 30 s
number of transactions actually processed: 12812
latency average: 187.324 ms
tps = 425.185222 (including connections establishing)
tps = 427.432431 (excluding connections establishing)


Если делать в одного клиента - нагрузка на сеть получается равномерной
Нашел интересную вещь - протокол

Теперь нужна нормальная (большая база) для тестов похожи на среднюю нагрузку
pgbench -i -s 200 -h 192.168.1.103 -U postgres tmp

Это база на 3гб
Классический тест
pgbench -c 80 -U postgres -T 30 -h 192.168.1.103 tmp
Делает большой разброс от 180 до 280 тпс.

В один коннект
93тпс. Видно что нагрузка просела.

Протестим увеличение work_mem
Непонятно. Всё также
200-270тпс

Самое время увеличить shared_buffers. 2гб в самый раз!
И сразу 200-290тпс

Всё упирается в чекпойнты. С 3 поднимем до 10
И сразу 290-337. Т.е. когда часто идёт запись есть смысл увеличивать число сегментов.

А теперь всё увеличим!
500! 500! Карл!
Повторно - 300.
Соло - 113-115 что несколько выше

Если при тестах видно что упирается всё в сегменты, то надо увеличивать число. При этом логи постгреса сами подскажут что нужно это число увеличить! Грепайте по HINT
После увеличения сегментов много пользовательский тест показал
pgbench -c 100 -U postgres -T 30 -h 192.168.1.103 tmp
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 200
query mode: simple
number of clients: 100
number of threads: 1
duration: 30 s
number of transactions actually processed: 48504
latency average: 61.851 ms
tps = 1597.936361 (including connections establishing)
tps = 1638.000089 (excluding connections establishing)

Огонь!

Проверим только селекты
pgbench -S -c 100 -U postgres -T 30 -h 192.168.1.103 tmp
starting vacuum...end.
transaction type: SELECT only
scaling factor: 200
query mode: simple
number of clients: 100
number of threads: 1
duration: 30 s
number of transactions actually processed: 93766
latency average: 31.995 ms
tps = 3100.100112 (including connections establishing)
tps = 3179.048805 (excluding connections establishing)

Это при 100 клиентах. Для одного клиента нам тоже важно
 pgbench -S -U postgres -T 30 -h 192.168.1.103 tmp
starting vacuum...end.
transaction type: SELECT only
scaling factor: 200
query mode: simple
number of clients: 1
number of threads: 1
duration: 30 s
number of transactions actually processed: 48013
latency average: 0.625 ms
tps = 1600.395937 (including connections establishing)
tps = 1600.801624 (excluding connections establishing)

1600 записей можно читать для одного клиента