Бенчмарк — это способ определения производительности вашей инфраструктуры. Sysbench — отличный инструмент для сравнения серверов PostgreSQL. В этой статье попробуем генерировать тестовые нагрузки с помощью sysbench. Будем использовать настройку потоковой репликации master-slave с двумя узлами. Это также поможет сгенерировать некоторую активность в кластере и проверить, работает ли репликация должным образом.
Установим последнюю версию sysbench, которая в настоящее время поддерживается здесь. Мы также будем использовать стандартные PostgreSQL 14.2. Обратите внимание, что путь, используемый в этой статье, может отличаться в зависимости от установленной версии PostgreSQL и поставщика.
В качестве примечания мы рассмотрели аналогичное сообщение в блоге о бенчмаркинге PostgreSQL с помощью pgbench в этом сообщении в блоге, как сравнить производительность PostgreSQL.
Сервер СУБД (master) — vav-pg
Сервер СУБД (secondary) — vav-pgs
Сервер sysbench — vav-sysbench
Содержание
Установка Sysbench
Установка sysbench проста. Для Debian / Ubuntu:
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash $ sudo apt -y install sysbench
И для RHEL / CentOS:
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash $ sudo yum -y install sysbench
Проверьте версию:
$ sysbench --version sysbench 1.0.15
Инициализация тестовых данных
Если вы знакомы с sysbench, он использует следующие значения по умолчанию для параметров PostgreSQL:
- pgsql-host=localhost
- pgsql-port=5432
- pgsql-user=sbtest
- pgsql-password=пароль
- pgsql-db=sbtest
Во-первых, создайте базу данных и пользователя в PostgreSQL:
$ su - postgres $ psql > CREATE USER sbtest WITH PASSWORD 'password'; > CREATE DATABASE sbtest; > GRANT ALL PRIVILEGES ON DATABASE sbtest TO sbtest;
Затем отредактируйте файл доступа на основе хоста, pg_hba.conf
И добавьте следующую строку, чтобы разрешить подключения для пользователя sbtest, к базе данных sbtest со всех хостов:
host sbtest sbtest 0.0.0.0/0 scram-sha-256
Перезагрузите конфигурацию, чтобы применить изменения:
$ su - postgres $ psql > select pg_reload_conf(); pg_reload_conf ---------------- t (1 row)
Проверьте из клиента командной строки psql, правильно ли работает аутентификация пользователя:
$ psql -U sbtest -h vav-pg -p 5432 -d sbtest -W Password: psql (14.2) Type "help" for help. sbtest=>
Теперь мы можем инициализировать базу данных с помощью sysbench с помощью следующей команды:
$ sysbench \ --db-driver=pgsql \ --oltp-table-size=100000 \ --oltp-tables-count=24 \ --threads=1 \ --pgsql-host=vav-pg \ --pgsql-port=5432 \ --pgsql-user=sbtest \ --pgsql-password=password \ --pgsql-db=sbtest \ /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua \ run
Приведенная выше команда генерирует 100 000 строк в каждой таблице для 24 таблиц (от sbtest1 до sbtest24) внутри базы данных «sbtest». Имя схемы «public» по умолчанию. Данные подготавливаются скриптом parallel_prepare.lua, который доступен в /usr/share/sysbench/tests/include/oltp_legacy.
Проверьте сгенерированные таблицы с помощью следующей команды:
$ psql -U sbtest -h vav-pg -p 5432 -W -c '\dt+\'
Password for user sbtest:
List of relations
Schema | Name | Type | Owner | Size | Description
--------+----------+-------+--------+-------+-------------
public | sbtest1 | table | sbtest | 21 MB |
public | sbtest10 | table | sbtest | 21 MB |
public | sbtest11 | table | sbtest | 21 MB |
public | sbtest12 | table | sbtest | 21 MB |
public | sbtest13 | table | sbtest | 21 MB |
public | sbtest14 | table | sbtest | 21 MB |
public | sbtest15 | table | sbtest | 21 MB |
public | sbtest16 | table | sbtest | 21 MB |
public | sbtest17 | table | sbtest | 21 MB |
public | sbtest18 | table | sbtest | 21 MB |
public | sbtest19 | table | sbtest | 21 MB |
public | sbtest2 | table | sbtest | 21 MB |
public | sbtest20 | table | sbtest | 21 MB |
public | sbtest21 | table | sbtest | 21 MB |
public | sbtest22 | table | sbtest | 21 MB |
public | sbtest23 | table | sbtest | 21 MB |
public | sbtest24 | table | sbtest | 21 MB |
public | sbtest3 | table | sbtest | 21 MB |
public | sbtest4 | table | sbtest | 21 MB |
public | sbtest5 | table | sbtest | 21 MB |
public | sbtest6 | table | sbtest | 21 MB |
public | sbtest7 | table | sbtest | 21 MB |
public | sbtest8 | table | sbtest | 21 MB |
public | sbtest9 | table | sbtest | 21 MB |
(24 rows)
Теперь загружены тестовые данные.
Создание тестовых нагрузок
Существуют различные виды рабочей нагрузки базы данных, которые вы можете выполнять с помощью sysbench, как показано в следующих разделах.
Загрузка чтения/записи
Команда похожа на версию MySQL sysbench. Можно использовать аналогичные параметры, кроме параметров, связанных с PostgreSQL:
$ sysbench \ --db-driver=pgsql \ --report-interval=2 \ --oltp-table-size=100000 \ --oltp-tables-count=24 \ --threads=64 \ --time=60 \ --pgsql-host=vav-pg \ --pgsql-port=5432 \ --pgsql-user=sbtest \ --pgsql-password=password \ --pgsql-db=sbtest \ /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \ run
Приведенная выше команда сгенерирует рабочую нагрузку OLTP из скрипта LUA с именем /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua с данными размером 100 000 строк в 24 таблиц в 64 рабочих потока в течение 60 секунд на хосте vav-pg (master). Каждые 2 секунды sysbench будет сообщать промежуточную статистику (--report-interval = 2).
После выполнения вы получите что-то вроде ниже:
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 64 Report intermediate results every 2 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 2s ] thds: 64 tps: 299.91 qps: 6318.96 (r/w/o: 4468.63/1221.08/629.25) lat (ms,95%): 612.21 err/s: 0.00 reconn/s: 0.00 [ 4s ] thds: 64 tps: 362.61 qps: 7376.22 (r/w/o: 5201.07/1446.94/728.22) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00 [ 6s ] thds: 64 tps: 488.57 qps: 9765.38 (r/w/o: 6850.97/1937.27/977.14) lat (ms,95%): 193.38 err/s: 0.00 reconn/s: 0.00 [ 8s ] thds: 64 tps: 544.39 qps: 10715.42 (r/w/o: 7437.56/2187.58/1090.29) lat (ms,95%): 144.97 err/s: 1.00 reconn/s: 0.00 [ 10s ] thds: 64 tps: 411.01 qps: 8145.24 (r/w/o: 5684.17/1638.55/822.52) lat (ms,95%): 272.27 err/s: 0.00 reconn/s: 0.00 [ 12s ] thds: 64 tps: 409.04 qps: 8510.43 (r/w/o: 6033.66/1657.68/819.09) lat (ms,95%): 282.25 err/s: 0.50 reconn/s: 0.00 [ 14s ] thds: 64 tps: 463.45 qps: 9256.51 (r/w/o: 6483.81/1845.80/926.90) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00 [ 16s ] thds: 64 tps: 381.06 qps: 7482.73 (r/w/o: 5210.85/1508.25/763.63) lat (ms,95%): 253.35 err/s: 0.50 reconn/s: 0.00
Пока тест выполняется, мы можем отслеживать активность PostgreSQL с помощью pg_activity или pg_top, чтобы подтвердить промежуточную статистику, сообщенную sysbench.
Установим pg_activity
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm sudo yum install -y https://repo.ius.io/ius-release-el7.rpm sudo yum install -y pg_activity
В терминале на мастере выполните:
$ su - postgres $ pg_activity
А также поток репликации, просмотрев таблицу pg_stat_replication на главном сервере:
$ su - postgres $ watch -n1 'psql -xc "select * from pg_stat_replication"' Every 1.0s: psql -xc "select * from pg_stat_replication" Fri May 13 09:18:15 2022 -[ RECORD 1 ]----+------------------------------ pid | 19761 usesysid | 10 usename | postgres application_name | walreceiver client_addr | 123.123.123.123 client_hostname | client_port | 60498 backend_start | 2022-05-13 09:15:49.99184+00 backend_xmin | state | streaming sent_lsn | 0/F5C105D8 write_lsn | 0/F5C105D8 flush_lsn | 0/F5C105D8 replay_lsn | 0/F5C105D8 write_lag | 00:00:00.000802 flush_lag | 00:00:00.002841 replay_lag | 00:00:00.002842 sync_priority | 0 sync_state | async reply_time | 2022-05-13 09:18:12.646698+00
Приведенная выше команда «watch» запускает команду psql каждые 1 секунду. Вы должны увидеть, что столбцы «* _location» обновляются соответствующим образом при передаче изменений.
В конце теста вы должны увидеть резюме:
SQL statistics:
queries performed:
read: 283766
write: 81017
other: 40563
total: 405346
transactions: 20252 (337.31 per sec.)
queries: 405346 (6751.35 per sec.)
ignored errors: 17 (0.28 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 60.0373s
total number of events: 20252
Latency (ms):
min: 19.83
avg: 189.69
max: 1102.99
95th percentile: 272.27
sum: 3841547.45
Threads fairness:
events (avg/stddev): 316.4375/6.55
execution time (avg/stddev): 60.0242/0.00
Приведенное выше резюме говорит нам, что наш сервер баз данных PostgreSQL может обрабатывать в среднем около 337 транзакций в секунду и около 6751 запросов в секунду в 64 рабочих потоках.
Загрузка только для чтения
Для теста только для чтения вы можете использовать ту же команду, но измените сценарий LUA на select.lua, select_random_points.lua, select_random_ranges.lua или oltp_simple.lua:
$ sysbench \ --db-driver=pgsql \ --report-interval=2 \ --oltp-table-size=100000 \ --oltp-tables-count=24 \ --threads=64 \ --time=60 \ --pgsql-host=vav-pgs \ --pgsql-port=5432 \ --pgsql-user=sbtest \ --pgsql-password=password \ --pgsql-db=sbtest \ /usr/share/sysbench/tests/include/oltp_legacy/select.lua \ run
Приведенная выше команда запускает рабочую нагрузку только для чтения с именем select.lua на реплике PostgreSQL (потоковая репликация) с 64 рабочими потоками.
Другие нагрузки
Существует много других рабочих нагрузок OLTP, которые вы можете создать с помощью sysbench, как указано в каталоге /usr/share/sysbench/tests/include/oltp_legacy:
ls -1 /usr/share/sysbench/tests/include/oltp_legacy/ bulk_insert.lua common.lua delete.lua insert.lua oltp.lua oltp_simple.lua parallel_prepare.lua select.lua select_random_points.lua select_random_ranges.lua update_index.lua update_non_index.lua
Вы можете использовать аналогичную команду и изменить путь к скрипту LUA, чтобы загрузить его.
Заключительные мысли
Используя sysbench, мы можем генерировать тестовые нагрузки для нашего сервера PostgreSQL. Обратите внимание, что лучший тест будет с вашими реальными данными и приложениями, но это не всегда возможно. Это также может быть новое приложение, которое будет быстро развиваться. Несмотря на то, что нагрузка, создаваемая sysbench, может не отражать вашу реальную рабочую нагрузку OLTP, она может быть достаточно хорошей для тестирования производительности.
