Sådan benchmarker du MySQL &MariaDB's ydeevne ved hjælp af SysBench

Hvad er SysBench? Hvis du arbejder med MySQL regelmæssigt, så har du sandsynligvis hørt om det. SysBench har været i MySQL-økosystemet i lang tid. Den blev oprindeligt skrevet af Peter Zaitsev tilbage i 2004. Dens formål var at levere et værktøj til at køre syntetiske benchmarks af MySQL og den hardware, den kører på. Den er designet til at køre CPU, hukommelse og I/O-tests. Det havde også en mulighed for at udføre OLTP-arbejdsbelastning på en MySQL-database. OLTP står for online transaktionsbehandling, typisk arbejdsbyrde for onlineapplikationer som e-handel, ordreindtastning eller finansielle transaktionssystemer.

I dette blogindlæg vil vi fokusere på SQL-benchmark-funktionen, men husk på, at hardware-benchmarks også kan være meget nyttige til at identificere problemer på databaseservere. F.eks. var I/O-benchmark beregnet til at simulere InnoDB I/O-arbejdsbelastning, mens CPU-test involverer simulering af meget samtidige, multi-treaded miljø sammen med tests for mutex-påstande - noget, der også ligner en databasetype af arbejdsbelastning.

SysBench historie og arkitektur

Som nævnt blev SysBench oprindeligt skabt i 2004 af Peter Zaitsev. Kort efter overtog Alexey Kopytov dens udvikling. Den nåede version 0.4.12 og udviklingen stoppede. Efter en lang pause begyndte Alexey at arbejde på SysBench igen i 2016. Snart er version 0.5 blevet frigivet med OLTP benchmark omskrevet til at bruge LUA-baserede scripts. Så, i 2017, blev SysBench 1.0 udgivet. Dette var som dag og nat sammenlignet med den gamle version 0.4.12. Først og fremmest, i stedet for hårdkodede scripts, har vi nu muligheden for at tilpasse benchmarks ved hjælp af LUA. For eksempel skabte Percona TPCC-lignende benchmark, som kan udføres ved hjælp af SysBench. Lad os tage et hurtigt kig på den nuværende SysBench-arkitektur.

SysBench er en C-binær, som bruger LUA-scripts til at udføre benchmarks. Disse scripts skal:

1. Håndter input fra kommandolinjeparametre
2. Definer alle de tilstande, som benchmark skal bruge (forbered, kør, oprydning)
3. Forbered alle data
4. Definer, hvordan benchmark skal udføres (hvordan forespørgsler vil se ud osv.)

Scripts kan bruge flere forbindelser til databasen, de kan også behandle resultater, hvis du ønsker at skabe komplekse benchmarks, hvor forespørgsler afhænger af resultatsættet af tidligere forespørgsler. Med SysBench 1.0 er det muligt at lave latenshistogrammer. Det er også muligt for LUA-scripts at fange og håndtere fejl gennem fejlkroge. Der er understøttelse af parallelisering i LUA-scripts, flere forespørgsler kan udføres parallelt, hvilket for eksempel gør klargøring meget hurtigere. Sidst, men ikke mindst, er flere outputformater nu understøttet. Før SysBench genererede kun menneskeligt læsbart output. Nu er det muligt at generere det som CSV eller JSON, hvilket gør det meget nemmere at lave efterbehandling og generere grafer ved hjælp af for eksempel gnuplot eller feed dataene ind i Prometheus, Graphite eller lignende datalager.

Hvorfor SysBench?

Hovedårsagen til, at SysBench blev populær, er det faktum, at det er nemt at bruge. En person uden forudgående viden kan begynde at bruge det inden for få minutter. Det giver også som standard benchmarks, der dækker de fleste tilfælde - OLTP-arbejdsbelastninger, skrivebeskyttet eller læse-skrive, primærnøgleopslag og primærnøgleopdateringer. Alt dette forårsagede de fleste problemer for MySQL, op til MySQL 8.0. Dette var også en grund til, at SysBench var så populær i forskellige benchmarks og sammenligninger offentliggjort på internettet. Disse indlæg hjalp med at promovere dette værktøj og gjorde det til det syntetiske benchmark for MySQL.

En anden god ting ved SysBench er, at siden version 0.5 og inkorporering af LUA, kan enhver forberede enhver form for benchmark. Vi har allerede nævnt TPCC-lignende benchmark, men enhver kan lave noget, der ligner hendes produktionsarbejdsbyrde. Vi siger ikke, at det er simpelt, det vil højst sandsynligt være en tidskrævende proces, men at have denne evne er en fordel, hvis du skal udarbejde et tilpasset benchmark.

Da SysBench er et syntetisk benchmark, er SysBench ikke et værktøj, som du kan bruge til at tune konfigurationer af dine MySQL-servere (medmindre du har forberedt LUA-scripts med tilpasset arbejdsbelastning, eller din arbejdsbyrde tilfældigvis ligner de benchmark-arbejdsbelastninger, som SysBench kommer med). Hvad det er fantastisk til, er at sammenligne ydeevnen af ​​forskellig hardware. Du kan nemt sammenligne ydeevnen af, lad os sige, forskellige typer noder, der tilbydes af din cloud-udbyder, og den maksimale QPS (forespørgsler per sekund), de tilbyder. Ved at kende denne metrik og ved, hvad du betaler for en given node, kan du derefter beregne endnu vigtigere metriske - QP$ (forespørgsler pr. dollar). Dette giver dig mulighed for at identificere, hvilken nodetype du skal bruge, når du bygger et omkostningseffektivt miljø. Selvfølgelig kan SysBench også bruges til indledende tuning og vurdering af gennemførligheden af ​​et givet design. Lad os sige, at vi bygger en Galera-klynge, der spænder over hele kloden - Nordamerika, EU, Asien. Hvor mange indstik i sekundet kan sådan en opsætning klare? Hvad ville commit-forsinkelsen være? Giver det overhovedet mening at lave et proof of concept, eller måske er netværksforsinkelsen høj nok til, at selv en simpel arbejdsbyrde ikke fungerer, som du ville forvente.

Hvad med stresstest? Ikke alle er flyttet til skyen, der er stadig virksomheder, der foretrækker at bygge deres egen infrastruktur. Hver ny server, der anskaffes, skal gennemgå en opvarmningsperiode, hvor du vil understrege den for at lokalisere potentielle hardwarefejl. I dette tilfælde kan SysBench også hjælpe. Enten ved at udføre OLTP-arbejdsbelastning, som overbelaster serveren, eller du kan også bruge dedikerede benchmarks for CPU, disk og hukommelse.

Som du kan se, er der mange tilfælde, hvor selv et simpelt, syntetisk benchmark kan være meget nyttigt. I det næste afsnit vil vi se på, hvad vi kan gøre med SysBench.

Hvad kan SysBench gøre for dig?

Hvilke tests kan du køre?

Som nævnt i begyndelsen vil vi fokusere på OLTP-benchmarks, og som en påmindelse gentager vi, at SysBench også kan bruges til at udføre I/O, CPU og hukommelsestest. Lad os tage et kig på de benchmarks, som SysBench 1.0 kommer med (vi fjernede nogle hjælpe-LUA-filer og ikke-database-LUA-scripts fra denne liste).

-rwxr-xr-x 1 rodrod 1.5K 30. maj 07:46 bulk_insert.lua-rwxr-xr-x 1 rodrod 1.3K 30. maj 07:46 oltp_delete.lua-rwxr-xr-x 1 rodrod 2.4K 30. maj 07:46 oltp_insert.lua-rwxr-xr-x 1 rodrod 1.3K 30. maj 07:46 oltp_point_select.lua-rwxr-xr-x 1 rodrod 1.7K 30. maj 07:_read lua-rwxr-xr-x 1 rodrod 1.8K 30. maj 07:46 oltp_read_write.lua-rwxr-xr-x 1 rodrod 1.1K 30. maj 07:46 oltp_update_index.lua-rwxr-rootxr-x 1.1K 30. maj 07:46 oltp_update_non_index.lua-rwxr-xr-x 1 rodrod 1.5K 30. maj 07:46 oltp_write_only.lua-rwxr-xr-x 1 rodrod 1,9K 30. maj 07:46 select.rxrx.rxr. -x 1 root root 2.1K 30. maj 07:46 select_random_ranges.lua 

Lad os gennemgå dem én efter én.

Først bulk_insert.lua. Denne test kan bruges til at benchmarke MySQL's evne til at udføre multi-row inserts. Dette kan være ret nyttigt, når du for eksempel kontrollerer replikeringsydelsen eller Galera-klyngen. I det første tilfælde kan det hjælpe dig med at besvare et spørgsmål:"hvor hurtigt kan jeg indsætte, før replikationsforsinkelsen starter?". I det senere tilfælde vil den fortælle dig, hvor hurtigt data kan indsættes i en Galera-klynge givet den aktuelle netværksforsinkelse.

Alle oltp_* scripts deler en fælles tabelstruktur. De første to af dem (oltp_delete.lua og oltp_insert.lua) udfører enkelte DELETE- og INSERT-sætninger. Igen, dette kunne være en test for enten replikering eller Galera-klynge - skub det til grænserne og se, hvor meget indsættelse eller udrensning den kan klare. Vi har også andre benchmarks med fokus på særlig funktionalitet - oltp_point_select, oltp_update_index og oltp_update_non_index. Disse vil udføre en undergruppe af forespørgsler - primære nøglebaserede valg, indeksbaserede opdateringer og ikke-indeksbaserede opdateringer. Hvis du vil teste nogle af disse funktioner, er testene der. Vi har også mere komplekse benchmarks, som er baseret på OLTP-arbejdsbelastninger:oltp_read_only, oltp_read_write og oltp_write_only. Du kan køre enten en skrivebeskyttet arbejdsbelastning, som vil bestå af forskellige typer SELECT-forespørgsler, du kan kun køre skrivninger (en blanding af DELETE, INSERT og UPDATE), eller du kan køre en blanding af disse to. Endelig kan du ved at bruge select_random_points og select_random_ranges køre nogle tilfældige SELECT enten ved at bruge tilfældige punkter i IN() listen eller tilfældige områder ved at bruge BETWEEN.

Hvordan kan du konfigurere et benchmark?

Hvad der også er vigtigt, benchmarks er konfigurerbare - du kan køre forskellige arbejdsbelastningsmønstre ved at bruge det samme benchmark. Lad os tage et kig på de to mest almindelige benchmarks at udføre. Vi vil have et dybt dyk ned i OLTP read_only og OLTP read_write benchmarks. Først og fremmest har SysBench nogle generelle konfigurationsmuligheder. Vi vil her kun diskutere de vigtigste, du kan tjekke dem alle ved at køre:

sysbench --help 

Lad os tage et kig på dem.

 --threads=N antal tråde, der skal bruges [1] 

Du kan definere, hvilken slags samtidighed du gerne vil have, at SysBench skal generere. MySQL, som enhver software, har nogle skalerbarhedsbegrænsninger, og dens ydeevne vil toppe på et vist niveau af samtidighed. Denne indstilling hjælper med at simulere forskellige samtidigheder for en given arbejdsbyrde og kontrollere, om den allerede har passeret sweet spot.

 --events=N grænse for det samlede antal hændelser [0] --time=N grænse for den samlede udførelsestid i sekunder [10] 

Disse to indstillinger styrer, hvor længe SysBench skal fortsætte med at køre. Den kan enten udføre et antal forespørgsler, eller den kan blive ved med at køre i et foruddefineret tidsrum.

 --warmup-time=N udfør begivenheder i så mange sekunder med statistik deaktiveret før den faktiske benchmarkkørsel med statistik aktiveret [0] 

Dette er selvforklarende. SysBench genererer statistiske resultater fra testene, og disse resultater kan blive påvirket, hvis MySQL er i en kold tilstand. Warmup hjælper med at identificere "regelmæssig" gennemløb ved at udføre benchmark i en foruddefineret tid, hvilket gør det muligt at varme cachen, bufferpuljer osv. op.

 --rate=N gennemsnitlig transaktionsrate. 0 for ubegrænset pris [0] 

Som standard vil SysBench forsøge at udføre forespørgsler så hurtigt som muligt. For at simulere langsommere trafik kan denne mulighed bruges. Du kan her definere, hvor mange transaktioner der skal udføres pr. sekund.

 --report-interval=N rapporterer periodisk mellemstatistik med et specificeret interval i sekunder. 0 deaktiverer mellemliggende rapporter [0] 

Som standard genererer SysBench en rapport, efter at den har afsluttet sin kørsel, og der rapporteres ingen fremskridt, mens benchmark kører. Ved at bruge denne mulighed kan du gøre SysBench mere omfattende, mens benchmark stadig kører.

 --rand-type=STRING fordeling af tilfældige tal {uniform, gaussian, special, pareto, zipfian} til brug som standard [special] 

SysBench giver dig mulighed for at generere forskellige typer datadistribution. Alle kan have deres egne formål. Standardindstillingen, 'special', definerer flere (det kan konfigureres) hot-spots i dataene, noget som er ret almindeligt i webapplikationer. Du kan også bruge andre distributioner, hvis dine data opfører sig på en anden måde. Ved at træffe et andet valg her kan du også ændre den måde, din database er stresset på. For eksempel er ensartet fordeling, hvor alle rækkerne har samme sandsynlighed for at blive tilgået, meget mere hukommelsesintensiv drift. Det vil bruge mere bufferpulje til at gemme alle data, og det vil være meget mere diskkrævende, hvis dit datasæt ikke passer i hukommelsen. På den anden side vil speciel distribution med et par hot-spots lægge mindre stress på disken, da hot rows er mere tilbøjelige til at blive holdt i bufferpuljen, og adgang til rækker gemt på disken er meget mindre sandsynligt. For nogle af datadistributionstyperne giver SysBench dig flere tweaks. Du kan finde disse oplysninger i 'sysbench --help' output.

 --db-ps-mode=STRING forberedte sætninger brugstilstand {auto, deaktiver} [auto] 

Ved at bruge denne indstilling kan du bestemme, om SysBench skal bruge forberedte sætninger (så længe de er tilgængelige i det givne datalager - for MySQL betyder det, at PS vil være aktiveret som standard) eller ej. Dette kan gøre en forskel, mens du arbejder med proxyer som ProxySQL eller MaxScale - de skal behandle forberedte udsagn på en speciel måde, og dem alle skal dirigeres til én vært, hvilket gør det umuligt at teste skalerbarheden af ​​proxyen.

Ud over de generelle konfigurationsmuligheder kan hver af testene have sin egen konfiguration. Du kan tjekke, hvad der er muligt ved at køre:

[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua helpsysbench 1.1.0-2e6b7d5 (bruger bundtet LuaJIT 2.1.0-beta3)oltp_read_ranges_only. =N Antal SELECT DISTINCT-forespørgsler pr. transaktion [1] --sum_ranges=N Antal SELECT SUM()-forespørgsler pr. transaktion [1] --skip_trx[=on|off] Start ikke eksplicitte transaktioner, og udfør alle forespørgsler i AUTOCOMMIT-tilstand [fra] --sekundær[=til|fra] Brug et sekundært indeks i stedet for den PRIMÆR-KEY [fra] --create_secondary[=on|off] Opret et sekundært indeks ud over den PRIMÆR-KEY [on] - -index_updates=N Antal UPDATE-indeksforespørgsler pr. transaktion [1] --range_size=N Områdestørrelse for område SELECT-forespørgsler [100] --auto_inc[=on|off] Brug AUTO_INCREMENT-kolonnen som primærnøgle (for MySQL), eller dens alternativer i andre DBMS. Når de er deaktiveret, skal du bruge klientgenererede id'er [på] --delete_inserts=N Antal DELETE/INSERT-kombinationer pr. transaktion [1] --tables=N Antal tabeller [1] --mysql_storage_engine=STRING Storagemotor, hvis MySQL bruges [innodb] --non_index_updates=N Antal UPDATE ikke-indeksforespørgsler pr. transaktion [1] --table_size=N Antal rækker pr. tabel [10000] --pgsql_variant=STRING Brug denne PostgreSQL-variant, når du kører med PostgreSQL-driveren. Den eneste i øjeblikket understøttede variant er 'rødforskydning'. Når det er aktiveret, deaktiveres create_secondary automatisk, og delete_inserts er indstillet til 0 --simple_ranges=N Antal simple range SELECT-forespørgsler pr. transaktion [1] --order_ranges=N Antal SELECT ORDER BY-forespørgsler pr. transaktion [1] --range_selects[ =on|off] Aktiver/deaktiver alle område SELECT-forespørgsler [on] --point_selects=N Antal punkt-SELECT-forespørgsler pr. transaktion [10] 

Igen vil vi diskutere de vigtigste muligheder herfra. Først og fremmest har du styr på, hvordan en transaktion præcis kommer til at se ud. Generelt set består det af forskellige typer forespørgsler - INSERT, DELETE, forskellig type SELECT (punktopslag, rækkevidde, aggregering) og OPDATERING (indekseret, ikke-indekseret). Brug af variabler som:

 --distinct_ranges=N Antal SELECT DISTINCT-forespørgsler pr. transaktion [1] --sum_ranges=N Antal SELECT SUM()-forespørgsler pr. transaktion [1] --index_updates=N Antal UPDATE-indeksforespørgsler pr. transaktion [1] --delete_inserts=N Antal DELETE/INSERT-kombinationer pr. transaktion [1] --non_index_updates=N Antal UPDATE ikke-indeks-forespørgsler pr. transaktion [1] --simple_ranges=N Antal simple SELECT-forespørgsler pr. transaktion [ 1] --order_ranges=N Antal SELECT ORDER BY-forespørgsler pr. transaktion [1] --point_selects=N Antal punkt SELECT-forespørgsler pr. transaktion [10] --range_selects[=on|off] Aktiver/deaktiver alle range SELECT-forespørgsler [ på] 

Du kan definere, hvordan en transaktion skal se ud. Som du kan se ved at se på standardværdierne, er størstedelen af ​​forespørgsler SELECT'er - hovedsageligt punktvalg, men også forskellige typer område SELECT'er (du kan deaktivere dem alle ved at slå range_selects til fra). Du kan justere arbejdsbyrden mod mere skrivetung arbejdsbyrde ved at øge antallet af opdateringer eller INSERT/DELETE-forespørgsler. Det er også muligt at justere indstillinger relateret til sekundære indekser, automatisk stigning men også datasætstørrelse (antal tabeller og hvor mange rækker hver af dem skal indeholde). Dette lader dig tilpasse din arbejdsbyrde ganske pænt.

 --skip_trx[=on|off] Start ikke eksplicitte transaktioner og udfør alle forespørgsler i AUTOCOMMIT-tilstanden [fra] 

Dette er en anden indstilling, ret vigtig, når du arbejder med proxyer. Som standard vil SysBench forsøge at udføre forespørgsler i eksplicit transaktion. På denne måde vil datasættet forblive konsistent og ikke påvirket:SysBench vil f.eks. udføre INSERT og DELETE på samme række, hvilket sikrer, at datasættet ikke vokser (påvirker din evne til at reproducere resultater). Proxyer vil dog behandle eksplicitte transaktioner forskelligt - alle forespørgsler, der udføres inden for en transaktion, skal udføres på den samme vært, hvilket fjerner muligheden for at skalere arbejdsbyrden. Vær opmærksom på, at deaktivering af transaktioner vil resultere i, at datasættet afviger fra det oprindelige punkt. Det kan også udløse nogle problemer som duplikatnøglefejl eller lignende. For at kunne deaktivere transaktioner vil du måske også se nærmere på:

 --mysql-ignore-errors=[LIST,...] liste over fejl, der skal ignoreres, eller "alle" [1213,1020,1205] 

Denne indstilling giver dig mulighed for at angive fejlkoder fra MySQL, som SysBench skal ignorere (og ikke afbryde forbindelsen). For at ignorere fejl som f.eks.:fejl 1062 (Duplikatindtastning '6' for nøglen 'PRIMARY'), skal du videregive denne fejlkode:--mysql-ignore-errors=1062

Hvad der også er vigtigt, bør hvert benchmark præsentere en måde at klargøre et datasæt til test, køre dem og derefter rydde op i, efter at testene er afsluttet. Dette gøres ved at bruge kommandoerne 'forbered', 'kør' og 'oprydning'. Vi vil vise, hvordan dette gøres i næste afsnit.

Eksempler

I dette afsnit gennemgår vi nogle eksempler på, hvad SysBench kan bruges til. Som tidligere nævnt vil vi fokusere på de to mest populære benchmarks - OLTP read only og OLTP read/write. Nogle gange kan det give mening at bruge andre benchmarks, men i det mindste vil vi være i stand til at vise dig, hvordan de to kan tilpasses.

Primære nøgleopslag

Først og fremmest skal vi beslutte, hvilket benchmark vi vil køre, skrivebeskyttet eller læse-skrive. Teknisk set gør det ingen forskel, da vi kan fjerne skrivninger fra R/W benchmark. Lad os fokusere på den skrivebeskyttede.

Som et første skridt skal vi udarbejde et datasæt. Vi skal beslutte, hvor stor den skal være. For dette særlige benchmark vil 1 million rækker resultere i ~240 MB data. Ti tabeller, 1000 000 rækker hver svarer til 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.4Gdrwxr-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 1 jun 12:12 sbtest10.frm-rw-r----- 1 mysql mysql 240M 1 12:12 sbtest10.ibd-rw-r----- 1 mysql mysql 8.5K 1. jun 12:10 sbtest1.frm-rw-r----- 1 mysql mysql 240M 1. jun. 12:10 sb -rw-r----- 1 mysql mysql 8.5K 1. juni 12:10 sbtest2.frm-rw-r----- 1 mysql mysql 240M 1. jun. 12:10 sbtest2.ibd-rw-r--- -- 1 mysql mysql 8.5K 1. juni 12:10 sbtest3.frm-rw-r----- 1 mysql mysql 240M 1. juni 12:10 sbtest3.ibd-rw-r----- 1 mysql mysql 8.5K 1 jun 12:10 sbtest4.frm-rw-r----- 1 mysql mysql 240M 1 jun 12:10 sbtest4.ibd-rw-r----- 1 mysql mysql 8.5K 1 jun 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 1. jun. 12:11 sbtest6.ibd-rw-r----- 1 mysql mysql 8.5K 1. jun. 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 140M:11 sbtest8.ibd-rw-r----- 1 mysql mysql 8.5K 1. jun 12:12 sbtest9.frm-rw-r----- 1 mysql mysql 240M 1. jun. 12:12 sbtest9.ibd 

Dette skulle give dig en idé om, hvor mange borde du ønsker, og hvor store de skal være. Lad os sige, at vi vil teste arbejdsbelastningen i hukommelsen, så vi vil oprette tabeller, der passer ind i InnoDB-bufferpuljen. På den anden side vil vi også sikre os, at der er nok borde til ikke at blive en flaskehals (eller at mængden af ​​borde matcher, hvad du ville forvente i dit produktionssetup). Lad os forberede vores datasæt. Vær opmærksom på, at SysBench som standard leder efter 'sbtest'-skema, som skal eksistere, før du forbereder datasættet. Du skal muligvis oprette den manuelt.

[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 preparesysbench 1.1.0-2e6b7d5 (ved hjælp af bundtet LuaJIT 2.1.0-beta3) Initialiserer arbejdertråde...Opretter tabel 'sbtest2 '...Opretter tabel 'sbtest3'...Opretter tabel 'sbtest4'...Opretter tabel 'sbtest1'...Indsætter 1000000 poster i 'sbtest2'Indsætter 1000000 poster i 'sbtest4'Indsætter 1000000 poster i 'sbtest3'I 'sbtest3' 1000000 poster i 'sbtest1'Oprettelse af et sekundært indeks på 'sbtest2'...Oprettelse af et sekundært indeks på 'sbtest3'...Oprettelse af et sekundært indeks på 'sbtest1'...Oprettelse af et sekundært indeks på 'sbtest4'... Opretter tabel 'sbtest6'...Indsætter 1000000 poster i 'sbtest6'Opretter tabel 'sbtest7'...Indsætter 1000000 poster i 'sbtest7'Opretter tabel 'sbtest5'...Indsætter 1000000 poster i 'sbtestsb8'Creater tabel 'sbtest6' ...Indsættelse af 1000000 poster int o 'sbtest8'Oprettelse af et sekundært indeks på 'sbtest6'...Oprettelse af et sekundært indeks på 'sbtest7'...Oprettelse af et sekundært indeks på 'sbtest5'...Oprettelse af et sekundært indeks på 'sbtest8'...Opretter tabel 'sbtest10'...Indsætter 1000000 poster i 'sbtest10'Opretter tabel 'sbtest9'...Indsætter 1000000 poster i 'sbtest9'Opretter et sekundært indeks på 'sbtest10'...Opretter et sekundært indeks på 'sbtest9'...  

Når vi har vores data, lad os forberede en kommando til at køre testen. Vi ønsker at teste primære nøgleopslag, derfor vil vi deaktivere alle andre typer SELECT. Vi vil også deaktivere forberedte udsagn, da vi ønsker at teste almindelige forespørgsler. Vi vil teste lav samtidighed, lad os sige 16 tråde. Vores kommando kan se ud som nedenfor:

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 kørsel 

SQL-statistik:udførte forespørgsler:læst:614660 skriv:0 andre:122932 i alt:737592 transaktioner:61466 (204,84 pr. sek.) forespørgsler:737592 (2458,08 pr. sek.) (Ignorerede fejl:000 pr. sek. .) genopretter forbindelse:0 (0,00 pr. sek.)Gennemgang:hændelser/s (eps):204,8403 forløbne tid:300,0679 s samlet antal hændelser:61466Latency (ms):min:24,91 gns.:78,10 maks. 9:335 procent 9:335 procent. :4800234.60Tråde fairness:events (avg/stddev):3841.6250/20.87 executi til tiden (avg/stddev):300.0147/0.02 

Latenshistogram (værdier er i millisekunder) værdi ------------- fordeling --------------antal 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 oprydning 

[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 klargør 

[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 kørsel 

[ 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 recon. [ 6s ] thds:16 tps:17,01 qps:955,81 (r/w/o:223,19/698,59/34,03) lat (ms,95%):1032,01 fejl/s:0,00 reconn/s:0.00 reconn/s:6ds: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 ] 6thds:6ts:6ts:6ts:6ts:3 (r/w/o:195.12/460.29/28.02) lat (ms,95%):1533.66 fejl/s:0.00 reconn/s:0.00