Wydajność MySQL:identyfikacja długich zapytań

Każda aplikacja wspierana przez MySQL może korzystać z precyzyjnie dostrojonego serwera bazy danych. Zespół Liquid Web Heroic Support na przestrzeni lat napotkał wiele sytuacji, w których drobne poprawki spowodowały ogromną różnicę w wydajności witryny i aplikacji. W tej serii artykułów przedstawiliśmy niektóre z najczęstszych zaleceń, które miały największy wpływ na wydajność.

Sprawdzenie przed lotem

Ten artykuł dotyczy większości serwerów MySQL VPS opartych na systemie Linux. Obejmuje to między innymi serwery tradycyjne dedykowane i serwery Cloud VPS z różnymi popularnymi dystrybucjami systemu Linux. Artykuł może być używany z następującymi typami systemów Liquid Web:

• Rdzeń zarządzany CentOS 6x/7x
• Rdzeń zarządzany Ubuntu 14.04/16.04
• W pełni zarządzany panel cPanel CentOS 6/7
• W pełni zarządzany CentOS 7 Plesk Onyx 17
• Samozarządzane serwery Linux

Ta seria artykułów zakłada znajomość następujących podstawowych pojęć związanych z administrowaniem systemem:

• Połączenia SSH i podstawowa nawigacja w standardowym środowisku powłoki wiersza poleceń Linuksa.
• Otwieranie, edytowanie i zapisywanie plików w Vimie lub wybranym edytorze systemowym.
• Tryb interaktywny MySQL i ogólna składnia zapytań MySQL.

Co to jest optymalizacja MySQL?

Nie ma jasno zdefiniowanej definicji terminu Optymalizacja MySQL. Może to oznaczać coś innego w zależności od osoby, administratora, grupy lub firmy. W tej serii artykułów na temat optymalizacji MySQL zdefiniujemy optymalizację MySQL jako: Konfiguracja serwera MySQL lub MariaDB, który został skonfigurowany w celu uniknięcia często spotykanych wąskich gardeł omawianych w tej serii artykułów.

Co to jest wąskie gardło?

Bardzo podobne do szyjki butelki po napojach, wąskie gardło jako termin techniczny to punkt w konfiguracji aplikacji lub serwera, w którym niewielka ilość ruchu lub danych może przejść bez problemu. Jednak większy wolumen tego samego rodzaju ruchu lub danych jest utrudniony lub zablokowany i nie może działać pomyślnie bez zmian. Zobacz następujący przykład wąskiego gardła w konfiguracji:

W tym przykładzie serwer może obsługiwać jednocześnie 10 połączeń. Jednak konfiguracja akceptuje tylko 5 połączeń. Ten problem nie ujawniłby się, dopóki było 5 lub mniej połączeń naraz. Jednak gdy ruch wzrośnie do 10 połączeń, połowa z nich zaczyna zawodzić z powodu niewykorzystanych zasobów w konfiguracji serwera. Powyższe przykłady ilustrują kształt wąskiego gardła, od którego pochodzi jego nazwa, w porównaniu ze zoptymalizowaną konfiguracją, która koryguje wąskie gardło.

Kiedy powinienem zoptymalizować bazę danych MySQL?

W idealnym przypadku dostrajanie wydajności bazy danych powinno odbywać się regularnie i zanim wpłynie to na produktywność. Najlepszym sposobem postępowania jest przeprowadzanie cotygodniowych lub miesięcznych audytów wydajności bazy danych, aby zapobiec niekorzystnemu wpływowi problemów na aplikacje. Najbardziej oczywiste symptomy problemów z wydajnością to:

• Zapytania nakładają się na siebie i nigdy się nie kończą w tabeli procesów MySQL.
• Aplikacje lub strony internetowe korzystające z bazy danych spowalniają.
• Błędy przekroczenia limitu czasu połączenia, szczególnie w godzinach szczytu.

Chociaż w zajętym systemie jest to normalne, że jednocześnie w zajętym systemie działa jednocześnie kilka zapytań, pojawia się problem, gdy ich regularne kończenie trwa zbyt długo. Chociaż określony próg różni się w zależności od systemu i aplikacji, średnie czasy zapytań przekraczające kilka sekund będą objawiać się spowolnieniem w dołączonych witrynach i aplikacjach. Te spowolnienia mogą czasami zaczynać się od małych rozmiarów i pozostać niezauważone, dopóki duży wzrost natężenia ruchu nie uderzy w konkretne wąskie gardło.

Identyfikowanie problemów z wydajnością

Wiedza o tym, jak zbadać tabelę procesów MySQL, jest niezbędna do diagnozowania konkretnego napotkanego wąskiego gardła. Istnieje kilka sposobów przeglądania tabeli procesów w zależności od konkretnego serwera i preferencji. Dla zwięzłości, ta seria skupi się na najpopularniejszych metodach używanych za pośrednictwem dostępu Secure Shell (SSH):

Metoda 1. Korzystanie z tabeli procesów MySQL

Użyj „mysqladmin ’ narzędzie wiersza poleceń z flagą „processlist ” lub „proc w skrócie. (Dodanie flagi „statystyki ” lub „statystyka ’ w skrócie pokaże bieżące statystyki dla zapytań od ostatniego restartu MySQL.)

Polecenie:

mysqladmin proc stat

Wyjście:

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

Metoda 2:Użycie tabeli procesów MySQL

Uruchom zapytanie „show processlist;” z poziomu monitu trybu interaktywnego MySQL. (dodając ‘ pełny Modyfikator ’  do polecenia wyłącza obcinanie Informacje kolumna . Jest to konieczne podczas przeglądania długich zapytań).

Polecenie:

show processlist;

Wyjście:

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Korzystanie z dziennika powolnych zapytań

Innym cennym narzędziem w MySQL jest dołączona funkcja powolnego rejestrowania zapytań. Ta funkcja jest preferowaną metodą regularnego znajdowania długotrwałych zapytań. Dostępnych jest kilka dyrektyw umożliwiających dostosowanie tej funkcji. Jednak najczęściej potrzebne ustawienia to:

Dyrektywy te są ustawiane w sekcji [mysqld] pliku konfiguracyjnego MySQL znajdującego się w /etc/my.cnf i wymagają ponownego uruchomienia usługi MySQL, zanim zaczną obowiązywać. Zobacz poniższy przykład formatowania:

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

Po włączeniu dziennika powolnych zapytań będziesz musiał okresowo sprawdzać jego działanie, aby przejrzeć niesforne zapytania, które należy dostosować w celu uzyskania lepszej wydajności. Aby przeanalizować plik dziennika powolnych zapytań, możesz przeanalizować go bezpośrednio, aby przejrzeć jego zawartość. Poniższy przykład pokazuje statystyki dla przykładowego zapytania, które trwało dłużej niż skonfigurowane 5 sekund:

# Time: 180717 0:23:28 # User@Host: root[root] @ localhost [] # Thread_id: 32 Schema: employees QC_hit: No # Query_time: 627.163085 Lock_time: 0.000021 Rows_sent: 0 Rows_examined: 0 # Rows_affected: 0 use employees; SET timestamp=1531801408; call While_Loop2();

Opcjonalnie możesz użyć narzędzia wiersza poleceń mysqldumpslow, które analizuje plik dziennika powolnych zapytań i grupuje razem takie jak zapytania, z wyjątkiem wartości liczbowych i danych ciągu:

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

(Aby uzyskać informacje o użytkowaniu, odwiedź dokumentację MySQL tutaj – mysqldumpslow — Podsumowanie plików dziennika powolnych zapytań)

Wniosek

Tak kończy się pierwsza część naszej serii Optymalizacja baz danych i daje nam solidną podstawę do odniesienia się do celów porównawczych. Chociaż problemy z bazą danych mogą być skomplikowane, nasza seria podzieli te koncepcje, aby zapewnić środki do optymalizacji bazy danych poprzez konwersję bazy danych, konwersję tabel i indeksowanie.

Jak możemy pomóc?

Jesteśmy dumni z tego, że jesteśmy najbardziej pomocnymi ludźmi w hostingu™!

Nasze zespoły pomocy technicznej są wypełnione doświadczonymi technikami Linuxa i utalentowanymi administratorami systemów, którzy posiadają gruntowną wiedzę na temat wielu technologii hostingowych, zwłaszcza tych omówionych w tym artykule.

Jeśli masz jakiekolwiek pytania dotyczące tych informacji, jesteśmy zawsze dostępni, aby odpowiedzieć na wszelkie pytania związane z tym artykułem, 24 godziny na dobę, 7 dni w tygodniu 365 dni w roku.

Jeśli jesteś w pełni zarządzanym serwerem VPS, serwerem dedykowanym w chmurze, prywatną chmurą VMWare, prywatnym serwerem nadrzędnym, zarządzanymi serwerami w chmurze lub właścicielem serwera dedykowanego i nie czujesz się komfortowo podczas wykonywania którejkolwiek z opisanych czynności, my można się z nim skontaktować telefonicznie pod adresem @800.580.4985, czat lub zgłoszenie do pomocy technicznej, które pomogą Ci w tym procesie.

Nawigacja po seriachNastępny artykuł>>