Какво е SysBench? Ако работите редовно с MySQL, най-вероятно сте чували за него. SysBench е в MySQL екосистемата от дълго време. Първоначално е написана от Петър Зайцев през 2004 г. Целта му беше да предостави инструмент за изпълнение на синтетични бенчмаркове на MySQL и хардуера, на който работи. Той е проектиран да изпълнява тестове на процесора, паметта и I/O. Имаше и опция за изпълнение на OLTP натоварване на база данни на MySQL. OLTP означава онлайн обработка на транзакции, типично работно натоварване за онлайн приложения като електронна търговия, системи за въвеждане на поръчки или финансови транзакции.
В тази публикация в блога ще се съсредоточим върху функцията за сравнение на SQL, но имайте предвид, че хардуерните бенчмаркове също могат да бъдат много полезни при идентифициране на проблеми на сървърите на бази данни. Например, I/O бенчмаркът е предназначен да симулира InnoDB I/O работно натоварване, докато тестовете на процесора включват симулация на много едновременна, многопроточна среда заедно с тестове за мютекс спорове – нещо, което също наподобява натоварване от тип база данни.
История и архитектура на SysBench
Както споменахме, SysBench първоначално е създаден през 2004 г. от Петър Зайцев. Скоро след това Алексей Копитов поема развитието му. Достигна версия 0.4.12 и разработката спря. След дълга пауза Алексей отново започна да работи върху SysBench през 2016 г. Скоро беше пусната версия 0.5 с пренаписан OLTP бенчмарк за използване на базирани на LUA скриптове. След това, през 2017 г., беше пуснат SysBench 1.0. Това беше като ден и нощ в сравнение със старата версия 0.4.12. Първо и най-важното, вместо твърдо кодирани скриптове, сега имаме възможността да персонализираме бенчмаркове с помощта на LUA. Например, Percona създаде бенчмарк, подобен на TPCC, който може да бъде изпълнен с помощта на SysBench. Нека да разгледаме набързо текущата архитектура на SysBench.
SysBench е двоичен файл в C, който използва LUA скриптове за изпълнение на бенчмаркове. Тези скриптове трябва да:
- Управление на въвеждане от параметри на командния ред
- Определете всички режими, които се предполага да използва бенчмаркът (подготовка, изпълнение, почистване)
- Подгответе всички данни
- Определете как ще се изпълнява бенчмаркът (как ще изглеждат заявките и т.н.)
Скриптовете могат да използват множество връзки към базата данни, те също могат да обработват резултати, ако искате да създадете сложни сравнителни показатели, при които заявките зависят от набора от резултати от предишни заявки. Със SysBench 1.0 е възможно да се създават хистограми на латентност. Възможно е също LUA скриптовете да улавят и обработват грешки чрез кукички за грешки. Има поддръжка за паралелизиране в LUA скриптовете, множество заявки могат да се изпълняват паралелно, което прави, например, предоставянето много по-бързо. Не на последно място, вече се поддържат множество изходни формати. Преди SysBench генерираше само четим от човека изход. Сега е възможно да се генерира като CSV или JSON, което прави много по-лесно извършването на последваща обработка и генериране на графики, като се използва например gnuplot или подаването на данните в Prometheus, Graphite или подобно хранилище за данни.
Защо SysBench?
Основната причина, поради която SysBench стана популярен, е фактът, че е лесен за използване. Някой без предварителни познания може да започне да го използва за минути. Той също така предоставя по подразбиране еталонни показатели, които обхващат повечето случаи - OLTP натоварвания, само за четене или за четене-запис, търсене на първичен ключ и актуализации на първичен ключ. Всичко това причини повечето проблеми за MySQL, до MySQL 8.0. Това беше и причина SysBench да е толкова популярен в различни бенчмаркове и сравнения, публикувани в Интернет. Тези публикации помогнаха за популяризирането на този инструмент и го превърнаха в основния синтетичен еталон за MySQL.
Друго добро нещо за SysBench е, че след версия 0.5 и включване на LUA всеки може да подготви всякакъв вид бенчмарк. Вече споменахме бенчмарк, подобен на TPCC, но всеки може да изработи нещо, което да наподобява нейното производствено натоварване. Не казваме, че е просто, най-вероятно ще е отнемащ време процес, но притежаването на тази способност е от полза, ако трябва да подготвите персонализиран сравнителен показател.
Като синтетичен бенчмарк, SysBench не е инструмент, който можете да използвате за настройване на конфигурации на вашите MySQL сървъри (освен ако не сте подготвили LUA скриптове с персонализирано работно натоварване или вашето работно натоварване е много подобно на натоварванията за сравнителни тестове, с които идва SysBench). Това, за което е чудесно, е да сравнявате производителността на различен хардуер. Можете лесно да сравните производителността на, да речем, различни типове възли, предлагани от вашия доставчик на облак, и максималния QPS (заявки в секунда), които предлагат. Познавайки този показател и знаейки какво плащате за даден възел, можете да изчислите още по-важен показател - QP$ (заявки за долар). Това ще ви позволи да определите какъв тип възел да използвате при изграждането на рентабилна среда. Разбира се, SysBench може да се използва и за първоначална настройка и оценка на осъществимостта на даден дизайн. Да кажем, че изграждаме клъстер Galera, обхващащ целия свят - Северна Америка, ЕС, Азия. С колко вмъквания в секунда може да се справи такава настройка? Каква би била латентността на извършване? Има ли смисъл дори да се прави доказателство за концепция или може би латентността на мрежата е достатъчно голяма, че дори обикновеното натоварване не работи, както бихте очаквали.
Ами стрес тестовете? Не всички са преминали към облака, все още има компании, които предпочитат да изградят своя собствена инфраструктура. Всеки придобит нов сървър трябва да премине през период на загряване, по време на който ще го стресирате, за да определите потенциални хардуерни дефекти. В този случай SysBench също може да помогне. Или чрез изпълнение на OLTP натоварване, което претоварва сървъра, или можете също да използвате специални тестове за CPU, диск и памет.
Както можете да видите, има много случаи, в които дори прост, синтетичен бенчмарк може да бъде много полезен. В следващия параграф ще разгледаме какво можем да правим със SysBench.
Какво може да направи SysBench за вас?
Какви тестове можете да изпълнявате?
Както бе споменато в началото, ще се съсредоточим върху OLTP бенчмарковете и само като напомняне ще повторим, че SysBench може да се използва и за извършване на I/O, CPU и тестове на паметта. Нека да разгледаме критериите за сравнение, с които идва SysBench 1.0 (премахнахме някои помощни LUA файлове и LUA скриптове без база данни от този списък).
-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.luaНека ги прегледаме един по един.
Първо, bulk_insert.lua. Този тест може да се използва за сравнение на способността на MySQL да изпълнява многоредови вмъквания. Това може да бъде доста полезно, когато проверявате, например, производителността на репликацията или клъстера Galera. В първия случай може да ви помогне да отговорите на въпрос:„колко бързо мога да вмъкна, преди да започне забавянето на репликацията?“. В по-късния случай ще ви каже колко бързо могат да бъдат вмъкнати данни в клъстер на Galera предвид текущата латентност на мрежата.
Всички oltp_* скриптове споделят обща структура на таблицата. Първите две от тях (oltp_delete.lua и oltp_insert.lua) изпълняват единични оператори DELETE и INSERT. Отново, това може да бъде тест или за репликация, или за клъстер Galera - натиснете го до границите и вижте какво количество вмъкване или прочистване може да понесе. Имаме и други бенчмаркове, фокусирани върху конкретна функционалност - oltp_point_select, oltp_update_index и oltp_update_non_index. Те ще изпълнят подмножество от заявки - селектиране, базирано на първичен ключ, актуализации, базирани на индекс, и актуализации, които не са базирани на индекси. Ако искате да тествате някои от тези функции, тестовете са там. Имаме и по-сложни сравнителни показатели, които се основават на OLTP работни натоварвания:oltp_read_only, oltp_read_write и oltp_write_only. Можете да изпълнявате или работно натоварване само за четене, което ще се състои от различни типове заявки SELECT, можете да изпълнявате само записи (смес от DELETE, INSERT и UPDATE) или можете да стартирате микс от тези две. И накрая, като използвате select_random_points и select_random_ranges, можете да стартирате произволен SELECT или като използвате произволни точки в списъка IN() или произволни диапазони, като използвате BETWEEN.
Как можете да конфигурирате бенчмарк?
Това, което също е важно, бенчмарковете са конфигурируеми - можете да изпълнявате различни модели на работно натоварване, като използвате един и същ бенчмарк. Нека да разгледаме двата най-често срещани бенчмарка за изпълнение. Ще се потопим дълбоко в сравнителните показатели за OLTP read_only и OLTP read_write. На първо място, SysBench има някои общи опции за конфигурация. Тук ще обсъдим само най-важните, можете да проверите всички, като изпълните:
sysbench --helpНека да ги разгледаме.
--threads=N number of threads to use [1]Можете да дефинирате какъв вид паралелност искате да генерира SysBench. MySQL, както всеки софтуер, има някои ограничения за мащабируемост и неговата производителност ще достигне връх при някакво ниво на едновременност. Тази настройка помага да се симулират различни съвпадения за дадено работно натоварване и да се провери дали вече е преминало най-добрата точка.
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]Тези две настройки определят колко дълго трябва да работи SysBench. Може или да изпълни определен брой заявки, или да продължи да работи за предварително определено време.
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]Това се разбира от само себе си. SysBench генерира статистически резултати от тестовете и тези резултати могат да бъдат засегнати, ако MySQL е в студено състояние. Warmup помага за идентифициране на „редовна“ пропускателна способност чрез изпълнение на бенчмарк за предварително определено време, което позволява загряване на кеша, буферните пулове и т.н.
--rate=N average transactions rate. 0 for unlimited rate [0]По подразбиране SysBench ще се опитва да изпълнява заявки възможно най-бързо. Тази опция може да се използва за симулиране на по-бавен трафик. Тук можете да дефинирате колко транзакции трябва да се изпълняват в секунда.
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]По подразбиране SysBench генерира отчет, след като завърши изпълнението си и не се отчита напредък, докато бенчмаркът се изпълнява. Използвайки тази опция, можете да направите SysBench по-подробен, докато бенчмаркът все още работи.
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBench ви дава възможност да генерирате различни видове разпределение на данни. Всички те могат да имат свои собствени цели. Опцията по подразбиране, „специална“, дефинира няколко (може да се конфигурира) горещи точки в данните, нещо, което е доста често срещано в уеб приложенията. Можете също да използвате други дистрибуции, ако вашите данни се държат по различен начин. Като направите различен избор тук, можете също да промените начина, по който вашата база данни е натоварена. Например, равномерното разпределение, при което всички редове имат еднаква вероятност да бъдат достъпни, е много по-интензивна операция. Той ще използва повече буферен пул за съхраняване на всички данни и ще бъде много по-интензивен на диск, ако наборът ви от данни не се побира в паметта. От друга страна, специалната дистрибуция с няколко горещи точки ще постави по-малко напрежение върху диска, тъй като е по-вероятно горещите редове да се съхраняват в буферния пул и достъпът до редове, съхранявани на диска, е много по-малко вероятен. За някои от типовете разпределение на данни SysBench ви дава повече настройки. Можете да намерите тази информация в изхода „sysbench --help“.
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]С помощта на тази настройка можете да решите дали SysBench да използва подготвени оператори (стига да са налични в даденото хранилище за данни - за MySQL това означава, че PS ще бъде активиран по подразбиране) или не. Това може да има значение при работа с прокси сървъри като ProxySQL или MaxScale – те трябва да третират подготвените оператори по специален начин и всички те трябва да бъдат насочени към един хост, което прави невъзможно тестването на мащабируемостта на прокси сървъра.
В допълнение към общите опции за конфигурация, всеки от тестовете може да има своя собствена конфигурация. Можете да проверите какво е възможно, като изпълните:
[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
oltp_read_only.lua options:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
--secondary[=on|off] Use a secondary index in place of the PRIMARY KEY [off]
--create_secondary[=on|off] Create a secondary index in addition to the PRIMARY KEY [on]
--index_updates=N Number of UPDATE index queries per transaction [1]
--range_size=N Range size for range SELECT queries [100]
--auto_inc[=on|off] Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--tables=N Number of tables [1]
--mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--table_size=N Number of rows per table [10000]
--pgsql_variant=STRING Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]
--point_selects=N Number of point SELECT queries per transaction [10]Отново ще обсъдим най-важните опции от тук. На първо място, имате контрол как точно ще изглежда една транзакция. Най-общо казано, той се състои от различни типове заявки - INSERT, DELETE, различен тип SELECT (търсене на точки, диапазон, агрегиране) и UPDATE (индексирани, неиндексирани). Използване на променливи като:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--index_updates=N Number of UPDATE index queries per transaction [1]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--point_selects=N Number of point SELECT queries per transaction [10]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]Можете да дефинирате как трябва да изглежда една транзакция. Както можете да видите, като разгледате стойностите по подразбиране, по-голямата част от заявките са SELECT - основно избиране на точки, но също и различни типове SELECTs на диапазон (можете да деактивирате всички от тях, като зададете range_selects на изключено). Можете да настроите натоварването към по-голямо натоварване при запис, като увеличите броя на актуализациите или заявките INSERT/DELETE. Възможно е също така да настроите настройки, свързани с вторични индекси, автоматично увеличение, но също и размер на набора от данни (брой таблици и колко реда трябва да съдържа всяка от тях). Това ви позволява да персонализирате доста добре работното си натоварване.
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]Това е друга настройка, доста важна при работа с прокси сървъри. По подразбиране SysBench ще се опитва да изпълнява заявки в изрична транзакция. По този начин наборът от данни ще остане последователен и няма да бъде засегнат:SysBench, например, ще изпълни INSERT и DELETE на един и същи ред, като се увери, че наборът от данни няма да нараства (влияе върху способността ви да възпроизвеждате резултати). Въпреки това, прокситата ще третират изричните транзакции по различен начин - всички заявки, изпълнявани в рамките на транзакция, трябва да се изпълняват на един и същ хост, като по този начин се премахва възможността за мащабиране на работното натоварване. Моля, имайте предвид, че деактивирането на транзакциите ще доведе до разминаване на набора от данни от първоначалната точка. Това може също да предизвика някои проблеми като дублирани ключови грешки или други подобни. За да можете да деактивирате транзакции, може да искате да разгледате и:
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]Тази настройка ви позволява да посочите кодове за грешки от MySQL, които SysBench трябва да игнорира (и да не прекъсва връзката). Например, за да игнорирате грешки като:грешка 1062 (Дублиращ запис „6“ за ключ „PRIMARY“), трябва да подадете този код на грешка:--mysql-ignore-errors=1062
Важно е също така, че всеки бенчмарк трябва да представя начин за предоставяне на набор от данни за тестове, стартиране и след това да го почисти след приключване на тестовете. Това се прави с помощта на команди „подготви“, „изпълни“ и „почисти“. Ще покажем как се прави това в следващия раздел.
Примери
В този раздел ще разгледаме някои примери за това за какво може да се използва SysBench. Както споменахме по-рано, ще се съсредоточим върху двата най-популярни бенчмарка - OLTP само за четене и OLTP за четене/запис. Понякога може да има смисъл да използвате други сравнителни показатели, но поне ще можем да ви покажем как тези два могат да бъдат персонализирани.
Проверки на първичен ключ
На първо място, трябва да решим кой бенчмарк ще стартираме, само за четене или за четене-запис. Технически погледнато, това не прави разлика, тъй като можем да премахнем записи от R/W бенчмарк. Нека се съсредоточим върху този, който е само за четене.
Като първа стъпка трябва да подготвим набор от данни. Трябва да решим колко голям трябва да бъде. За този конкретен бенчмарк, използвайки настройките по подразбиране (така че се създават вторични индекси), 1 милион реда ще доведат до ~240 MB данни. Десет таблици, 1000 000 реда всяка се равнява на 2,4 GB:
[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun 1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun 1 12:10 ..
-rw-r----- 1 mysql mysql 65 Jun 1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest9.ibdТова трябва да ви даде представа колко маси искате и колко големи трябва да бъдат те. Да кажем, че искаме да тестваме работното натоварване в паметта, така че искаме да създадем таблици, които да се поберат в буферния пул на InnoDB. От друга страна, ние също искаме да се уверим, че има достатъчно таблици, за да не се превърнат в пречка (или, че количеството таблици съответства на това, което бихте очаквали във вашата производствена настройка). Нека подготвим нашия набор от данни. Моля, имайте предвид, че по подразбиране SysBench търси схема „sbtest“, която трябва да съществува, преди да подготвите набора от данни. Може да се наложи да го създадете ръчно.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
Initializing worker threads...
Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...След като имаме нашите данни, нека подготвим команда за стартиране на теста. Искаме да тестваме търсенето на първичен ключ, затова ще деактивираме всички други видове SELECT. Ние също така ще деактивираме подготвените изрази, тъй като искаме да тестваме редовни заявки. Ще тестваме ниско ниво на едновременност, да кажем 16 нишки. Нашата команда може да изглежда така:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 runКакво направихме тук? Зададохме броя на нишките на 16. Решихме, че искаме нашият бенчмарк да работи за 300 секунди, без ограничение на изпълнените заявки. Дефинирахме свързаност с базата данни, брой таблици и техния размер. Ние също така деактивирахме всички диапазони SELECT, също така деактивирахме подготвени оператори. Накрая задаваме интервала на отчета на една секунда. Ето как може да изглежда примерен изход:
[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00Всяка секунда виждаме моментна снимка на статистически данни за натоварването. Това е доста полезно за проследяване и начертаване - окончателният отчет ще ви даде само средни стойности. Междинните резултати ще дадат възможност за проследяване на изпълнението на база секунда по секунда. Окончателният отчет може да изглежда така:
SQL statistics:
queries performed:
read: 614660
write: 0
other: 122932
total: 737592
transactions: 61466 (204.84 per sec.)
queries: 737592 (2458.08 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 204.8403
time elapsed: 300.0679s
total number of events: 61466
Latency (ms):
min: 24.91
avg: 78.10
max: 331.91
95th percentile: 137.35
sum: 4800234.60
Threads fairness:
events (avg/stddev): 3841.6250/20.87
execution time (avg/stddev): 300.0147/0.02Тук ще намерите информация за изпълнени заявки и други (BEGIN/COMMIT) оператори. Ще научите колко транзакции са били изпълнени, колко грешки са се случили, каква е пропускателната способност и общото изминало време. Можете също да проверите показателите за забавяне и разпределението на заявките между нишките.
Ако се интересуваме от разпределението на латентността, бихме могли също да предадем аргумент „--histogram“ на SysBench. Това води до допълнителен изход като по-долу:
Latency histogram (values are in milliseconds)
value ------------- distribution ------------- count
29.194 |****** 1
30.815 |****** 1
31.945 |*********** 2
33.718 |****** 1
34.954 |*********** 2
35.589 |****** 1
37.565 |*********************** 4
38.247 |****** 1
38.942 |****** 1
39.650 |*********** 2
40.370 |*********** 2
41.104 |***************** 3
41.851 |***************************** 5
42.611 |***************** 3
43.385 |***************** 3
44.173 |*********** 2
44.976 |**************************************** 7
45.793 |*********************** 4
46.625 |*********** 2
47.472 |***************************** 5
48.335 |**************************************** 7
49.213 |*********** 2
50.107 |********************************** 6
51.018 |*********************** 4
51.945 |**************************************** 7
52.889 |***************** 3
53.850 |***************** 3
54.828 |*********************** 4
55.824 |*********** 2
57.871 |*********** 2
58.923 |*********** 2
59.993 |****** 1
61.083 |****** 1
63.323 |*********** 2
66.838 |****** 1
71.830 |****** 1След като сме добри с нашите резултати, можем да изчистим данните:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanupНатоварен при записване трафик
Нека си представим тук, че искаме да изпълним тежко за запис (но не само за запис) работно натоварване и, например, да тестваме производителността на I/O подсистемата. На първо място, трябва да решим колко голям трябва да бъде наборът от данни. Ще приемем ~48 GB данни (20 таблици, 10 000 000 реда всяка). Трябва да го подготвим. Този път ще използваме бенчмарк за четене-запис.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepareСлед като това е направено, можем да настроим настройките по подразбиране, за да принудим повече записи в микса на заявките:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 runКакто можете да видите от междинните резултати, транзакциите вече са тежки за запис:
[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00Разбиране на резултатите
Както показахме по-горе, SysBench е страхотен инструмент, който може да помогне за определяне на някои от проблемите с производителността на MySQL или MariaDB. Може да се използва и за първоначална настройка на конфигурацията на вашата база данни. Разбира се, трябва да имате предвид, че за да извлечете най-доброто от своите критерии за сравнение, трябва да разберете защо резултатите изглеждат така. Това ще изисква прозрения за вътрешните показатели на MySQL с помощта на инструменти за наблюдение, например ClusterControl. Това е доста важно да запомните – ако не разбирате защо представянето е било такова, може да направите неправилни заключения от критериите за сравнение. Винаги има пречка и SysBench може да ви помогне да повдигнете проблеми с производителността, които след това трябва да идентифицирате.
