Vad är SysBench? Om du arbetar med MySQL regelbundet har du förmodligen hört talas om det. SysBench har funnits i MySQL-ekosystemet under lång tid. Den skrevs ursprungligen av Peter Zaitsev, redan 2004. Syftet var att tillhandahålla ett verktyg för att köra syntetiska benchmarks för MySQL och hårdvaran den körs på. Den designades för att köra CPU, minne och I/O-tester. Den hade också en möjlighet att köra OLTP-arbetsbelastning på en MySQL-databas. OLTP står för onlinetransaktionsbehandling, typisk arbetsbelastning för onlineapplikationer som e-handel, orderinmatning eller finansiella transaktionssystem.
I det här blogginlägget kommer vi att fokusera på SQL benchmark-funktionen men kom ihåg att hårdvaruriktmärken också kan vara mycket användbara för att identifiera problem på databasservrar. Till exempel var I/O-benchmark avsett att simulera InnoDB I/O-arbetsbelastning medan CPU-tester involverar simulering av mycket samtidiga, multitraded miljö tillsammans med tester för mutex-konflikter - något som också liknar en databastyp av arbetsbelastning.
SysBench Historia och arkitektur
Som nämnts skapades SysBench ursprungligen 2004 av Peter Zaitsev. Strax efter tog Alexey Kopytov över dess utveckling. Den nådde version 0.4.12 och utvecklingen stannade. Efter ett långt uppehåll började Alexey arbeta på SysBench igen 2016. Snart har version 0.5 släppts med OLTP benchmark omskrivet för att använda LUA-baserade skript. Sedan, 2017, släpptes SysBench 1.0. Detta var som dag och natt jämfört med den gamla versionen 0.4.12. Först och främst, istället för hårdkodade skript, har vi nu möjligheten att anpassa benchmarks med LUA. Till exempel skapade Percona TPCC-liknande benchmark som kan köras med SysBench. Låt oss ta en snabb titt på den nuvarande SysBench-arkitekturen.
SysBench är en C-binär som använder LUA-skript för att exekvera benchmarks. Dessa skript måste:
- Hantera indata från kommandoradsparametrar
- Definiera alla lägen som riktmärket ska använda (förbereda, köra, städa)
- Förbered all data
- Definiera hur riktmärket ska köras (hur frågor kommer att se ut osv.)
Skript kan använda flera anslutningar till databasen, de kan också bearbeta resultat om du vill skapa komplexa riktmärken där frågor beror på resultatuppsättningen av tidigare frågor. Med SysBench 1.0 är det möjligt att skapa latenshistogram. Det är också möjligt för LUA-skripten att fånga upp och hantera fel genom felkrokar. Det finns stöd för parallellisering i LUA-skripten, flera frågor kan köras parallellt, vilket gör till exempel provisioneringen mycket snabbare. Sist men inte minst stöds nu flera utdataformat. Innan SysBench genererade endast läsbar utdata. Nu är det möjligt att generera det som CSV eller JSON, vilket gör det mycket lättare att göra efterbearbetning och generera grafer med till exempel gnuplot eller mata in data till Prometheus, Graphite eller liknande datalager.
Varför SysBench?
Den främsta anledningen till att SysBench blev populär är det faktum att den är enkel att använda. Någon utan förkunskaper kan börja använda den inom några minuter. Den tillhandahåller också, som standard, riktmärken som täcker de flesta fall - OLTP-arbetsbelastningar, skrivskyddad eller läs-skriv, uppslagningar av primärnyckel och uppdateringar av primärnyckel. Allt som orsakade de flesta problem för MySQL, upp till MySQL 8.0. Detta var också en anledning till att SysBench var så populärt i olika benchmarks och jämförelser publicerade på Internet. Dessa inlägg hjälpte till att marknadsföra det här verktyget och gjorde det till det syntetiska riktmärket för MySQL.
En annan bra sak med SysBench är att, sedan version 0.5 och införlivandet av LUA, kan vem som helst förbereda vilken typ av benchmark som helst. Vi har redan nämnt TPCC-liknande benchmark men vem som helst kan skapa något som liknar hennes produktionsbelastning. Vi säger inte att det är enkelt, det kommer troligen att vara en tidskrävande process, men att ha denna förmåga är fördelaktigt om du behöver förbereda ett anpassat riktmärke.
Eftersom SysBench är ett syntetiskt riktmärke, är inte SysBench ett verktyg som du kan använda för att finjustera konfigurationer av dina MySQL-servrar (såvida du inte förberett LUA-skript med anpassad arbetsbelastning eller din arbetsbelastning råkar vara mycket lik de riktmärkesarbetsbelastningar som SysBench kommer med). Vad det är bra för är att jämföra prestanda för olika hårdvaror. Du kan enkelt jämföra prestanda för, låt oss säga, olika typer av noder som erbjuds av din molnleverantör och maximala QPS (queries per second) de erbjuder. Genom att veta det måttet och veta vad du betalar för en given nod kan du sedan beräkna ännu viktigare mätvärde - QP$ (queries per dollar). Detta gör att du kan identifiera vilken nodtyp du ska använda när du bygger en kostnadseffektiv miljö. Naturligtvis kan SysBench också användas för initial justering och bedömning av genomförbarheten av en given design. Låt oss säga att vi bygger ett Galera-kluster som spänner över hela världen - Nordamerika, EU, Asien. Hur många skär per sekund klarar en sådan installation? Vad skulle fördröjningen vara? Är det ens vettigt att göra ett proof of concept eller kanske nätverkslatensen är tillräckligt hög för att inte ens en enkel arbetsbelastning fungerar som du förväntar dig.
Hur är det med stresstester? Alla har inte flyttat till molnet, det finns fortfarande företag som föredrar att bygga sin egen infrastruktur. Varje ny server som skaffas bör gå igenom en uppvärmningsperiod under vilken du kommer att betona den för att lokalisera potentiella hårdvarufel. I det här fallet kan SysBench också hjälpa till. Antingen genom att köra OLTP-arbetsbelastning som överbelastas servern, eller så kan du också använda dedikerade riktmärken för CPU, disk och minne.
Som du kan se finns det många fall där även ett enkelt, syntetiskt riktmärke kan vara mycket användbart. I nästa stycke ska vi titta på vad vi kan göra med SysBench.
Vad kan SysBench göra för dig?
Vilka tester kan du köra?
Som nämnts i början kommer vi att fokusera på OLTP-riktmärken och bara som en påminnelse kommer vi att upprepa att SysBench även kan användas för att utföra I/O, CPU och minnestester. Låt oss ta en titt på riktmärkena som SysBench 1.0 kommer med (vi tog bort några LUA-hjälpfiler och LUA-skript som inte är databaser från den här listan).
-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.luaLåt oss gå igenom dem en efter en.
Först, bulk_insert.lua. Detta test kan användas för att jämföra förmågan hos MySQL att utföra flerradsinfogningar. Detta kan vara mycket användbart när du kontrollerar till exempel replikeringsprestanda eller Galera-kluster. I det första fallet kan det hjälpa dig att svara på en fråga:"hur snabbt kan jag infoga innan replikeringsfördröjningen börjar?". I det senare fallet kommer det att berätta hur snabbt data kan infogas i ett Galera-kluster givet den aktuella nätverkslatensen.
Alla oltp_*-skript delar en gemensam tabellstruktur. De två första av dem (oltp_delete.lua och oltp_insert.lua) exekverar enstaka DELETE- och INSERT-satser. Återigen, detta kan vara ett test för antingen replikering eller Galera-kluster - pressa det till gränserna och se hur mycket insättning eller rensning det kan hantera. Vi har också andra riktmärken fokuserade på speciell funktionalitet - oltp_point_select, oltp_update_index och oltp_update_non_index. Dessa kommer att exekvera en undergrupp av frågor - primärnyckelbaserade urval, indexbaserade uppdateringar och icke-indexbaserade uppdateringar. Om du vill testa några av dessa funktioner finns testerna där. Vi har också mer komplexa benchmarks som är baserade på OLTP-arbetsbelastningar:oltp_read_only, oltp_read_write och oltp_write_only. Du kan köra antingen en skrivskyddad arbetsbelastning, som kommer att bestå av olika typer av SELECT-frågor, du kan bara köra skrivningar (en blandning av DELETE, INSERT och UPDATE) eller så kan du köra en blandning av dessa två. Slutligen, med select_random_points och select_random_ranges kan du köra några slumpmässiga SELECT antingen med slumpmässiga punkter i IN()-listan eller slumpmässiga intervall med BETWEEN.
Hur kan du konfigurera ett benchmark?
Vad som också är viktigt, benchmarks är konfigurerbara - du kan köra olika arbetsbelastningsmönster med samma benchmark. Låt oss ta en titt på de två vanligaste riktmärkena att utföra. Vi kommer att göra en djupdykning i OLTP read_only och OLTP read_write benchmarks. Först och främst har SysBench några allmänna konfigurationsalternativ. Vi kommer att diskutera här endast de viktigaste, du kan kontrollera dem alla genom att köra:
sysbench --helpLåt oss ta en titt på dem.
--threads=N number of threads to use [1]Du kan definiera vilken typ av samtidighet du vill att SysBench ska generera. MySQL, som alla program, har vissa skalbarhetsbegränsningar och dess prestanda kommer att toppa på en viss nivå av samtidighet. Den här inställningen hjälper till att simulera olika samtidigheter för en given arbetsbelastning och kontrollera om den redan har passerat sweet spot.
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]Dessa två inställningar styr hur länge SysBench ska fortsätta köra. Den kan antingen köra ett visst antal frågor eller så kan den fortsätta att köras under en fördefinierad tid.
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]Detta är självförklarande. SysBench genererar statistiska resultat från testerna och dessa resultat kan påverkas om MySQL är i ett kallt tillstånd. Warmup hjälper till att identifiera "vanlig" genomströmning genom att köra benchmark under en fördefinierad tid, vilket gör det möjligt att värma upp cachen, buffertpooler etc.
--rate=N average transactions rate. 0 for unlimited rate [0]Som standard kommer SysBench att försöka utföra frågor så snabbt som möjligt. För att simulera långsammare trafik kan detta alternativ användas. Du kan här definiera hur många transaktioner som ska utföras per sekund.
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]Som standard genererar SysBench en rapport efter att den slutfört sin körning och inga framsteg rapporteras medan benchmark körs. Med det här alternativet kan du göra SysBench mer omfattande medan riktmärket fortfarande körs.
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBench ger dig möjlighet att generera olika typer av datadistribution. Alla kan ha sina egna syften. Standardalternativet, "speciell", definierar flera (det är konfigurerbart) hot-spots i data, något som är ganska vanligt i webbapplikationer. Du kan också använda andra distributioner om din data beter sig på ett annat sätt. Genom att göra ett annat val här kan du också ändra hur din databas är stressad. Till exempel är enhetlig distribution, där alla rader har samma sannolikhet att nås, mycket mer minneskrävande drift. Det kommer att använda mer buffertpool för att lagra all data och det kommer att bli mycket mer diskintensivt om din datauppsättning inte får plats i minnet. Å andra sidan kommer specialdistribution med ett par hot-spots att lägga mindre stress på disken eftersom heta rader är mer benägna att hållas i buffertpoolen och tillgång till rader lagrade på disken är mycket mindre sannolikt. För några av datadistributionstyperna ger SysBench dig fler tweaks. Du kan hitta denna information i 'sysbench --help'-utgången.
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]Med den här inställningen kan du bestämma om SysBench ska använda förberedda uttalanden (så länge de är tillgängliga i den givna datalagringen - för MySQL betyder det att PS kommer att vara aktiverat som standard) eller inte. Detta kan göra skillnad när du arbetar med proxyservrar som ProxySQL eller MaxScale - de bör behandla förberedda uttalanden på ett speciellt sätt och alla bör dirigeras till en värd vilket gör det omöjligt att testa skalbarheten för proxyn.
Utöver de allmänna konfigurationsalternativen kan var och en av testerna ha sin egen konfiguration. Du kan kontrollera vad som är möjligt genom att köra:
[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]Återigen kommer vi att diskutera de viktigaste alternativen härifrån. Först och främst har du kontroll över hur exakt en transaktion kommer att se ut. Generellt sett består den av olika typer av frågor - INSERT, DELETE, olika typer av SELECT (punktsökning, intervall, aggregering) och UPDATE (indexerad, icke-indexerad). Använda variabler som:
--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]Du kan definiera hur en transaktion ska se ut. Som du kan se genom att titta på standardvärdena är majoriteten av frågorna SELECTs - främst punktval men också olika typer av intervall SELECT:er (du kan inaktivera dem alla genom att sätta range_selects till av). Du kan justera arbetsbelastningen mot mer skrivtung arbetsbelastning genom att öka antalet uppdateringar eller INSERT/DELETE-frågor. Det är också möjligt att justera inställningar relaterade till sekundära index, automatisk inkrement men även datauppsättningsstorlek (antal tabeller och hur många rader var och en av dem ska innehålla). Detta låter dig anpassa din arbetsbelastning ganska snyggt.
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]Detta är en annan inställning, ganska viktig när man arbetar med proxyservrar. Som standard kommer SysBench att försöka utföra frågor i explicit transaktion. På så sätt kommer datasetet att förbli konsekvent och inte påverkas:SysBench kommer till exempel att köra INSERT och DELETE på samma rad, vilket säkerställer att datamängden inte växer (som påverkar din förmåga att reproducera resultat). Emellertid kommer proxyer att behandla explicita transaktioner på olika sätt - alla frågor som körs inom en transaktion bör köras på samma värd, vilket tar bort möjligheten att skala arbetsbelastningen. Tänk på att inaktivering av transaktioner kommer att resultera i att datamängden avviker från den ursprungliga punkten. Det kan också utlösa vissa problem som dubbletter av nyckelfel eller liknande. För att kunna inaktivera transaktioner kanske du också vill titta på:
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]Den här inställningen låter dig ange felkoder från MySQL som SysBench ska ignorera (och inte avbryta anslutningen). Till exempel, för att ignorera fel som:fel 1062 (duplicera post '6' för nyckel 'PRIMÄR') bör du skicka denna felkod:--mysql-ignore-errors=1062
Vad som också är viktigt, varje benchmark bör presentera ett sätt att tillhandahålla en datamängd för tester, köra dem och sedan rensa upp den efter att testerna är klara. Detta görs med kommandon "förbered", "kör" och "städa". Vi kommer att visa hur detta går till i nästa avsnitt.
Exempel
I det här avsnittet går vi igenom några exempel på vad SysBench kan användas till. Som nämnts tidigare kommer vi att fokusera på de två mest populära riktmärkena - OLTP skrivskyddad och OLTP läs/skriv. Ibland kan det vara vettigt att använda andra riktmärken, men vi kommer åtminstone att kunna visa dig hur dessa två kan anpassas.
Primära nyckeluppslag
Först och främst måste vi bestämma vilken benchmark vi ska köra, skrivskyddad eller läs-skriv. Tekniskt sett gör det ingen skillnad eftersom vi kan ta bort skrivningar från R/W benchmark. Låt oss fokusera på den skrivskyddade.
Som ett första steg måste vi förbereda en datamängd. Vi måste bestämma hur stor den ska vara. För just detta riktmärke, med standardinställningar (så att sekundära index skapas), kommer 1 miljon rader att resultera i ~240 MB data. Tio tabeller, vardera 1 000 000 rader motsvarar 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.ibdDetta bör ge dig en uppfattning om hur många bord du vill ha och hur stora de ska vara. Låt oss säga att vi vill testa arbetsbelastningen i minnet så vi vill skapa tabeller som passar in i InnoDB-buffertpoolen. Å andra sidan vill vi också se till att det finns tillräckligt med bord för att inte bli en flaskhals (eller att antalet bord matchar vad du kan förvänta dig i din produktionsuppsättning). Låt oss förbereda vår datauppsättning. Tänk på att SysBench som standard letar efter "sbtest"-schemat som måste finnas innan du förbereder datamängden. Du kanske måste skapa den manuellt.
[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'...När vi har vår data, låt oss förbereda ett kommando för att köra testet. Vi vill testa primärnyckelsökningar, därför kommer vi att inaktivera alla andra typer av SELECT. Vi kommer också att inaktivera förberedda uttalanden eftersom vi vill testa vanliga frågor. Vi kommer att testa låg samtidighet, låt oss säga 16 trådar. Vårt kommando kan se ut så här:
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 runVad gjorde vi här? Vi satte antalet trådar till 16. Vi bestämde att vi vill att vårt benchmark ska köras i 300 sekunder, utan en begränsning av körda frågor. Vi definierade anslutning till databasen, antal tabeller och deras storlek. Vi inaktiverade också alla intervall SELECT, vi inaktiverade också förberedda uttalanden. Slutligen sätter vi rapportintervallet till en sekund. Så här kan en provutgång se ut:
[ 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.00Varje sekund ser vi en ögonblicksbild av arbetsbelastningsstatistik. Detta är ganska användbart att spåra och plotta - slutrapporten ger dig endast medelvärden. Mellanliggande resultat kommer att göra det möjligt att spåra prestandan sekund för sekund. Slutrapporten kan se ut så här:
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.02Du hittar här information om utförda frågor och andra (BEGIN/COMMIT) uttalanden. Du får reda på hur många transaktioner som utfördes, hur många fel som hände, vad var genomströmningen och totalt förfluten tid. Du kan också kontrollera latensstatistik och frågefördelningen över trådar.
Om vi var intresserade av latensfördelning skulle vi också kunna skicka "--histogram"-argumentet till SysBench. Detta resulterar i en ytterligare utdata som nedan:
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 |****** 1När vi är bra med våra resultat kan vi rensa upp data:
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 cleanupSkriv mycket trafik
Låt oss här föreställa oss att vi vill utföra en skrivtung (men inte skrivbar) arbetsbelastning och till exempel testa I/O-undersystemets prestanda. Först och främst måste vi bestämma hur stor datamängden ska vara. Vi antar ~48 GB data (20 tabeller, 10 000 000 rader vardera). Vi måste förbereda det. Den här gången kommer vi att använda läs-skriv-riktmärket.
[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 prepareNär detta är gjort kan vi justera standardinställningarna för att tvinga fram fler skrivningar i frågemixen:
[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 runSom du kan se från de mellanliggande resultaten är transaktioner nu på en skrivtung sida:
[ 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.00Förstå resultaten
Som vi visade ovan är SysBench ett bra verktyg som kan hjälpa till att lokalisera några av prestandaproblemen i MySQL eller MariaDB. Den kan också användas för initial justering av din databaskonfiguration. Naturligtvis måste du komma ihåg att, för att få ut det bästa av dina riktmärken, måste du förstå varför resultaten ser ut som de gör. Detta skulle kräva insikter i MySQL interna mätvärden med hjälp av övervakningsverktyg, till exempel ClusterControl. Detta är ganska viktigt att komma ihåg - om du inte förstår varför prestandan var som den var kan du dra felaktiga slutsatser från riktmärkena. Det finns alltid en flaskhals och SysBench kan hjälpa till att ta upp prestandaproblemen, som du sedan måste identifiera.