W tym artykule omówimy sysbench, aktualny standard benchmarkingu MySQL. Przyjrzymy się podstawom korzystania z sysbench i jak możemy wykorzystać sysbench do nauki o MySQL, a drugi jest dla nas najważniejszy aspekt. Praktycznie użyjemy sysbench jako narzędzia do generowania ruchu, o którym wiemy dużo, ponieważ sysbench będzie co sekundę przechowywać informacje o generowanym ruchu.
Test SysBench MySQL
Sysbench to wielowątkowe narzędzie do testów porównawczych oparte na luaJIT, które jest rzeczywistym standardem testów porównawczych MySQL, musi być w stanie połączyć się z bazą danych.
Instalacja Sysbencha
Najpierw musimy zainstalować sysbench, ja instaluję sysbench na innym serwerze, abyśmy mogli przetestować rzeczywisty wpływ obciążenia na nasz serwer MySQL.
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash yum -y install sysbench
To oznacza, że instalacja sysbencha jest bardzo łatwa, lepiej jest pozwolić sysbenchowi na interakcję z serwerem MySQL na poziomie zapory ogniowej, ponieważ jest to środowisko testowe, wyłączyłem zaporę ogniową na obu hostach, aby zapobiec wszelkim trudnościom.
Gotowe środowisko dla SysBench:
Na potrzeby tego testu tworzę bazę danych sbtest i użytkownika sbtest_user i przyznaję wszystkie UPRAWNIENIA użytkownikowi sbtest_user w bazie danych sbtest.
za pomocą roota;
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`@`%` | +---------------------------------------------------------+
Wydajność MySQL przy użyciu SysBench
Konfiguracja testu porównawczego:
Krok przygotowania w sysbench tworzy tabele z danymi, które będą używane w benchmarku. W tym przykładzie uruchamiamy polecenie przygotowania. Na początku jest kilka parametrów z MySQL, będą to parametry połączenia. Pozostałe parametry to parametry testu oltp_read_write.lua i określamy sam test, którym jest oltp_read_write.lua i że uruchamiamy polecenie przygotowania. Opcja rozpoczynająca się od MySQL określa połączenie MySQL, nazwę hosta i port do połączenia, nazwę użytkownika i hasło do połączenia oraz domyślny schemat połączenia. Tabele i parametry table_size są właściwościami testu oltp_read_write.lua.
Oznacza to, że etap przygotowania utworzy 16 tabel z 10 000 reguł w każdej z nich. Następnym krokiem jest uruchomienie testu porównawczego.
Aby uruchomić, zazwyczaj przekazywane są wszystkie parametry, które przejdą do przygotowanych i kilka dodatkowych, które teraz sprawdzaliśmy, są one specyficzne dla rzeczywistego przebiegu testu porównawczego. „CZAS” parametr określa limit czasu uruchomienia testu, zero oznacza nieograniczony czas, test będzie działał do momentu naciśnięcia control+c. W ten sposób będziemy używać sysbench w laboratorium i w ten sposób ludzie zwykle używają go w nauce, a nie w konfiguracji porównawczej.
Chcemy po prostu uwolnić ruch na czymś, co zbadamy, i możemy go zatrzymać za pomocą control+c, gdy skończymy badanie.
„interwał raportu” parametry określają, jak często sysbench były drukowane statystyki. Zazwyczaj jest to ustawione na 1, jak w naszym przykładzie, co powoduje, że sysbench wypisuje linię co sekundę. Nawet w ustawieniach benchmarkingu ten parametr jest szeroko stosowany, ponieważ wyobraź sobie, że mamy godzinny benchmark i na końcu mamy tylko zagregowane statystyki, które nie mówią nic o dystrybucji danych, np. o tym, jaka była wydajność na serwerze w czasie . „Wątek” opcja określa liczbę wątków klienta lub połączeń MySQL do użycia w sysbench. Liczba wątków klienta będzie miała również wpływ na liczbę wątków serwera, których można użyć. „Stawka” parametr określa szybkość przybycia transakcji sysbench jako sposób na rzeczywiste sprostanie obciążeniu spowodowanemu przez test porównawczy. Jeśli transakcje mogą być kontynuowane, są umieszczane w kolejce, jest to znowu coś, co jest zwykle używane w tego rodzaju konfiguracji, czego teraz będziemy używać w konfiguracji typu uczenia się.
Z hosta sysbench:
Przygotuj zestaw danych:
Na maszynie wirtualnej do testów porównawczych uruchomimy polecenie przygotowania sysbench, aby utworzyć bazę danych dla naszych testów porównawczych.
Tutaj widzimy, że używamy sbtest_user it jako nazwy użytkownika, hasło to hasło i łączymy się z 192.168.66.5 DB jako serwerem bazy danych.
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'..
Masz tutaj bazę danych sbtest, zmieńmy domyślny schemat na bazę danych sbtest, sprawdź, jakie mamy tabele.
Określiliśmy, że benchmark powinien utworzyć szesnaście tabel i utworzył 16 tabel, możemy to zobaczyć tutaj
mysql> show tables; +------------------+ | Tables_in_sbtest +------------------+ | sbtest1 | | sbtest2 | . . . | sbtest16 | +------------------+ 16 rows in set (0.01 sec)
Sprawdźmy kilka rekordów z tabeli.
mysql> select * from sbtest1 limit 6;
przeprowadzimy test porównawczy. Ten test porównawczy będzie miał jedną linię wyjściową na każdą sekundę, ponieważ ustawiliśmy raport, interwał równy jest jeden i ma cztery wątki klienckie, ponieważ ustawiliśmy wątki równe czterem.
--events=N limit for total number of events [0] --time=N limit for total execution time in seconds [10]
Powyższe dwa ustawienia (zdarzenia i czas) określają, jak długo SysBench powinien działać. Może wykonać pewną liczbę zapytań lub może działać przez określony czas.
Na hoście sysbench:
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
więc widzimy, że na moim komputerze wykonuje około 70 80 transakcji na sekundę, co przekłada się na około tysiąc zapytań na sekundę. To działa w VirtualBox na laptopie.
Z tych zapytań możemy zobaczyć ile z nich to odczyty, ile zapisów, ile innych, jaki jest 95 percentyl opóźnienia dla transakcji (r/w/o:1038.01/302.00/148,00), jak ile mamy błędów na sekundę (err/s:0.00 ) i ile mamy połączeń na sekundę (reconn/s:0.00). Ponieważ określamy, że czas jest równy zero, będzie on działał, dopóki nie naciśniemy ctrl+c.
Sprawdźmy listę procesów pokazu na hoście bazy danych.
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 rzędów w zestawie (0,00 s)
Serwer bazy danych był praktycznie zawsze zajęty. Widziałem, że czas wykonania praktycznie nigdy nie zmienia się od zera i bardzo łatwo było złapać serwer bazy danych w akcji, na przykład podczas uruchamiania „SELECT c FROM sbtest13 WHERE id=4978”. I na pewno mamy cztery połączenia z maszyny testującej
Domyślnie SysBench będzie próbował wykonać zapytania tak szybko, jak to możliwe. Do symulacji wolniejszego ruchu można użyć tej opcji. Tutaj możesz zdefiniować, ile transakcji ma być wykonywanych na sekundę.
--rate=N average transactions rate. 0 for unlimited rate [0]
Na hoście sysbench
[[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
Więc nowym parametrem jest tutaj –rate równa się 40, co oznacza, że będziemy mieć dwa wiersze na sekundę, dwa wiersze wyjścia, a nie jeden. Ponieważ ustawiliśmy szybkość przybycia zdarzeń benchmarkingowych na 40 na sekundę, zobaczymy aktualny TPS.
Nie ma gwarancji, że będzie to 40 na sekundę, ale przybycie gwarantuje, że średnio wykonujemy około 40 transakcji na sekundę i możemy monitorować długość kolejki i współbieżność na drugiej linii. Jeśli zrobimy krótką listę procesów, znacznie łatwiej jest złapać bazę danych w stanie, w którym niektóre połączenia po prostu czekają tutaj.
Gdy sesja jest zajęta, możesz zobaczyć, że transakcja na sekundę wynosi zero (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)
Widzimy, że to śpi przez kilka sekund, w poprzednim scenariuszu uzyskanie czegoś takiego było prawie niemożliwe.
Natężony ruch związany z zapisem i raportem końcowym:
Wykonajmy duże obciążenie związane z zapisem (ale nie tylko zapisem) i, na przykład, wydajność testowego podsystemu I/O, jak wspomniałem time=300 następnie test porównawczy będzie działał przez 300 sekund i da nam raport końcowy do jego analizy.
[[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
ANALIZA RAPORTU:
Jest to bardzo przydatne, aby sprawdzić, czy raport końcowy zawiera tylko średnie. Wyniki pośrednie umożliwią śledzenie wyników z sekundy na sekundę. Raport końcowy może wyglądać jak powyżej. Znajdziesz tutaj informacje o wykonanych zapytaniach, zrealizowanych transakcjach, ile wystąpiło błędów, nastąpiło jakiekolwiek zgubienie połączenia, jaka była przepustowość i całkowity czas, jaki upłynął. Możesz także sprawdzić metryki opóźnień i rozkład zapytań w wątkach.
