Polsko-Japońska Wyższa Szkoła Technik Komputerowych Wydział Zamiejscowy Informatyki w Bytomiu Badanie wydajności i optymalizacja bazy danych MySQL Marcin Hłybin, numer indeksu s4641 prowadzący: dr inż. Aleksander Nawrat STRESZCZENIE Praca omawia zagadnienia związane z optymalizacją bazy danych MySQL. Została omówiona wstępna konfiguracja bazy, która powinna zostać przeprowadzona tuż po instalacji. Następnie poruszony został temat optymalizacji zapytań z wykorzystaniem funkcji EXPLAIN oraz temat przyspieszenia wykonywania zapytań za pomocą indeksów. Kolejnym zagadnieniem jest obserwacja zachowania bazy danych podczas pracy za pomocą programu mysqlreport, który został szczegółowo omówiony, oraz za pomocą wewnętrznego polecenia bazy MySQL SHOW PROCESS LIST.
Spis treści 1 Wstęp... 3 2 Wstępna konfiguracja... 3 3 Optymalizacja zapytań... 4 3.1 Zastosowanie indeksów... 5 3.2 Wykorzystanie polecenia EXPLAIN... 5 3.3 Wyszukiwanie wolnych zapytań... 6 4 Badanie aktywności bazy danych... 6 4.1 Program mysqlreport... 7 4.2 Lista procesów... 11 5 Narzędzia wspomagające optymalizację... 11 6 Podsumowanie... 12 7 Bibliografia... 12 Badanie wydajności i optymalizacja bazy danych MySQL. Strona 2
1 Wstęp Optymalizacja bazy danych to proces skomplikowany i długotrwały, ponieważ wymaga zrozumienia działania systemu jako całości, a także każdego aspektu z osobna wpływającego na szybkość wykonywania zapytań. Na działanie MySQL wpływa bardzo wiele czynników. Badanie wydajności pozwoli nam ustalić wąskie gardła i rzeczy, które wymagają skonfigurowania lub poprawy obecnej konfiguracji. Zaczniemy od działań, które należy podjąć tuż po zainstalowaniu serwera baz danych. Następnie zajmiemy się sprawą najbardziej oczywistą, czyli optymalizacją zapytań z użyciem indeksów i oceną ich poprawności za pomocą wbudowanej komendy EXPLAIN. Ostatnim krokiem będzie obserwacja pracy bazy danych w czasie obciążenia, a w szczególności takich parametrów jak ilość zapytań na sekundę, wykorzystanie przestrzeni w pamięci operacyjnej przeznaczonej na indeksy oraz wydajność systemu cache. 2 Wstępna konfiguracja MySQL posiada wiele zmiennych konfiguracyjnych, jednak są takie, których odpowiednie ustawienie jest koniecznością. W przeciwnym wypadku, serwer baz danych, nawet przy najmniejszym obciążeniu będzie miał problemy z obsłużeniem wszystkich żądań. Po odpowiednim ustawieniu poniższych parametrów już na pierwszy rzut oka będzie można zobaczyć poprawę. key_buffer_size jeśli używasz silnika składowania danych typu MyISAM jest to bardzo ważna zmienna. Można śmiało zwiększyć tę wartość do 30-40% całkowitej pamięci. Zmienna ta definiuje przestrzeń, w której między innymi trzymane są indeksy. Oczywiście ustawienie tej zmiennej na bardzo wysoką wartość w przypadku posiadania indeksów o wielkości 100M byłoby marnotrawstwem pamięci. Jeśli nasza maszyna dysponuje dużą ilością pamięci warto policzyć wielkość indeksów to znaczy wielkość wszystkich plików z rozszerzeniem.myi w katalogu bazy danych (domyślnie /var/lib/mysql). Przykładowo będą w katalogu naszej bazy możemy wydać polecenie: # du *.MYI awk '{sum += $1} END { print sum }' 23303200 Otrzymany wynik to wartość w kilobajtach. Oznacza to, że nasze indeksy zajmują 22GB, czyli całkiem sporo. Jeśli dysponujmy taką ilością pamięci warto ustawić zmienną key_buffer_size na 23GB. innodb_buffer_pool_size natomiast w przypadku posiadania tabel typu InnoDB ta zmienna jest bardzo ważna. Tabele InnoDB są z natury bardziej wrażliwe na wielkość tego bufora niż tabele typu MyISAM na ustawienia key_buffer_size. W przypadku niewłaściwego Badanie wydajności i optymalizacja bazy danych MySQL. Strona 3
dostosowania tej wartości, w postaci przeznaczenia zbyt małej ilości pamięci, operacje na tabelach InnoDB będą wykonywane nieznośnie wolne. Należy pamiętać o tym, że bufor InnoDB keszuje zarówno strony, indeksy jak i dane, dlatego w optymalnej sytuacji, jego wielkość powinna być większa niż wielkość samych indeksów. innodb_log_file_size mając do czynienia ze środowiskami, w których występuje dużo zapisów ten parametr ma szczególne znaczenie. Większy rozmiar oferuje większą wydajność, jednak wydłuża czas odzyskiwania baz danych w przypadku awarii. table_cache otwieranie tabel może być kosztowne, szczególnie w przypadku ich dużej ilości. Później dowiemy się jak sprawdzić ilość używanych tabel przez bazę MySQL. query_cache_size w przypadku środowisk, które wykonują dużo operacji odczytów z bazy danych ten parametr może bardzo pomóc, ponieważ jest odpowiedzialny za wielkość cache dla wyników zapytań. Oznacza to, że jeśli dwukrotnie wykonamy to samo zapytanie, wartość drugiego zostanie zwrócona bezpośrednio z pamięci nie obciążając bazy danych. Z drugiej strony ilość pamięci przeznaczonej na cache nie powinien być zbyt wysoki, ponieważ zarządzanie może być kosztowne. 3 Optymalizacja zapytań Każde zapytanie, od momentu uruchomienia do zwrócenia wyników, zabiera cenny czas. Im krótszy będzie ten czas, tym lepiej dla nas i nasza maszyna będzie w stanie obsłużyć większą ilość równoległych połączeń, czyli klientów. Poza tym użytkownik lub aplikacja korzystająca z bazy danych, otrzyma wyniki szybciej, co przeważnie przekłada się do szybszego wyświetlenia strony WWW. Istnieje kilka technik przyspieszania zapytań do bazy danych: tworzenie indeksów na tabelach w celu przyspieszenia wyszukiwania interesujących rekordów badanie zachowania bazy danych podczas wykonywania zapytania za pomocą polecenia EXPLAIN wyszukiwanie wolnych zapytań za pomocą MySQL slow log. tuningowanie parametrów serwera bazodanowego MySQL, co właściwie już omówiliśmy analiza sprzętu i jego zachowania podczas pracy bazy danych w celu poprawy wydajności Badanie wydajności i optymalizacja bazy danych MySQL. Strona 4
3.1 Zastosowanie indeksów Dane występujące w tabelach mają charakter nieuporządkowany. W celu wyszukania konkretnego wiersza na przykład wydając zapytanie SELECT * FROM pracownicy WHERE id=10; serwer bazodanowy MySQL musi wykonać tzw. pełny skan tabeli (ang. full table scan), czyli fizycznie zaczynając od pierwszego rekordu musi przejść kolejno przez wszystkie rekordy, aż do ostatniego w poszukiwaniu wartości kolumny id równej 10. Oczywiście nie kończy po znalezieniu pierwszego rekordu, ponieważ zapytanie prosi o zwrócenie wszystkich rekordów. Skanowanie każdorazowo tabeli to operacja bardzo kosztowna, której wydajność zależy od prędkości dysku twardego i jego czasu odpowiedzi. Nie trudno sobie wyobrazić, że z bazy danych korzysta więcej niż jedna osoba i zwracanie wyników w ten sposób oznacza ciężką pracę dysku twardego i częste przemieszczenie głowicy w różne miejsca. Aby temu zapobiec stosuje się indeksy. Wyróżniamy różne typy indeksów najbardziej popularne to BTREE, HASH i FULLTEXT. Zasada działania indeksu na tabeli jest bardzo prosta. Indeks zapisuje wartości kolumny na którą nakładamy indeks, ale w postaci posortowanej. Jeśli poszukujemy w tabeli pracownicy, pracownika o numerze ID równym 10 to MySQL skanuje indeks z góry na dół w poszukiwaniu wartości 10. Operacja ta jest dużo szybsza niż skanowanie tabeli, ponieważ indeks jest dużo mniejszy, a poza tym najczęściej znajduje się w całości w pamięci RAM. Po znalezieniu liczby 10 następuje przejście do następnej pozycji. Jeśli tam także znajduje się 10 to przetwarzana jest kolejna pozycja. Jeśli w kolejnej natomiast baza danych napotka liczbę 11 to kończy przeszukiwanie, ze względu na to, że wartości są posortowane i liczba 10 z pewnością w innym miejscu już nie wystąpi. Wykorzystanie indeksów daje nam kolosalny wzrost wydajności zapytań. 3.2 Wykorzystanie polecenia EXPLAIN W celu optymalizacji zapytań musimy się dowiedzieć w jaki sposób baza danych je przetwarza i jaką drogę wybiera w celu wyświetlenia interesujących nas wyników. Do tego celu powstało polecenie EXPLAIN, którego zastosowanie jest przedstawione poniżej: mysql> EXPLAIN SELECT * FROM produkty WHERE id=671422756; +----+-------------+----------+------+---------------+-----+---------+-------+------+-------+ id select_type table type possible_keys key key_len ref rows Extra +----+-------------+----------+------+---------------+-----+---------+-------+------+-------+ 1 SIMPLE produkty ref id id 4 const 2 +----+-------------+----------+------+---------------+-----+---------+-------+------+-------+ 1 row in set (0,01 sec) W powyższym przykładzie widzimy, że nasze zapytanie może skorzystać z indeksu o nazwie id. Informuje nas o tym wartość possibile_keys. Zadanie systemu zarządzania bazą danych jest decyzja, czy i którego indeksu najbardziej opłaca się użyć. W tym przypadku, jak najbardziej zastosowanie ma indeks id, dlatego też w kolumnie key zostaliśmy poinformowani, że zostanie on użyty. Kolumna Badanie wydajności i optymalizacja bazy danych MySQL. Strona 5
rows informuje nas, że zostaną zwrócone dwa wiersze. Prześledzenie wyników polecenia EXPLAIN jest bardzo istotne, szczególnie przy skomplikowanych zapytaniach wykorzystujących złączenia tabel (polecenia JOIN) i podzapytania. 3.3 Wyszukiwanie wolnych zapytań Baza danych MYSQL ma możliwość zapisywania informacji o zapytaniach, które wykonały się powyżej zdefiniowanego czasu wolnego zapytania np. 1 sekundy. Zapytania takie zapisywane są do pliku nazywanego slow.log, którego analiza pomoże w optymalizacji zapytań. Znając zapytania, które wykonują się za długo możemy zrobić dwie rzeczy: zmienić logikę aplikacji, tak aby zamiast jednego skomplikowanego zapytania wykonała dwa lub więcej, ale dużo szybszych zapytań na podstawie analizy wyników polecenia EXPLAIN zoptymalizować zapytanie poprzez jego zmianę lub dodanie odpowiedniego indeksu Za pomocą slow.log możemy także wyłapywać zapytania, które nie używają indeksów. Jest to bardzo przydatna opcja. Przykłady wyciąg z pliku slow.log wygląda następująco: # Time: 091015 11:38:54 # User@Host: pokemonl_admin[pokemonl_admin] @ localhost [] # Query_time: 4 Lock_time: 0 Rows_sent: 6 Rows_examined: 3471031 SELECT pokemon_id,pokemon_name,pokemon_level FROM user_pokemon WHERE user_id LIKE '_pesao' and in_party='y' LIMIT 6; Z powyższego łatwo wywnioskować, że wykonanie zapytania trwało aż 4 sekundy, w wyniku zwrócono 6 wierszy, a MySQL przeskanował prawie trzy i pół miliona wierszy. 4 Badanie aktywności bazy danych Informacja o pracy bazy danych jest bardzo ważna dla administratora. MySQL dysponuje dwoma poleceniami: SHOW STATUS, które raportuje 291 parametrów obrazujących obecny stan bazy danych SHOW PROCESSLIST, które wyświetla bieżące działania wykonywane w bazie danych Wynik pierwszego polecenia wydaje się bardzo niewygodny i nieporęczny dlatego powstało narzędzie mysqlreport, napisane w języku Perl ułatwiające analizę tych danych. Badanie wydajności i optymalizacja bazy danych MySQL. Strona 6
4.1 Program mysqlreport Program mysqlreport pobiera dane statusowe z serwera MySQL i wyświetla jest w formie przyjaznej dla użytkownika. Omówienie skryptu mysqlreport rozpoczniemy od prezentacji wyników jego działania. Ze względu na to, że jest on dosyć długi na potrzeby tego tekstu raport został podzielony na działy, które zostaną omówione po kolei. MySQL 5.1.26-rc-log uptime 5 19:54:47 Sun Feb 28 17:35:17 2010 Key Buffer used 1.64G of 2.00G %Used: 81.76 Current 666.59M %Usage: 32.55 Write hit 87.77% Read hit 99.86% Pierwsza linia to podstawowe informacje na temat naszej bazy danych, takie jak: numer wersji, czas działania i aktualna data. Zaraz poniżej mamy informacje dotyczące key_buffer, o którym wspomnieliśmy na samym początku i w którym przechowywane są indeksy. Zdefiniowana została maksymalna ilość pamięci jaką może zająć jest to wartość dwóch gigabajtów. W czasie działania bazy danych maksymalnie było zajętych 81.75 %. Poniżej mamy informację w jakim stopniu bufor jest zużywany w tym momencie, a następnie procentowy stosunek zapisów i odczytów klucza z pamięci do zapisów i odczytów klucza z dysku twardego. Questions Total 109.20M 216.8/s QC Hits 45.69M 90.7/s %Total: 41.84 DMS 36.19M 71.9/s 33.14 Com_ 23.93M 47.5/s 21.91 COM_QUIT 4.46M 8.9/s 4.09 -Unknown 1.07M 2.1/s 0.98 Slow 1 s 4.02M 8.0/s 3.68 %DMS: 11.11 Log: ON DMS 36.19M 71.9/s 33.14 SELECT 27.33M 54.3/s 25.03 75.52 UPDATE 4.24M 8.4/s 3.89 11.73 INSERT 3.22M 6.4/s 2.95 8.90 DELETE 1.35M 2.7/s 1.23 3.72 REPLACE 47.26k 0.1/s 0.04 0.13 Com_ 23.93M 47.5/s 21.91 set_option 14.17M 28.1/s 12.97 change_db 4.03M 8.0/s 3.69 show_fields 957.06k 1.9/s 0.88 Kolejna część raportu informuje nas o tym jakiego typu zapytania przyjmuje nasza baza danych. Pierwsza linia to ilość wszystkich zapytań w czasie działania bazy danych oraz ilość zapytań na sekundę. W momencie stworzenia tego raportu do bazy zadawanych jest ponad 216 zapytań na sekundę. Następnie wszystkie zapytania podzielone są na różne rodzaje. Najważniejsze z nich to: Badanie wydajności i optymalizacja bazy danych MySQL. Strona 7
QC Hits oznacza odpowiedzi systemu cache DMS to zapytania manipulujące danymi typu SELECT, INSERT, DELETE, UPDATE, REPLACE, CALL i inne Com_ to komendy wewnętrzne MySQL, przeważnie związane z protokołem. Wysoka wartość jest niewskazana. Informacja Slow jest bardzo istotna. Oznacza ilość znalezionych wolnych zapytań w naszym przypadku to takie, których wykonanie trwa dłużej niż 1 sekundę. Jak widać jest 8 takich zapytań w trakcie sekundy. Następnie widzimy podział zapytań manipulujących danymi na już konkretne typu SELECT, UPDATE, INSERT, DELETE i REPLACE. Z tej informacji możemy łatwo wywnioskować w jakim stopniu nasza baza pracuje w trybie odczytu, a w jakim w trybie zapisu. Na zakończenie mamy podział zapytań typu Com_. SELECT and Sort Scan 6.11M 12.1/s %SELECT: 22.36 Range 2.64M 5.2/s 9.67 Full join 99.14k 0.2/s 0.36 Range check 39 0.0/s 0.00 Full rng join 43.12k 0.1/s 0.16 Sort scan 1.62M 3.2/s Sort range 910.54k 1.8/s Sort mrg pass 362.21k 0.7/s Kolejny dział to szczegółowe informacje na temat zapytań typu SELECT i sortowania. Scan mówi nam jak często przeprowadzane jest skanowanie całej tabeli (ang. full table scan), range to zapytania szukające zakresu danych. Query Cache Memory usage 1.16G of 2.00G %Used: 57.79 Block Fragmnt 21.02% Hits 45.69M 90.7/s Inserts 18.05M 35.8/s Insrt:Prune 36.53:1 34.9/s Hit:Insert 2.53:1 Kolejny dział mówi o użyciu przez bazę systemu keszującego. W naszym przykładzie dostępnych jest 2GB pamięci, z czego prawie 60% jest wykorzystana. Następnie mamy informację o fragmentacji bloków oraz ile zapytań trafia w cache oraz jak często zapytania są do niego dodawane. Badanie wydajności i optymalizacja bazy danych MySQL. Strona 8
Table Locks Waited 83.70k 0.2/s %Total: 0.18 Immediate 46.63M 92.6/s Tables Open 32357 of 3236 %Cache: 99.98 Opened 1.89M 3.8/s Connections Max used 551 of 800 %Max: 68.88 Total 4.56M 9.0/s Created Temp Disk table 2.32M 4.6/s Table 4.21M 8.4/s Size: 32.0M File 38.19k 0.1/s Threads Running 7 of 117 Cached 3 of 8 %Hit: 97.02 Created 135.59k 0.3/s Slow 3 0.0/s Aborted Clients 187.99k 0.4/s Connects 283 0.0/s Bytes Sent 510.21G 1.0M/s Received 17.93G 35.6k/s Powyższych danych raczej nie trzeba tłumaczyć, bo na pierwszy rzut oka wydają się jasne. Znajdziemy tutaj informacje na temat blokad zakładanych na tabele, otwartych tabeli, ilości połączeń, tymczasowych tabeli, wątków, przerwanych połączeń oraz ilości przesyłanych danych. Aktualnie baza generuje ruch o wielkości jednego megabajta na sekundę, czyli dosyć sporo. InnoDB Buffer Pool Usage 1.00G of 1.00G %Used: 100.00 Read hit 99.92% Pages Free 1 %Total: 0.00 Data 62.89k 95.97 %Drty: 0.07 Misc 2643 4.03 Latched 0 0.00 Reads 3.05G 6.1k/s From file 2.42M 4.8/s 0.08 Ahead Rnd 87858 0.2/s Ahead Sql 153614 0.3/s Writes 472.65M 938.4/s Badanie wydajności i optymalizacja bazy danych MySQL. Strona 9
Flushes 5.79M 11.5/s Wait Free 0 0/s Kolejny dział dotyczy już tylko tabeli wykorzystujących silnik InnoDB. Mamy informację o omawianym na początku parametrze innodb_buffer_pool, który w tym momencie niestety jest w całości zajęty. Następnie pojawia się informacja o stronach oraz informacja na temat operacji odczytu i zapisu. InnoDB Lock Waits 3179 0.0/s Current 0 Time acquiring Total 1319105 ms Average 414 ms Max 31256 ms InnoDB Data, Pages, Rows Data Reads 3.32M 6.6/s Writes 6.25M 12.4/s fsync 654.79k 1.3/s Pending Reads 0 Writes 0 fsync 0 Pages Created 389.01k 0.8/s Read 15.18M 30.1/s Written 5.79M 11.5/s Rows Deleted 502.39k 1.0/s Inserted 6.54M 13.0/s Read 3.71G 7.4k/s Updated 155.08M 307.9/s Na koniec otrzymamy szczegółowe informacje na temat danych, stron i krotek zawartych w tabelach typu InnoDB. Całość raportu jest bardzo opisowa i dostarcza administratorowi bardzo ciekawych informacji na temat działania bazy danych MySQL. Badanie wydajności i optymalizacja bazy danych MySQL. Strona 10
4.2 Lista procesów Za pomocą polecenia SHOW PROCESSLIST możemy wyświetlić aktualnie przetwarzane zapytania przez MySQL. Przykład takiego polecenia wygląda następująco: mysql> show processlist; +----+------+-----------+---------+---------+------+-------+----------------------+ Id User Host db Command Time State Info +----+------+-----------+---------+---------+------+-------+----------------------+ 7 root localhost allegro Query 4375 NULL analyze table buyers 8 root localhost NULL Query 0 NULL show processlist +----+------+-----------+---------+---------+------+-------+----------------------+ 2 rows in set (0,00 sec) Widzimy dokładnie jaki użytkownik, połączony z jakiego hosta, wykonuje jakie polecenie na jakiej bazie danych. Istnieje możliwość zabicia procesu za pomocą polecenia KILL do identyfikacji procesu posłuży nam numer Id z pierwszej kolumny. Istnieje narzędzie o nazwie mytop, które ułatwia oglądanie operacji obecnie wykonywanych przez MySQL. Swoim wyglądem bardzo przypomina uniksowe narzędzie top, do podglądania listy procesów w sposób przyjazny dla użytkownika. 5 Narzędzia wspomagające optymalizację Jest dostępnych kilka darmowych narzędzi, które ułatwiają administratorowi proces optymalizacji oraz wskazują potencjalne słabości w konfiguracji. Dwa z nich godne uwagi to: MySQL Tuner MySQL Performance Tuning Primer Oba narzędzia opierają się na podobnej zasadzie działania. Analizują dane polecenia SHOW STATUS, ilość dostępnej pamięci operacyjnej, wielkość indeksów itp. i na tej podstawie wyciągają wnioski. Przed uruchomieniem skryptów serwer baz danych powinien być uruchomiony co najmniej przez 24 godziny, aby zebrać dostateczną ilość informacji na temat jego działania. Skrypty wprost instruują użytkownika, które parametry w konfiguracji powinien zwiększyć lub zmniejszyć. Warto się z nimi zapoznać i po konfiguracji serwera sprawdzić, czy jeszcze którejś opcji nie da się poprawić. Badanie wydajności i optymalizacja bazy danych MySQL. Strona 11
6 Podsumowanie Baza danych MySQL do wydajnej pracy wymaga poprawnego skonfigurowania szeregu parametrów. Pomocne w tym zadaniu okażą się zarówno wewnętrzne polecenia bazy danych MySQL, jak i programy pomocnicze w postaci programu mysqltuner. Po uruchomieniu bazy wymaga ona stałej obserwacji i kontroli buforów odpowiedzialnych za jej wydajną pracę. Idealnym narzędziem do tego celu okazał się program mysqlreport, który na pierwszy rzut oka wydaje się dosyć enigmatyczny. Jeśli z naszej bazy danych korzysta wielu użytkowników uruchamiających różne aplikacje w postaci serwisów WWW, warto również zwrócić uwagę na zawartość pliku slow.log, w którym zapisywane są zapytania prawdopodobnie nadające się do przepisania lub optymalizacji stosując indeksy na odpowiednie kolumny w tabeli. 7 Bibliografia [1] MySQL, 4th edition, Paul DuBois, Pearson Education, Inc. 2009 [2] MySQL Performance Blog, http://mysqlperformanceblog.com blog firmy Percona [3] MySQL Reference, http://dev.mysql.com oficjalna dokumentacja bazy danych MySQL [4] MySQL Report, http://hackmysql.com/mysqlreport - strona domowa programu mysqlreport Badanie wydajności i optymalizacja bazy danych MySQL. Strona 12