Co je SysBench? Pokud s MySQL pracujete pravidelně, pak jste o ní s největší pravděpodobností slyšeli. SysBench je v ekosystému MySQL již dlouhou dobu. Původně ji napsal Peter Zaitsev v roce 2004. Jejím účelem bylo poskytnout nástroj pro spouštění syntetických benchmarků MySQL a hardwaru, na kterém běží. Byl navržen tak, aby spouštěl testy CPU, paměti a I/O. Měl také možnost spouštět zátěž OLTP na databázi MySQL. OLTP je zkratka pro online zpracování transakcí, typickou pracovní zátěž pro online aplikace, jako je elektronický obchod, zadávání objednávek nebo systémy finančních transakcí.
V tomto příspěvku na blogu se zaměříme na funkci SQL benchmark, ale mějte na paměti, že hardwarové benchmarky mohou být také velmi užitečné při identifikaci problémů na databázových serverech. Například I/O benchmark byl zamýšlen k simulaci I/O zátěže InnoDB, zatímco testy CPU zahrnují simulaci vysoce souběžného prostředí s více běhouny spolu s testy na mutexové spory – něco, co také připomíná databázový typ zátěže.
Historie a architektura SysBench
Jak již bylo zmíněno, SysBench byl původně vytvořen v roce 2004 Peterem Zaitsevem. Brzy poté převzal jeho vývoj Alexey Kopytov. Dosáhla verze 0.4.12 a vývoj se zastavil. Po dlouhé přestávce začal Alexey znovu pracovat na SysBench v roce 2016. Brzy byla vydána verze 0.5 s benchmarkem OLTP přepsaným pro použití skriptů založených na LUA. Poté, v roce 2017, byl vydán SysBench 1.0. Bylo to jako den a noc ve srovnání se starou verzí 0.4.12. Za prvé a především, místo pevně kódovaných skriptů nyní máme možnost přizpůsobit benchmarky pomocí LUA. Například společnost Percona vytvořila benchmark podobný TPCC, který lze spustit pomocí SysBench. Pojďme se rychle podívat na současnou architekturu SysBench.
SysBench je binární kód C, který používá skripty LUA ke spouštění benchmarků. Tyto skripty musí:
- Ovládejte vstup z parametrů příkazového řádku
- Definujte všechny režimy, které má benchmark používat (příprava, spuštění, vyčištění)
- Připravte všechna data
- Definujte, jak bude srovnávací test prováděn (jak budou vypadat dotazy atd.)
Skripty mohou využívat více připojení k databázi, mohou také zpracovávat výsledky, pokud chcete vytvářet komplexní benchmarky, kde dotazy závisí na sadě výsledků předchozích dotazů. Pomocí SysBench 1.0 je možné vytvářet histogramy latence. Je také možné, aby skripty LUA zachytily a zpracovaly chyby prostřednictvím chybových háčků. Ve skriptech LUA je podpora paralelizace, paralelně lze provádět více dotazů, což například výrazně zrychluje poskytování. V neposlední řadě je nyní podporováno více výstupních formátů. Než SysBench generoval pouze výstup čitelný pro člověka. Nyní je možné je generovat jako CSV nebo JSON, takže je mnohem snazší provádět následné zpracování a generovat grafy pomocí například gnuplotu nebo vkládat data do datového úložiště Prometheus, Graphite nebo podobného úložiště.
Proč SysBench?
Hlavním důvodem, proč se SysBench stal populárním, je skutečnost, že se snadno používá. Někdo bez předchozích znalostí jej může začít používat během několika minut. Ve výchozím nastavení také poskytuje benchmarky, které pokrývají většinu případů – pracovní zátěž OLTP, pouze pro čtení nebo pro čtení a zápis, vyhledávání primárního klíče a aktualizace primárního klíče. To vše způsobilo většinu problémů pro MySQL, až po MySQL 8.0. To byl také důvod, proč byl SysBench tak populární v různých benchmarcích a srovnáních publikovaných na internetu. Tyto příspěvky pomohly propagovat tento nástroj a staly se z něj syntetický benchmark pro MySQL.
Další dobrá věc na SysBench je, že od verze 0.5 a začlenění LUA může kdokoli připravit jakýkoli druh benchmarku. Již jsme zmínili benchmark podobný TPCC, ale každý může vytvořit něco, co bude připomínat její produkční náplň. Neříkáme, že je to jednoduché, s největší pravděpodobností to bude časově náročný proces, ale mít tuto schopnost je výhodné, pokud potřebujete připravit vlastní benchmark.
Jelikož jde o syntetický benchmark, SysBench není nástroj, který můžete použít k vyladění konfigurací vašich MySQL serverů (pokud jste si nepřipravili LUA skripty s vlastní pracovní zátěží nebo vaše pracovní zátěž není náhodou velmi podobná zátěžím benchmarku, se kterými přichází SysBench). K čemu je to skvělé, je porovnat výkon různého hardwaru. Můžete snadno porovnat výkon, řekněme, různých typů uzlů nabízených vaším poskytovatelem cloudu a maximální QPS (dotazy za sekundu), které nabízejí. Znáte-li tuto metriku a víte, kolik platíte za daný uzel, můžete vypočítat ještě důležitější metriku – QP$ (počet dotazů za dolar). To vám umožní určit, jaký typ uzlu použít při vytváření nákladově efektivního prostředí. SysBench lze samozřejmě použít i pro prvotní ladění a posouzení proveditelnosti daného návrhu. Řekněme, že vybudujeme klastr Galera po celém světě – Severní Amerika, EU, Asie. Kolik vložek za sekundu zvládne takové nastavení? Jaká by byla latence potvrzení? Má vůbec smysl dělat důkaz konceptu nebo je možná latence sítě dostatečně vysoká na to, aby ani jednoduchá pracovní zátěž nefungovala tak, jak byste očekávali?
A co zátěžové testování? Ne všichni přešli do cloudu, stále existují společnosti preferující budování vlastní infrastruktury. Každý nově pořízený server by měl projít zahřívacím obdobím, během kterého jej budete zatěžovat, abyste odhalili potenciální hardwarové závady. V tomto případě může pomoci také SysBench. Buď provedením zátěže OLTP, která přetíží server, nebo můžete také použít vyhrazené benchmarky pro CPU, disk a paměť.
Jak vidíte, existuje mnoho případů, kdy i jednoduchý, syntetický benchmark může být velmi užitečný. V dalším odstavci se podíváme na to, co můžeme dělat se SysBench.
Co pro vás SysBench může udělat?
Jaké testy můžete spustit?
Jak již bylo zmíněno na začátku, zaměříme se na benchmarky OLTP a jen pro připomenutí zopakujeme, že SysBench lze použít i k provádění I/O, CPU a testů paměti. Pojďme se podívat na benchmarky, se kterými SysBench 1.0 přichází (z tohoto seznamu jsme odstranili některé pomocné soubory LUA a nedatabázové skripty 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.luaPojďme si je projít jeden po druhém.
Nejprve bulk_insert.lua. Tento test lze použít k porovnání schopnosti MySQL provádět víceřádkové vkládání. To může být docela užitečné například při kontrole výkonu replikace nebo clusteru Galera. V prvním případě vám může pomoci odpovědět na otázku:„Jak rychle mohu vložit, než se projeví zpoždění replikace?“. V pozdějším případě vám řekne, jak rychle lze data vložit do clusteru Galera s ohledem na aktuální latenci sítě.
Všechny skripty oltp_* sdílejí společnou strukturu tabulky. První dva z nich (oltp_delete.lua a oltp_insert.lua) provádějí jednotlivé příkazy DELETE a INSERT. Opět by to mohl být test buď replikace, nebo clusteru Galera – posuňte to na limity a uvidíte, jaké množství vkládání nebo čištění dokáže zvládnout. Máme také další benchmarky zaměřené na konkrétní funkcionalitu – oltp_point_select, oltp_update_index a oltp_update_non_index. Ty provedou podmnožinu dotazů – výběry založené na primárním klíči, aktualizace založené na indexu a aktualizace nezaložené na indexu. Pokud chcete otestovat některé z těchto funkcí, testy jsou zde. Máme také složitější benchmarky, které jsou založeny na pracovní zátěži OLTP:oltp_read_only, oltp_read_write a oltp_write_only. Můžete spustit buď pracovní zátěž pouze pro čtení, která se bude skládat z různých typů SELECT dotazů, můžete spouštět pouze zápisy (kombinace DELETE, INSERT a UPDATE) nebo můžete spustit kombinaci těchto dvou. Nakonec pomocí select_random_points a select_random_ranges můžete spustit nějaké náhodné SELECT buď pomocí náhodných bodů v seznamu IN() nebo náhodných rozsahů pomocí BETWEEN.
Jak můžete nakonfigurovat srovnávací test?
Co je také důležité, benchmarky jsou konfigurovatelné – pomocí stejného benchmarku můžete spouštět různé vzory zátěže. Pojďme se podívat na dva nejběžnější benchmarky, které je třeba provést. Budeme se hluboce ponořit do benchmarků OLTP read_only a OLTP read_write. Za prvé, SysBench má některé obecné možnosti konfigurace. Zde probereme pouze ty nejdůležitější, všechny si můžete zkontrolovat spuštěním:
sysbench --helpPojďme se na ně podívat.
--threads=N number of threads to use [1]Můžete definovat, jaký druh souběžnosti chcete, aby SysBench generoval. MySQL, jako každý software, má určitá omezení škálovatelnosti a jeho výkon bude vrcholit na určité úrovni souběžnosti. Toto nastavení pomáhá simulovat různé souběžnosti pro danou zátěž a zkontrolovat, zda již prošla sladkou tečkou.
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]Tato dvě nastavení určují, jak dlouho má SysBench běžet. Může buď provést určitý počet dotazů, nebo může běžet po předem definovanou dobu.
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]To je samovysvětlující. SysBench generuje statistické výsledky z testů a tyto výsledky mohou být ovlivněny, pokud je MySQL ve studeném stavu. Warmup pomáhá identifikovat „běžnou“ propustnost prováděním benchmarku po předem definovanou dobu, což umožňuje zahřátí mezipaměti, vyrovnávací paměti atd.
--rate=N average transactions rate. 0 for unlimited rate [0]Ve výchozím nastavení se SysBench pokusí provádět dotazy co nejrychleji. Tuto možnost lze použít pro simulaci pomalejšího provozu. Zde můžete definovat, kolik transakcí se má provést za sekundu.
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]Ve výchozím nastavení SysBench generuje zprávu po dokončení svého běhu a během běhu benchmarku není hlášen žádný pokrok. Pomocí této možnosti můžete udělat SysBench podrobnější, zatímco benchmark stále běží.
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBench vám dává možnost generovat různé typy distribuce dat. Všechny mohou mít své vlastní účely. Výchozí volba „speciální“ definuje několik (je konfigurovatelných) aktivních bodů v datech, což je ve webových aplikacích zcela běžné. Můžete také použít jiné distribuce, pokud se vaše data chovají jiným způsobem. Tím, že zde provedete jinou volbu, můžete také změnit způsob, jakým je vaše databáze namáhána. Například rovnoměrná distribuce, kde všechny řádky mají stejnou pravděpodobnost přístupu, je operace mnohem náročnější na paměť. K uložení všech dat bude používat více vyrovnávací paměti a bude mnohem náročnější na disk, pokud se vaše datová sada nevejde do paměti. Na druhou stranu speciální distribuce s několika hot-spoty bude méně zatěžovat disk, protože horké řádky budou s větší pravděpodobností udržovány ve fondu vyrovnávací paměti a přístup k řádkům uloženým na disku je mnohem méně pravděpodobný. Pro některé typy distribuce dat vám SysBench nabízí více vylepšení. Tyto informace můžete najít ve výstupu „sysbench --help“.
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]Pomocí tohoto nastavení se můžete rozhodnout, zda má SysBench používat připravené příkazy (pokud jsou dostupné v daném datovém úložišti - pro MySQL to znamená, že PS bude standardně povoleno) nebo ne. To může být rozdíl při práci s proxy, jako je ProxySQL nebo MaxScale – měly by zacházet s připravenými příkazy zvláštním způsobem a všechny by měly být směrovány na jednoho hostitele, což znemožňuje testovat škálovatelnost proxy.
Kromě obecných možností konfigurace může mít každý z testů svou vlastní konfiguraci. Můžete zkontrolovat, co je možné, spuštěním:
[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]Znovu zde probereme nejdůležitější možnosti. V první řadě máte kontrolu nad tím, jak přesně bude transakce vypadat. Obecně řečeno se skládá z různých typů dotazů - INSERT, DELETE, různého typu SELECT (vyhledávání bodů, rozsah, agregace) a UPDATE (indexované, neindexované). Pomocí proměnných jako:
--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]Můžete definovat, jak má transakce vypadat. Jak můžete vidět, když se podíváte na výchozí hodnoty, většina dotazů jsou SELECTy - hlavně výběry bodů, ale také různé typy SELECTů rozsahu (všechny můžete zakázat nastavením range_selects na off). Můžete vyladit pracovní zátěž směrem k větší zátěži pro zápis zvýšením počtu aktualizací nebo dotazů INSERT/DELETE. Je také možné ladit nastavení související se sekundárními indexy, automatickým přírůstkem, ale také velikostí datové sady (počet tabulek a počet řádků, které by každá z nich měla obsahovat). Díky tomu můžete svou pracovní zátěž docela dobře přizpůsobit.
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]To je další nastavení, docela důležité při práci s proxy. Ve výchozím nastavení se SysBench pokusí provést dotazy v explicitní transakci. Tímto způsobem zůstane datová sada konzistentní a nebude ovlivněna:SysBench například provede INSERT a DELETE na stejném řádku, čímž zajistí, že se sada dat nebude zvětšovat (ovlivní vaši schopnost reprodukovat výsledky). Proxy však budou s explicitními transakcemi zacházet odlišně – všechny dotazy provedené v rámci transakce by měly být provedeny na stejném hostiteli, čímž se odstraní možnost škálovat zátěž. Mějte prosím na paměti, že deaktivace transakcí bude mít za následek odchylku datové sady od počátečního bodu. Může také vyvolat některé problémy, jako jsou chyby duplicitních klíčů nebo podobně. Abyste mohli zakázat transakce, můžete se také podívat na:
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]Toto nastavení vám umožňuje zadat chybové kódy z MySQL, které by měl SysBench ignorovat (a nezabíjet připojení). Chcete-li například ignorovat chyby jako:chyba 1062 (duplicitní záznam '6' pro klíč 'PRIMARY'), měli byste předat tento kód chyby:--mysql-ignore-errors=1062
Co je také důležité, každý benchmark by měl představovat způsob, jak poskytnout sadu dat pro testy, spustit je a poté je po dokončení testů vyčistit. To se provádí pomocí příkazů ‚připravit‘, ‚spustit‘ a ‚vyčistit‘. Jak se to dělá, si ukážeme v další části.
Příklady
V této části si projdeme několik příkladů toho, k čemu lze SysBench použít. Jak již bylo zmíněno dříve, zaměříme se na dva nejoblíbenější benchmarky – OLTP pouze pro čtení a OLTP pro čtení/zápis. Někdy může mít smysl použít jiné benchmarky, ale alespoň vám budeme moci ukázat, jak lze tyto dva přizpůsobit.
Vyhledávání primárního klíče
Nejprve se musíme rozhodnout, který benchmark spustíme, zda jen pro čtení nebo pro čtení a zápis. Technicky vzato to není rozdíl, protože můžeme odstranit zápisy z R/W benchmarku. Zaměřme se na ten, který je pouze pro čtení.
Jako první krok musíme připravit datovou sadu. Musíme se rozhodnout, jak velký by měl být. Pro tento konkrétní benchmark bude při použití výchozího nastavení (takže jsou vytvořeny sekundární indexy) výsledkem 1 milionu řádků ~240 MB dat. Deset tabulek, každá 1 000 000 řádků odpovídá 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.ibdTo by vám mělo poskytnout představu, kolik stolů chcete a jak velké by měly být. Řekněme, že chceme otestovat zátěž v paměti, takže chceme vytvořit tabulky, které se vejdou do zásobníku vyrovnávací paměti InnoDB. Na druhou stranu se chceme také ujistit, že je dostatek stolů, aby se nestaly úzkým hrdlem (nebo aby množství stolů odpovídalo tomu, co byste očekávali ve vašem produkčním nastavení). Připravme si naši datovou sadu. Mějte prosím na paměti, že ve výchozím nastavení SysBench hledá schéma „sbtest“, které musí existovat, než připravíte sadu dat. Možná jej budete muset vytvořit ručně.
[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'...Jakmile máme data, připravíme příkaz ke spuštění testu. Chceme otestovat vyhledávání primárního klíče, proto zakážeme všechny ostatní typy SELECT. Připravené výpisy také zakážeme, protože chceme testovat běžné dotazy. Budeme testovat nízkou souběžnost, řekněme 16 vláken. Náš příkaz může vypadat takto:
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 runco jsme tady dělali? Nastavili jsme počet vláken na 16. Rozhodli jsme se, že chceme, aby náš benchmark běžel 300 sekund, bez omezení prováděných dotazů. Definovali jsme konektivitu k databázi, počet tabulek a jejich velikost. Zakázali jsme také všechny SELECTy rozsahu, zakázali jsme také připravené příkazy. Nakonec nastavíme interval hlášení na jednu sekundu. Ukázkový výstup může vypadat takto:
[ 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.00Každou sekundu vidíme snímek statistik zátěže. To je docela užitečné pro sledování a vykreslování - závěrečná zpráva vám poskytne pouze průměry. Průběžné výsledky umožní sledovat výkon sekundu po sekundě. Závěrečná zpráva může vypadat takto:
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.02Najdete zde informace o provedených dotazech a dalších (BEGIN/COMMIT) příkazech. Dozvíte se, kolik transakcí bylo provedeno, kolik se stalo chyb, jaká byla propustnost a celkový uplynulý čas. Můžete také zkontrolovat metriky latence a rozložení dotazů mezi vlákny.
Pokud bychom měli zájem o distribuci latence, mohli bychom také předat argument „--histogram“ SysBench. Výsledkem je další výstup, jako je níže:
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 |****** 1Jakmile budeme mít dobré výsledky, můžeme data vyčistit:
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 cleanupZapisovaný provoz
Představme si zde, že chceme provést zátěž s vysokým obsahem zápisu (ale nikoli pouze pro zápis) a například otestovat výkon I/O subsystému. Nejprve se musíme rozhodnout, jak velký by soubor dat měl být. Budeme předpokládat ~48 GB dat (20 tabulek, každá 10 000 000 řádků). Musíme to připravit. Tentokrát použijeme benchmark čtení a zápisu.
[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 prepareJakmile to uděláme, můžeme vyladit výchozí nastavení, abychom vynutili více zápisů do mixu dotazů:
[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 runJak můžete vidět z průběžných výsledků, transakce jsou nyní na straně, která je náročná na zápis:
[ 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.00Porozumění výsledkům
Jak jsme ukázali výše, SysBench je skvělý nástroj, který může pomoci určit některé problémy s výkonem MySQL nebo MariaDB. Může být také použit pro počáteční ladění konfigurace vaší databáze. Samozřejmě musíte mít na paměti, že abyste ze svých benchmarků dostali to nejlepší, musíte pochopit, proč výsledky vypadají tak, jak vypadají. To by vyžadovalo nahlédnutí do interních metrik MySQL pomocí monitorovacích nástrojů, například ClusterControl. To je docela důležité si zapamatovat – pokud nechápete, proč byl výkon takový, jaký byl, můžete z benchmarků vyvodit nesprávné závěry. Vždy existuje úzké hrdlo a SysBench může pomoci upozornit na problémy s výkonem, které pak musíte identifikovat.