Как да сравните производителността на PostgreSQL с помощта на Sysbench

Сравнителен анализ е начин за откриване на производителността на вашата инфраструктура. Sysbench е чудесен инструмент за сравнителен анализ на PostgreSQL сървъри. В тази публикация в блога ще ви покажем как да генерирате тестови натоварвания с помощта на sysbench. Ще използваме настройка за поточно репликация с два възела главен-подчинен от ClusterControl. Това също ще ни помогне да генерираме известна активност в клъстера и да проверим дали репликацията работи според очакванията.

Ще инсталираме най-новата версия на sysbench, която в момента се поддържа тук. Ще използваме по-актуалния пакет, предоставен на официалната страница на Github, за да инсталираме sysbench. Ще използваме и стандартните двоични файлове на PostgreSQL 9.6 от страницата за изтегляне на PostgreSQL. Обърнете внимание, че пътят, използван в тази публикация в блога, може да е различен в зависимост от версията на PostgreSQL и доставчика, който сте инсталирали.

Като странична бележка, ние разгледахме подобна публикация в блога относно сравнителния анализ на PostgreSQL с помощта на pgbench в тази публикация в блога, Как да сравним производителността на PostgreSQL.

Инсталиране на 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:

$ yum install sysbench

Проверете версията:

$ sysbench --version
sysbench 1.0.15

Вече инсталирахме sysbench.

Инициализиране на тестови данни

Ако сте запознати със sysbench, той използва следните настройки по подразбиране за параметрите на PostgreSQL:

pgsql-host=localhost
pgsql-port=5432
pgsql-user=sbtest
pgsql-password=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 :

$ vim /var/lib/pgsql/9.6/data/pg_hba.conf

И добавете следния ред, за да разрешите връзки за потребителски sbtest, към база данни sbtest от всички хостове под мрежа 192.168.55.0:

host    sbtest          sbtest          192.168.55.0/24         md5

Презаредете сървъра, за да приложите промените:

$ /usr/pgsql-9.6/bin/pg_ctl --reload

Проверете от клиента на командния ред psql дали удостоверяването на потребителя работи правилно:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -d sbtest -W

Трябва да можете да влезете в сървъра под базата данни sbtest:

$ psql -U sbtest -h 192.168.55.61 -p 5432 -W
Password for user sbtest:
Type "help" for help.

sbtest=>

Изпълнете "\q", за да излезете от терминала. Вече можем да инициализираме базата данни с помощта на sysbench със следната команда:

$ sysbench \
--db-driver=pgsql \
--oltp-table-size=100000 \
--oltp-tables-count=24 \
--threads=1 \
--pgsql-host=192.168.55.61 \
--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 192.168.55.61 -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)

Тестовите данни вече са заредени.

Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга

Генериране на тестови товари

Има различни видове натоварване на базата данни, което можете да изпълнявате със 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=192.168.55.61 \
--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 секунди на хост 192.1618.55.55. ). На всеки 2 секунди sysbench ще докладва междинната статистика (--report-interval=2 ).

След като бъде изпълнено, ще получите нещо като по-долу:

sysbench 1.0.15 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 16
Report intermediate results every 2 second(s)
Initializing random number generator from current time

Initializing worker threads...

Threads started!

[ 2s ] thds: 64 tps: 0.00 qps: 466.69 (r/w/o: 406.55/28.33/31.81) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 64 tps: 30.55 qps: 525.38 (r/w/o: 335.56/128.72/61.10) lat (ms,95%): 3639.94 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 64 tps: 39.55 qps: 718.41 (r/w/o: 496.13/142.68/79.60) lat (ms,95%): 4128.91 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 64 tps: 35.98 qps: 840.95 (r/w/o: 604.11/163.89/72.95) lat (ms,95%): 2198.52 err/s: 0.50 reconn/s: 0.00
[ 10s ] thds: 64 tps: 65.57 qps: 1314.94 (r/w/o: 912.00/271.80/131.14) lat (ms,95%): 3040.14 err/s: 0.00 reconn/s: 0.00
...

Когато тестът беше в ход, можем да наблюдаваме активността на PostgreSQL с помощта на pg_activity или pg_top , за да потвърдите междинната статистика, отчетена от sysbench. В друг терминал направете:

$ su - postgres
$ pg_activity
 PostgreSQL 9.6.9 - postgres1.local - [email protected]:5432/postgres - Ref.: 2s
  Size:  654.62M -     7.67K/s        | TPS:          74
  Mem.:   39.10% -   382.72M/979.68M  | IO Max:     3395/s
  Swap:    0.20% -     3.57M/2.00G    | Read :      8.36M/s -   2141/s
  Load:    20.20 6.02 2.44            | Write:      2.54M/s -    650/s
                                                                   RUNNING QUERIES
PID    DATABASE              USER           CLIENT   CPU% MEM%   READ/s  WRITE/s     TIME+  W  IOW              state   Query
5130   sbtest              sbtest    192.168.55.61    1.0  2.8  791.57K    3.84K  0.788732  N    N             active   SELECT c FROM sbtest7 WHERE id BETWEEN 33195
 AND 33294
...

Както и потока за репликация, като погледнете pg_stat_replication таблица на главния сървър:

$ su - postgres
$ watch -n1 'psql -xc "select * from pg_stat_replication"'
Every 1.0s: psql -xc "select * from pg_stat_replication"      Tue Jul 31 13:12:08 2018
-[ RECORD 1 ]----+------------------------------
pid              | 3792
usesysid         | 16448
usename          | slave
application_name | walreceiver
client_addr      | 192.168.55.62
client_hostname  |
client_port      | 44654
backend_start    | 2018-07-30 13:41:41.707514+08
backend_xmin     |
state            | streaming
sent_location    | 0/60933D78
write_location   | 0/60933D78
flush_location   | 0/60933D78
replay_location  | 0/60933D78
sync_priority    | 0
sync_state       | async

Горната команда "watch" изпълнява командата psql на всеки 1 секунда. Трябва да видите, че колоните "*_location" се актуализират съответно, когато се случи репликация.

В края на теста трябва да видите резюмето:

SQL statistics:
    queries performed:
        read:                            67704
        write:                           19322
        other:                           9682
        total:                           96708
    transactions:                        4830   (79.34 per sec.)
    queries:                             96708  (1588.53 per sec.)
    ignored errors:                      6      (0.10 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.8723s
    total number of events:              4830

Latency (ms):
         min:                                    4.52
         avg:                                  799.70
         max:                                 8082.70
         95th percentile:                     2279.14
         sum:                              3862532.62

Threads fairness:
    events (avg/stddev):           75.4688/7.39
    execution time (avg/stddev):   60.3521/0.20

Горното обобщение ни казва, че нашият PostgreSQL сървър на база данни може да обработва средно около 80 транзакции в секунда и около 1588 заявки в секунда под 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=192.168.55.62 \
--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 (поточно репликация), 192.168.55.62 с 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 сървър (както и за MySQL). Имайте предвид, че най-добрият еталон би бил с вашите реални данни и приложения, но това може да не винаги е възможно. Може също да е ново приложение, което бързо ще се развива. Въпреки че натоварването, генерирано от sysbench, може да не изобразява вашето OLTP работно натоварване в реалния свят, може да е достатъчно добро.