Tak jak obiecałem w poprzednim poście, tym razem opiszę dlaczego narzędzie mk-query-digest jest czymś genialnym, dlaczego Barona Schwartza należałoby ozłocić i dlaczego trudno mi wyobrazić sobie pracę bez tego narzędzia.
W trakcie analizy wydajności serwera i szukania przyczyn wolniejszego działania bazy najbardziej przydatnym źródłem informacji dla administratora są slowlogi. Dawno dawno temu opisywałem (tu i tu) jakie informacje można w nich znaleźć. W zależności od tego, jaką wersję serwera MySQL używamy może ich być mniej lub więcej. W przypadku Percona Server informacji tych jest zazwyczaj wystarczająco aby zlokalizować zapytanie będące przyczyną problemu – zapytanie to jednak najpierw musi do logów trafić. Domyślnie, MySQL loguje zapytania o czasie wykonywania dłuższym niż 10 sekund. W większości wypadków jest to dużo za dużo. Osobiście stosuję long_query_time=1;. W przypadku interaktywnej pracy z bazą (czyli ktoś klika na stronie, zapytanie idzie do bazy a w tym czasie użytkownik czeka na wynik) jedna sekunda to takie minimum przyzwoitości. Jeśli konieczne jest dłuższe oczekiwanie, użytkownik zacznie się frustrować. Zazwyczaj takie ustawienie logowania wystarczy, aby wyłapać te zapytania, które są nieoptymalne i które są przyczyną dużego obciążenia CPU czy dysku. Problem pojawia się jednak wtedy, gdy w slowlogu niczego podejrzanego nie widać. Oczywiście, rozwiązaniem jest włączenie logowania wszystkich zapytań – ustawiamy zmienną long_query_time na 0. W ten sposób wszystkie zapytania trafiają do slowlogów a my liczymy na to, że skoro przyczyną nie jest jedno długie zapytanie, to może będzie to większa liczba szybkich. Niestety, tu mamy kolejny problem. O ile kilkaset zapytań w logu możemy ręcznie przeglądnąć i przeanalizować, to po włączeniu logowania wszystkich zapytań do logów trafią nawet miliony zapytań dziennie. Tego już nie da się ręcznie przeglądnąć. Tu przydaje się agregator taki jak mk-query-digest.
czytaj dalej…
