В тази статия ще обсъдим sysbench, действителният стандарт за бенчмаркинг на MySQL. Ще разгледаме основите на използването на sysbench и как можем да използваме sysbench за изучаване на MySQL и вторият е най-важният аспект за нас. Практически ще използваме sysbench като инструмент за генериране на трафик, за който знаем много, защото sysbench ще задържа информация за генерирания трафик всяка секунда.

SysBench MySQL тест

Sysbench е многонишков инструмент за сравнителен анализ, базиран на luaJIT, това е действителният стандарт за бенчмаркове на MySQL, той трябва да може да се свързва с базата данни.

Инсталиране на Sysbench

Първо, трябва да инсталираме sysbench, аз инсталирам sysbench на друг сървър, за да можем да тестваме действителното въздействие на натоварването върху нашия MySQL сървър.

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashyum -y инсталирам sysbench

Това е настроено, много е лесно да се инсталира sysbench, по-добре е да се позволи на sysbench да взаимодейства с MySQL сървъра на ниво защитна стена, тъй като това е тестова среда, деактивирах защитната стена и на двата хоста, за да предотвратя всякакви трудности.

Готова среда за SysBench:

За този тест създавам базата данни sbtest и потребителя sbtest_user и ще дам всички ПРИВИЛЕГИИ на sbtest_user в базата данни sbtest.

използвайки root;

mysql> създаване на база данни sbtestmysql> създаване на потребител sbtest_user идентифициран с 'password';mysql> предоставяне на всички на sbtest.* на `sbtest_user`@`%`;mysql> показване на разрешения за sbtest_user;+------- -------------------------------------------------- +| Грантове за [email protected]%                                |+---------------------------------------- -----------------+| ПРЕДОСТАВЯТЕ ИЗПОЛЗВАНЕ НА *.* НА `sbtest_user`@`%`                 || ПРЕДОСТАВЯТЕ ВСИЧКИ ПРИВИЛЕГИИ НА `sbtest`.* НА `sbtest_user`@`%` |+------------------------------ ----------------------------------+

Изпълнение на MySQL с помощта на SysBench

Конфигурация на сравнителен тест:

Стъпката за подготовка на sysbench създава таблиците с данните, които ще бъдат използвани в бенчмарка. В този пример изпълняваме командата за подготовка. Има няколко параметъра с MySQL в началото, това ще бъдат параметрите на връзката. Другите параметри са параметри на теста oltp_read_write.lua и ние указваме самия тест, който е oltp_read_write.lua и че изпълняваме командата за подготовка. Опцията, започваща с MySQL, указва MySQL връзката, името на хоста и порта за свързване, потребителското име и паролата за свързване и схемата по подразбиране за връзката. Таблиците и параметрите table_size са свойствата на теста oltp_read_write.lua.

Това означава, че стъпката за подготовка ще създаде 16 таблици с 10 000 правила във всяка от тях. Следващата стъпка е да стартирате бенчмарка.

За да се изпълняват обикновено се предават всички параметри, които ще преминат към подготвени и някои допълнителни, които прегледахме сега, те са специфични за действителното изпълнение на бенчмарка. „ВРЕМЕТО“ параметърът определя времевия лимит за изпълнение на бенчмарка, нула означава неограничено време, бенчмаркът ще работи, докато не натиснете control+c. Ето как ще използваме sysbench в лабораторията и по този начин хората обикновено го използват при обучение, а не в настройка за сравнителен анализ.

Просто искаме да освободим трафик върху нещо, което ще разгледаме, и можем да го спрем с control+c, след като приключим с проверката.

„Интервалът за отчет“ параметрите указват колко често се отпечатват статистическите данни от sysbench. Обикновено това е настроено на 1, както в нашия пример, което кара sysbench да отпечатва реда за всяка секунда. Дори в настройките за сравнителен анализ този параметър се използва широко, защото представете си, ако имаме едночасов бенчмарк и имаме само обобщени статистически данни в края, това не казва нищо за разпределението на данните, като например как е била производителността на сървъра във времето . “нишката” опцията определя броя клиентски нишки или MySQL връзки, които да се използват в sysbench. Броят на нишките на клиента също ще има ефект върху броя на нишките на сървъра, които могат да се използват. „ставка“ параметърът определя скоростта на пристигане на транзакциите на sysbench като начин за реално посрещане на натоварването, причинено от бенчмарка. Ако транзакциите могат да продължат, те се поставят на опашка, това отново е нещо, което обикновено се използва в този вид настройка, което ще използваме сега при настройка тип обучение.

От хост на sysbench:

Подгответе набор от данни:

На виртуалната машина за сравнителен анализ ще изпълним командата подготовка на sysbench, за да създадем база данни за нашите бенчмаркове.

Тук можем да видим, че използваме sbtest_user it като потребителско име, паролата е парола и се свързваме към 192.168.66.5 DB като сървър на база данни.

sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=парола \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql- =3306 \--tables=16 \--table-size=10000 \/usr/share/sysbench/oltp_read_write.lua readysysbench 1.0.20 (с помощта на пакет LuaJIT 2.1.0-beta2) Създаване на таблица 'sbting1'...Inser 10000 записа в 'sbtest1'Създаване на вторичен индекс на 'sbtest1'......Създаване на таблица 'sbtest16'...Вмъкване на 10000 записа в 'sbtest16'Създаване на вторичен индекс на 'sbtest16'..

Имате базата данни sbtest точно тук, нека променим схемата по подразбиране на базата данни sbtest, проверете какви таблици имаме.

Ние уточнихме, че бенчмаркът трябва да създаде шестнадесет таблици и той създаде 16 таблици, можем да го видим тук

mysql> покажи таблици;+-----------------+| Tables_in_sbtest +------------------+| sbtest1          || sbtest2          |...| sbtest16         |+-----------------+16 реда в комплект (0,01 сек)

Нека проверим няколко записа от таблица.

mysql> изберете * от sbtest1 ограничение 6;

ще направим еталон. Този бенчмарк ще има един изходен ред за всяка секунда, тъй като ние задаваме rapport, интервалът е равен на една и има четири клиентски нишки, защото задаваме нишки равни на четири.

--events=N                      ограничение за общия брой събития [0]--time=N                        ограничение за общо време на изпълнение в секунди [10]

Тези по-горе две настройки (събития и време) управляват колко дълго трябва да работи SysBench. Може или да изпълни определен брой заявки, или да продължи да работи за предварително определено време.

На хост на sysbench:

sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=парола \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql- =3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \ /usr/share/sysbench/ oltp_read_write.lua run ПРЕДУПРЕЖДЕНИЕ:Ограниченията за събития и време са деактивирани, като се изпълнява безкраен testsysbench 1.0.20 (използвайки пакет LuaJIT 2.1.0-beta2) Изпълнение на теста със следните опции:Брой нишки:4 Докладвайте междинни резултати на всеки 1 секунда(и) )Инициализиране на генератора на произволни числа от текущото време. Инициализиране на работни нишки...Нишките започнаха![ 1s ] thds:4 tps:62,79 qps:1320,63 (r/w/o:933,91/257,15/129,57) lat:3 (ms8, ms) err/s:0.00 reconn/s:0.00[ 2s ] thds:4 tps:77.01 qps:1530.26 (r/w/o:1065.18/312.05/153.03) lat (ms,95%):nr. 6 /s:0.00[ 3s ] thds:4 tps:74.03 qps:1463.67 (r/w/o:1025.47/289.13/149.07) lat (ms,95%):70.55 err/s:4 con.0.0. ] thds:4 tps:69,99 qps:1414. 84 (r/w/o:991,89/282,97/139,98) lat (ms,95%):65,65 err/s:0,00 reconn/s:0,00[ 5s ] thds:4 tps:74,02 qps/w/3:3 o:1048.24/292.07/148.03) lat (ms,95%):74.46 err/s:0.00 reconn/s:0.00[ 6s ] thds:4 tps:72.99 qps:1444/wo. 145,99) lat (ms,95%):70,55 err/s:0,00 reconn/s:0,00[ 7s ] thds:4 tps:63,00 qps:1271,04 (r/w/o:890,03/255 ms 95%):87,56 err/s:0,00 reconn/s:0,00[ 8s ] thds:4 tps:72,99 qps:1439,82 (r/w/o:1008,87/284,96/145,98 msr.) /s:0.00 reconn/s:0.00[ 9s ] thds:4 tps:74.00 qps:1488.01 (r/w/o:1038.01/302.00/148.00) lat (ms,95%):er.n/01. s:0,00

така че можем да видим, че извършва приблизително 70 80 транзакции в секунда на моята машина, което означава приблизително повече от хиляда заявки в секунда. Това се изпълнява във VirtualBox на лаптоп.

От тези заявки можем да видим колко от тях са четени, колко от тях са записвания, колко от тях са други каква е 95-та персентилна латентност за транзакцията (r/w/o:1038.01/302.00/148.00), как много грешки в секунда (err/s:0.00 ) имаме и колко връзки в секунда (reconn/s:0.00) имаме. Тъй като указваме, че времето е равно на нула, това ще работи, докато не натиснете ctrl+c.

Нека проверим списъка с показване на процеси на хоста на базата данни.

mysql> покажи списък с процеси;+----+----------------+------------------ --+-------+--------+-------+------------------------- --------+-------------------------------------+| Идентификатор | Потребител            | Хост               | db     | Команда | Време  | Щат                      | Информация                                 |+----+-----------------+--------------------+--- -----+--------+-------+------------------------- --+----------------------------------------------+| 5 | event_scheduler | localhost          | NULL   | Демон  | 23200 | Изчакване на празна опашка     | NULL                                 || 11 | root            | localhost          | NULL   | Спи   | 18438 | | NULL                                 || 19 | root            | localhost          | sbtest | Запитване   | 0 | започване                   | покажи списък с процеси                     || 23 | root            | localhost          | NULL   | Спи   | 4098 | | NULL                                 || 30 | sbtest_user     | 192.168.66.6:37298 | sbtest | Спи   | 0 | | NULL                                 || 31 | sbtest_user     | 192.168.66.6:37300 | sbtest | Изпълни | 0 | чака за извършване на манипулатор | COMMIT                               || 32 | sbtest_user     | 192.168.66.6:37302 | sbtest | Спи   | 0 | | NULL                                 || 33 | sbtest_user     | 192.168.66.6:37304 | sbtest | Изпълни | 0 | Отваряне на маси             | ИЗБЕРЕТЕ c ОТ sbtest13 КЪДЕ ID=4978 |+---+----------------+----------------- ---+-------+--------+-------+------------------ ---------+----------------------------------------------+ 

 8 реда в комплект (0,00 сек.)
 

 Сървърът на базата данни практически винаги беше зает. Видях, че времето за изпълнение никога не се променя от нула на практика и беше много лесно да се хване сървъра на базата данни в действие, като когато той изпълнява „SELECT c FROM sbtest13 WHERE id=4978“. И определено имаме четири връзки от машината за сравнителен анализ
 

 
 

 
 

 
 

 
 

 
 

 По подразбиране SysBench ще се опитва да изпълнява заявки възможно най-бързо. Тази опция може да се използва за симулиране на по-бавен трафик. Тук можете да дефинирате колко транзакции трябва да се изпълняват в секунда.
 
--rate=N                        среден процент на транзакции. 0 за неограничена тарифа [0]
 
На хост на sysbench
 
[[email protected] ~]# sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=парола \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua run ПРЕДУПРЕЖДЕНИЕ:И събитията, и времевите ограничения са деактивирани, като се изпълнява безкраен testsysbench 1.0.20 (използвайки пакет LuaJIT 2.1.0-beta2) Изпълняване на теста със следното опции:Брой нишки:4Целева скорост на транзакциите:40/сек. Докладвайте междинни резултати на всеки 1 секунда(и)Инициализиране на генератора на произволни числа от текущото време Инициализиране на работните нишки...Нишките започнаха![ 1s ] thds:4 tps:42,87 qps:858,43 (r). /w/o:600.20/171.49/86.74) lat (ms,95%):73.13 err/s:0.00 reconn/s:0.00[ 1s ] дължина на опашката:0, едновременност:1[ 2s ] thds:41s thds:41s qps:857.25 (r/w/o:609.17/164.05/84.02) lat (ms,95%):101.13 err/s:0.00 reconn/s:0.00[ 2s ] дължина на опашката:0, concurrency:3. concurrency :4 tps:57.01 qps:1119.29 (r/w/o:778.20/228.06/113.03) lat (ms,95%):73.13 err/s:0.00 reconn/s:0.00[ 3s ] 0, queue length:2 concurrency:queue length:[ 15s ] thds:4 tps:0.00 qps:0.00 (r/w/o:0.00/0.00/0.00) lat (ms,95%):0.00 err/s:0.00 reconn/s:0.00[ 15s дължина:] 145, едновременност:4[ 16s ] thds:4 tps:0,00 qps:0,00 (r/w/o:0,00/0,00/0,00) lat (ms,95%):0,00 err/s:0,00 reconn.00:16s ] дължина на опашката:179, едновременност:4
 

 Така че новият параметър тук е –rate равно на 40, което означава, че ще имаме два реда в секунда, два изходни реда, а не един. Тъй като сме задали скоростта на пристигане на събитията за сравнителен анализ на 40 в секунда, ще видим текущия TPS.
 

 Това не е гарантирано, че е 40/секунда, но пристигането гарантира, че средно правим 40 транзакции в секунда и можем да наблюдаваме дължината на опашката и едновременността на втория ред. Ако направим кратък списък с процеси, е много по-лесно да хванем базата данни в състояние, в което някои връзки просто чакат тук.
 

 Докато сесията е заета, можете да видите, че транзакцията в секунда е нула (tps:0,00).
 
mysql> покажи списък с процеси;+----+----------------+------------------ --+-------+--------+-------+------------------------- ----+----------------------------------------------------- -------------------------------------------------- -------+| Идентификатор | Потребител            | Хост               | db     | Команда | Време  | Държава                  | Информация                                                                                                                                                                              - + |------------------+ | -----+--------+-------+-----------------------+- -------------------------------------------------- -------------------------------------------------- -+| 5 | event_scheduler | localhost          | NULL   | Демон  | 19162 | Изчакване на празна опашка | NULL                                                                                          | || 8 | root            | localhost          | NULL   | Запитване   | 0 | започване               | покажи списък с процеси                                                                                    | | || 21 | sbtest_user     | 192.168.66.6:49060 | sbtest | Изпълни | 33 | актуализиране               | АКТУАЛИЗИРАНЕ sbtest8 SET k=k+1 КЪДЕ id=5005                                                              || 22 | sbtest_user     | 192.168.66.6:49062 | sbtest | Изпълни | 22 | актуализиране               | АКТУАЛИЗАЦИЯ sbtest14 SET c='54592761471-89397085016-24424731626-29460127219-18466786462-73074657089-48925 | 23 | sbtest_user     | 192.168.66.6:49064 | sbtest | Изпълни | 21 | актуализиране               | АКТУАЛИЗАЦИЯ sbtest10 SET c='68520795048-46094139936-88850487689-12482054639-29231339380-71050139550-93403 || 24 | sbtest_user     | 192.168.66.6:49066 | sbtest | Изпълни | 31 | актуализиране               | ИЗТРИВАНЕ ОТ sbtest14 КЪДЕТО id=4994                                                                             |+-----------+------------------+ --+-------+--------+-------+------------------------- ----+----------------------------------------------------- -------------------------------------------------- -------+10 реда в комплект (0,00 сек)
 

 Виждаме, че това заспива за няколко секунди, това беше почти невъзможно в предишния сценарий да се получи нещо подобно.
 

 
 

 
 

 
 
Натоварен при записване трафик с краен отчет:
 

 Нека изпълним тежко за запис (но не само за запис) работно натоварване и, например, производителността на тестовата I/O подсистема, както споменах time=300 след това бенчмаркът ще работи за 300 секунди и ще ни даде краен отчет, за да го анализираме.
 
[[email protected] ~]#   sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=парола \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=8 \--time=300 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua runsysbench 1.0.20 (с помощта на пакет LuaJIT 2.1.0-beta2) Изпълнение на теста със следните опции:Брой нишки:8 Целева скорост на транзакция:40/сек. междинни резултати на всеки 1 секунда(и)Инициализиране на генератор на произволни числа от текущо време.Инициализиране на работни нишки...Нишки стартирани![ 1s ] thds:8 tps:39,87 qps:810,27 (r/w/o:570,08/159,46/80. ms,95%):82,96 err/s:0,00 reconn/s:0,00[ 1s ] дължина на опашката:0, едновременност:1[ 2s ] thds:8 tps:43,02 qps:847,39 (r/w/o:207) /85.04) lat (ms,95%):125.52 err/s:0.00 reconn/s:0.00[ 2s ] дължина на опашката:0, едновременност:0...[ 350s ] thds:8 tps:0.00 qps (r:0 /w/o:0,00/0,00/0,00) lat (ms,95%):0,00 err/s :0,00 reconn/s:0,00 [350s] Дължина на опашката:6545, Съпътстваща:1SQL Статистика:Извършва заявки:Прочетете:78624 Запишете:22385 Други:11205 Общо:112214 Транзакции:5589 (15.94 на сек.) Sec.) Игнорирани грешки:27 (0,08 в сек.) Повторно свързва:0 (0,00 в сек.) Обща статистика:Общо време:350.6412S Общ брой събития:5589 латентност (MS):Мин:12.45 Сред:74639.59 Макс:213244.02 процентил:                    100 000.00         сума:                            417160677.24 Справедливост на нишки: 6 д.                                     ср.    време за изпълнение (ср./stddev):   52145.0847/15557.93
 

 
 
АНАЛИЗ НА ОТЧЕТА:
 

 Това е доста полезно, за да проверите, че окончателният отчет ще ви даде само средни стойности. Междинните резултати ще дадат възможност за проследяване на изпълнението на база секунда по секунда. Окончателният отчет може да изглежда така, тук ще намерите информация за изпълнени заявки, извършени транзакции, колко грешки са се случили, каквато и да е загубена връзка се е случила, каква е била пропускателната способност и общото изминало време. Можете също да проверите показателите за забавяне и разпределението на заявките между нишките.