I den här artikeln kommer vi att diskutera sysbench, den faktiska standarden för MySQL benchmarking. Vi kommer att ta en titt på grunderna för sysbench-användning och hur vi kan använda sysbench för att lära oss om MySQL och den andra är den viktigaste aspekten för oss. Vi kommer praktiskt taget att använda sysbench som ett verktyg för att generera trafik som vi vet mycket om eftersom sysbench kommer att lagra information om den genererade trafiken varje sekund.
SysBench MySQL Test
Sysbench är ett flertrådigt benchmarkverktyg baserat på luaJIT, det är den faktiska standarden för MySQL benchmarks, det måste kunna ansluta till databasen.
Sysbench-installation
Först måste vi installera sysbench, jag installerar sysbench på en annan server så att vi kan testa den faktiska effekten av belastning på vår MySQL-server.
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash yum -y install sysbench
Det är inställt på att det är väldigt enkelt att installera sysbench, det är bättre att tillåta sysbench att interagera med MySQL-servern på brandväggsnivå, eftersom detta är en testmiljö som jag har inaktiverat brandväggen på båda värdarna för att förhindra problem.
Klar miljö för SysBench:
För det här testet skapar jag sbtest-databasen och användaren sbtest_user och kommer att ge alla PRIVILEGES till sbtest_user på sbtest-databasen.
använder 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`@`%` | +---------------------------------------------------------+
Prestanda av MySQL med SysBench
Benchmark-konfiguration:
Förberedelsesteget i sysbench skapar tabellerna med de data som kommer att användas i benchmarken. I det här exemplet kör vi kommandot prepare. Det finns några parametrar med MySQL i början, det kommer att vara anslutningsparametrarna. De andra parametrarna är parametrar för oltp_read_write.lua-testet och vi specificerar själva testet som är oltp_read_write.lua och att vi kör kommandot prepare. Alternativet som börjar med MySQL är att specificera MySQL-anslutningen, värdnamnet och porten som ska anslutas till, användarnamnet och lösenordet att ansluta till och standardschemat för anslutningen. Tabellerna och parametrarna table_size är egenskaperna för oltp_read_write.lua-testet.
Detta innebär att förberedelsesteget kommer att skapa 16 tabeller med 10 000 regler i var och en av dem. Nästa steg är att köra benchmark.
För att köra vanligtvis alla parametrar skickas som kommer att gå till förberedda och några ytterligare som vi granskade nu, dessa är specifika för den faktiska körningen av benchmark. TID parametern anger tidsgränsen för riktmärket att köra, noll betyder obegränsad tid, riktmärket kommer att köras tills vi trycker på kontroll+c. Det är så vi kommer att använda sysbench i labbet och det är så människor vanligtvis använder det i lärande och inte i en benchmarking-inställning.
Vi vill bara släppa lös trafik på något vi ska undersöka och vi kan stoppa det med kontroll+c när vi är klara med undersökningen.
"rapportintervall" parametrar anger hur ofta sysbench skrevs ut statistik. Vanligtvis är detta satt till 1 som i vårt exempel, vilket gör att sysbench skriver ut raden för varje sekund. Även i benchmarking-inställningar används denna parameter flitigt eftersom tänk om vi har ett timlångt benchmark och vi bara har samlad statistik i slutet, det säger ingenting om fördelningen av data som hur prestanda var på servern över tiden . "tråden" alternativet anger antalet klienttrådar eller MySQL-anslutningar som ska användas i sysbench. Antalet klienttrådar kommer också att påverka antalet servertrådar som kan användas. "kurs" parametern anger ankomsthastigheten för sysbench-transaktioner som ett sätt att verkligen möta belastningen som orsakas av riktmärket. Om transaktioner kan fortsätta ställs de i kö, det här är återigen något som vanligtvis används i den här typen av konfiguration, vad vi nu ska använda i en inlärningstyp av konfiguration.
Från sysbench-värd:
Förbered en datamängd:
På den virtuella benchmarkingmaskinen kommer vi att köra kommandot sysbench prepare för att skapa en databas för våra benchmarks.
Här kan vi se att vi använder sbtest_user det som ett användarnamn, lösenordet är lösenord och vi ansluter till 192.168.66.5 DB som databasserver.
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 här, låt oss ändra standardschemat till sbtest-databasen, kolla vilka tabeller vi har.
Vi specificerade att riktmärket skulle skapa sexton tabeller och det skapade 16 tabeller, vi kan se det här
mysql> show tables; +------------------+ | Tables_in_sbtest +------------------+ | sbtest1 | | sbtest2 | . . . | sbtest16 | +------------------+ 16 rows in set (0.01 sec)
Låt oss kontrollera några poster från en tabell.
mysql> select * from sbtest1 limit 6;
vi ska köra ett riktmärke. Detta riktmärke kommer att ha en utdatarad för varje sekund eftersom vi ställer in rapport intervallet är lika med ett och det har fyra klienttrådar eftersom vi ställer in trådar lika med fyra.
--events=N limit for total number of events [0] --time=N limit for total execution time in seconds [10]
De ovanstående två inställningarna (händelser och tid) 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.
På sysbench-värd:
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 att den gör ungefär 70 80 transaktioner per sekund på min maskin, vilket översätts till ungefär mer än tusen frågor per sekund. Detta körs i VirtualBox på en bärbar dator.
Från dessa frågor kan vi se hur många av dem som är lästa, hur många av dem som är skrivningar, hur många av dem är andra vad är 95:e percentilens latens för transaktionen (r/w/o:1038.01/302.00/148.00), hur många fel per sekund (err/s:0.00 ) vi har och hur många anslutningar per sekund (reconn/s:0.00) vi har. Eftersom vi anger att tiden är lika med noll kommer detta att köras tills vi trycker på ctrl+c.
Låt oss kontrollera showprocesslistan på databasvärden.
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 rader i set (0,00 sek)
Databasservern var praktiskt taget alltid upptagen. Jag såg att den exekverade tiden praktiskt taget aldrig ändras från noll, och det var väldigt lätt att fånga databasservern i aktion som när den körs "SELECT c FROM sbtest13 WHERE id=4978". Och definitivt, vi har fyra anslutningar från benchmarkingmaskinen
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.
--rate=N average transactions rate. 0 for unlimited rate [0]
På sysbench-värd
[[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 nya parametern här är –rate är lika med 40 vilket betyder att vi kommer att ha två rader per sekund två rader av utdata och inte en. Eftersom vi ställer in ankomstfrekvensen för benchmarkinghändelserna till 40 per sekund kommer vi att se den aktuella TPS.
Detta är inte garanterat 40/sekund men ankomsten garanterar att vi i genomsnitt gör ungefär 40 transaktioner per sekund och vi kan övervaka kölängden och samtidigheten på den andra raden. Om vi gör en kort processlista är det mycket lättare att fånga databasen i ett tillstånd där vissa anslutningar bara väntar här.
Medan en session är upptagen kan du se att transaktionen per sekund är noll (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 att den här sover i några sekunder, det här var ganska omöjligt i det tidigare scenariot att få något liknande.
Skriv tung trafik med slutrapport:
Låt oss köra en skrivtung (men inte skrivbar) arbetsbelastning och till exempel test I/O-delsystemets prestanda, som jag nämnde tid=300 sedan körs riktmärket i 300 sekunder och det ger oss en slutrapport för att analysera 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
RAPPORTANALYS:
Detta är ganska användbart för att kontrollera att slutrapporten endast ger dig medelvärden. Mellanliggande resultat kommer att göra det möjligt att spåra prestandan sekund för sekund. Slutrapporten kan se ut som ovan. Här hittar du information om utförda förfrågningar, transaktioner som utfördes, hur många fel som hände, eventuella anslutningsbortfall hände, vad var genomströmningen och total förfluten tid. Du kan också kontrollera latensstatistik och frågefördelningen över trådar.