I denne artikel skal vi diskutere sysbench, den faktiske standard for MySQL benchmarking. Vi vil tage et kig på det grundlæggende i sysbench-brug, og hvordan kan vi bruge sysbench til at lære om MySQL, og det andet er det vigtigste aspekt for os. Vi vil praktisk talt bruge sysbench som et værktøj til at generere trafik, som vi ved meget om, fordi sysbench vil holde nogle oplysninger om den genererede trafik hvert sekund.
SysBench MySQL Test
Sysbench er et multi-threaded benchmark-værktøj baseret på luaJIT, det er den faktiske standard for MySQL-benchmarks, det skal kunne oprette forbindelse til databasen.
Sysbench-installation
Først skal vi installere sysbench, jeg installerer sysbench på en anden server, så vi kan teste den faktiske effekt af belastning på vores MySQL-server.
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash yum -y install sysbench
Det er indstillet, at det er meget nemt at installere sysbench, det er bedre at tillade sysbench at interagere med MySQL-serveren på firewall-niveau, da dette er et testmiljø, jeg har deaktiveret firewallen på begge værter for at forhindre problemer.
Klart miljø til SysBench:
Til denne test opretter jeg sbtest-databasen og brugeren sbtest_user og vil give alle PRIVILEGES til sbtest_user på sbtest-databasen.
ved hjælp af root;
mysql> create database sbtest mysql> create user sbtest_user identified by 'password'; mysql> grant all on sbtest.* to `sbtest_user`@`%`; mysql> show grants for sbtest_user; +---------------------------------------------------------+ | Grants for [email protected]% | +---------------------------------------------------------+ | GRANT USAGE ON *.* TO `sbtest_user`@`%` | | GRANT ALL PRIVILEGES ON `sbtest`.* TO `sbtest_user`@`%` | +---------------------------------------------------------+
Ydeevne af MySQL ved hjælp af SysBench
Benchmark-konfiguration:
Forberedelsestrinnet i sysbench opretter tabellerne med de data, der vil blive brugt i benchmark. I dette eksempel kører vi prepare-kommandoen. Der er et par parametre med MySQL i begyndelsen, det vil være forbindelsesparametrene. De andre parametre er parametre for oltp_read_write.lua-testen, og vi angiver selve testen, som er oltp_read_write.lua, og at vi kører prepare-kommandoen. Indstillingen, der starter med MySQL, er at angive MySQL-forbindelsen, værtsnavnet og porten, der skal oprettes forbindelse til, brugernavnet og adgangskoden, der skal oprettes forbindelse til, og standardskemaet for forbindelsen. Tabellerne og table_size-parametrene er egenskaberne for oltp_read_write.lua-testen.
Det betyder, at forberedelsestrinnet vil skabe 16 tabeller med 10.000 regler i hver af dem. Det næste trin er at køre benchmark.
For at køre typisk sendes alle parametrene, som vil overføres til forberedte, og nogle yderligere, som vi gennemgik nu, disse er specifikke for den faktiske kørsel af benchmark. "TID" parameter angiver tidsgrænsen for benchmark til at køre, nul betyder ubegrænset tid, benchmark vil køre indtil vi rammer control+c. Det er sådan, vi vil bruge sysbench i laboratoriet, og det er sådan, folk typisk bruger det i læring og ikke i en benchmarking-opsætning.
Vi vil bare udløse trafik på noget, vi vil undersøge, og vi kan stoppe det med kontrol+c, når vi er færdige med undersøgelsen.
"rapportintervallet" parametre angiver, hvor ofte sysbench blev udskrevet statistik. Typisk er dette sat til 1 ligesom i vores eksempel, hvilket får sysbench til at udskrive linjen for hvert sekund. Selv i benchmarking-opsætninger er denne parameter meget brugt, fordi tænk, hvis vi har et timelangt benchmark, og vi kun har aggregerede statistikker i slutningen, fortæller det ikke noget om fordelingen af dataene, såsom hvordan ydeevnen var på serveren over tid . "tråden" option angiver antallet af klienttråde eller MySQL-forbindelser, der skal bruges i sysbench. Antallet af klienttråde vil også have en effekt på antallet af servertråde, der kan bruges. "kursen" parameter angiver ankomsthastigheden af sysbench-transaktioner som en måde at virkelig imødekomme belastningen forårsaget af benchmark. Hvis transaktioner kan fortsætte, sættes de i kø, det er igen noget, der typisk bruges i denne form for opsætning, hvad vi nu skal bruge i en læringstype af opsætning.
Fra sysbench-vært:
Forbered et datasæt:
På den virtuelle benchmarkingmaskine skal vi køre kommandoen sysbench prepare for at oprette en database til vores benchmarks.
Her kan vi se, at vi bruger sbtest_user det som brugernavn, adgangskoden er adgangskode, og vi opretter forbindelse til 192.168.66.5 DB som databaseserver.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Creating table 'sbtest1'... Inserting 10000 records into 'sbtest1' Creating a secondary index on 'sbtest1'... . . . Creating table 'sbtest16'... Inserting 10000 records into 'sbtest16' Creating a secondary index on 'sbtest16'..
Du har sbtest-databasen lige her, lad os ændre standardskemaet til sbtest-databasen, tjek hvilke tabeller vi har.
Vi specificerede, at benchmark skulle oprette seksten tabeller, og det oprettede 16 tabeller, vi kan se det her
mysql> show tables; +------------------+ | Tables_in_sbtest +------------------+ | sbtest1 | | sbtest2 | . . . | sbtest16 | +------------------+ 16 rows in set (0.01 sec)
Lad os tjekke nogle få poster fra en tabel.
mysql> select * from sbtest1 limit 6;
vi skal køre et benchmark. Dette benchmark vil have én outputlinje for hvert sekund, fordi vi indstiller rapport, intervallet er lig med én, og det har fire klienttråde, fordi vi indstiller tråde til fire.
--events=N limit for total number of events [0] --time=N limit for total execution time in seconds [10]
De ovenstående to indstillinger (hændelser og tid) 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.
På sysbench-vært:
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run WARNING: Both event and time limits are disabled, running an endless test sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with the following options: Number of threads: 4 Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 4 tps: 62.79 qps: 1320.63 (r/w/o: 933.91/257.15/129.57) lat (ms,95%): 80.03 err/s: 0.00 reconn/s: 0.00 [ 2s ] thds: 4 tps: 77.01 qps: 1530.26 (r/w/o: 1065.18/312.05/153.03) lat (ms,95%): 61.08 err/s: 0.00 reconn/s: 0.00 [ 3s ] thds: 4 tps: 74.03 qps: 1463.67 (r/w/o: 1025.47/289.13/149.07) lat (ms,95%): 70.55 err/s: 0.00 reconn/s: 0.00 [ 4s ] thds: 4 tps: 69.99 qps: 1414.84 (r/w/o: 991.89/282.97/139.98) lat (ms,95%): 65.65 err/s: 0.00 reconn/s: 0.00 [ 5s ] thds: 4 tps: 74.02 qps: 1488.34 (r/w/o: 1048.24/292.07/148.03) lat (ms,95%): 74.46 err/s: 0.00 reconn/s: 0.00 [ 6s ] thds: 4 tps: 72.99 qps: 1444.89 (r/w/o: 1003.92/294.98/145.99) lat (ms,95%): 70.55 err/s: 0.00 reconn/s: 0.00 [ 7s ] thds: 4 tps: 63.00 qps: 1271.04 (r/w/o: 890.03/255.01/126.00) lat (ms,95%): 87.56 err/s: 0.00 reconn/s: 0.00 [ 8s ] thds: 4 tps: 72.99 qps: 1439.82 (r/w/o: 1008.87/284.96/145.98) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 9s ] thds: 4 tps: 74.00 qps: 1488.01 (r/w/o: 1038.01/302.00/148.00) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00
så vi kan se, at den udfører omkring 70 80 transaktioner i sekundet på min maskine, hvilket svarer til mere end tusinde forespørgsler i sekundet. Dette kører i VirtualBox på en bærbar computer.
Fra disse forespørgsler kan vi se, hvor mange af dem der er læst, hvor mange af dem der er skrivninger, hvor mange af dem er andre, hvad er den 95. percentil latency for transaktionen (r/w/o:1038.01/302.00/148.00), hvordan mange fejl per sekund (err/s:0.00 ) vi har, og hvor mange forbindelser per sekund (reconn/s:0.00) vi har. Fordi vi angiver, at tiden er lig nul, vil dette køre, indtil vi trykker på ctrl+c.
Lad os tjekke showproceslisten på databaseværten.
mysql> show processlist; +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 23200 | Waiting on empty queue | NULL | | 11 | root | localhost | NULL | Sleep | 18438 | | NULL | | 19 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 23 | root | localhost | NULL | Sleep | 4098 | | NULL | | 30 | sbtest_user | 192.168.66.6:37298 | sbtest | Sleep | 0 | | NULL | | 31 | sbtest_user | 192.168.66.6:37300 | sbtest | Execute | 0 | waiting for handler commit | COMMIT | | 32 | sbtest_user | 192.168.66.6:37302 | sbtest | Sleep | 0 | | NULL | | 33 | sbtest_user | 192.168.66.6:37304 | sbtest | Execute | 0 | Opening tables | SELECT c FROM sbtest13 WHERE id=4978 | +----+-----------------+--------------------+--------+---------+-------+----------------------------+--------------------------------------+
8 rækker i sæt (0,00 sek.)
Databaseserveren var stort set altid optaget. Jeg så, at den udførte tid praktisk talt aldrig ændrer sig fra nul, og det var meget nemt at fange databaseserveren i aktion, som når den kører "SELECT c FROM sbtest13 WHERE id=4978". Og bestemt, vi har fire forbindelser fra benchmarking-maskinen
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.
--rate=N average transactions rate. 0 for unlimited rate [0]
På sysbench-vært
[[email protected] ~]# sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --report-interval=1 \ --rate=40 \ /usr/share/sysbench/oltp_read_write.lua run WARNING: Both event and time limits are disabled, running an endless test sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 4 Target transaction rate: 40/sec Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 4 tps: 42.87 qps: 858.43 (r/w/o: 600.20/171.49/86.74) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 1s ] queue length: 0, concurrency: 1 [ 2s ] thds: 4 tps: 41.01 qps: 857.25 (r/w/o: 609.17/164.05/84.02) lat (ms,95%): 101.13 err/s: 0.00 reconn/s: 0.00 [ 2s ] queue length: 0, concurrency: 3 [ 3s ] thds: 4 tps: 57.01 qps: 1119.29 (r/w/o: 778.20/228.06/113.03) lat (ms,95%): 73.13 err/s: 0.00 reconn/s: 0.00 [ 3s ] queue length: 0, concurrency: 2 . . . [ 15s ] thds: 4 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 15s ] queue length: 145, concurrency: 4 [ 16s ] thds: 4 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 16s ] queue length: 179, concurrency: 4
Så den nye parameter her er –rate er lig med 40, hvilket betyder, at vi vil have to linjer i sekundet, to linjer med output og ikke én. Fordi vi indstiller ankomsthastigheden for benchmarking-begivenheder til 40 pr. sekund, vil vi se den aktuelle TPS.
Dette er ikke garanteret at være 40/sekund, men ankomsten garanterer det, at vi i gennemsnit laver omkring 40 transaktioner i sekundet, og vi kan overvåge kølængden og samtidigheden på den anden linje. Hvis vi laver en kort procesliste, er det meget nemmere at fange databasen i en tilstand, hvor nogle forbindelser bare venter her.
Mens en session er optaget, kan du se, at transaktionen pr. sekund er nul (tps:0,00 ).
mysql> show processlist; +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 19162 | Waiting on empty queue | NULL | | 8 | root | localhost | NULL | Query | 0 | starting | show processlist | | | 21 | sbtest_user | 192.168.66.6:49060 | sbtest | Execute | 33 | updating | UPDATE sbtest8 SET k=k+1 WHERE id=5005 | | 22 | sbtest_user | 192.168.66.6:49062 | sbtest | Execute | 22 | updating | UPDATE sbtest14 SET c='54592761471-89397085016-24424731626-29460127219-18466786462-73074657089-48925 | 23 | sbtest_user | 192.168.66.6:49064 | sbtest | Execute | 21 | updating | UPDATE sbtest10 SET c='68520795048-46094139936-88850487689-12482054639-29231339380-71050139550-93403 | | 24 | sbtest_user | 192.168.66.6:49066 | sbtest | Execute | 31 | updating | DELETE FROM sbtest14 WHERE id=4994 | +----+-----------------+--------------------+--------+---------+-------+------------------------+------------------------------------------------------------------------------------------------------+ 10 rows in set (0.00 sec)
Vi kan se, at dette sover i et par sekunder, det var stort set umuligt i det forrige scenarie at få noget som dette.
Skriv tung trafik med slutrapport:
Lad os udføre en skrivetung (men ikke skrive-kun) arbejdsbelastning og f.eks. test I/O-undersystemets ydeevne, som jeg nævnte tid=300 så vil benchmark køre i 300 sek., og det vil give os en slutrapport til at analysere det.
[[email protected] ~]# sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=8 \ --time=300 \ --events=0 \ --report-interval=1 \ --rate=40 \ /usr/share/sysbench/oltp_read_write.lua run sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 8 Target transaction rate: 40/sec Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 8 tps: 39.87 qps: 810.27 (r/w/o: 570.08/159.46/80.73) lat (ms,95%): 82.96 err/s: 0.00 reconn/s: 0.00 [ 1s ] queue length: 0, concurrency: 1 [ 2s ] thds: 8 tps: 43.02 qps: 847.39 (r/w/o: 590.27/172.08/85.04) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00 [ 2s ] queue length: 0, concurrency: 0 . . . [ 350s ] thds: 8 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 350s ] queue length: 6545, concurrency: 1 SQL statistics: queries performed: read: 78624 write: 22385 other: 11205 total: 112214 transactions: 5589 (15.94 per sec.) queries: 112214 (320.02 per sec.) ignored errors: 27 (0.08 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 350.6412s total number of events: 5589 Latency (ms): min: 12.45 avg: 74639.59 max: 213244.02 95th percentile: 100000.00 sum: 417160677.24 Threads fairness: events (avg/stddev): 698.6250/196.36 execution time (avg/stddev): 52145.0847/15557.93
RAPPORT ANALYSE:
Dette er ganske nyttigt for at kontrollere, at den endelige rapport kun vil give dig gennemsnit. Mellemliggende resultater vil gøre det muligt at spore præstationen sekund for anden. Den endelige rapport kan se ud som ovenfor. Du finder her information om udførte forespørgsler, transaktioner blev udført, hvor mange fejl der skete, en eventuel mistet forbindelse skete, hvad var gennemløbet og den samlede forløbne tid. Du kan også tjekke latency-metrics og forespørgselsfordelingen på tværs af tråde.