Skuteczne monitorowanie MySQL za pomocą pulpitów nawigacyjnych SCUMM:część 3

W poprzednich blogach omawialiśmy pulpity nawigacyjne związane z MySQL. Podkreśliliśmy zalety, z których administrator baz danych może skorzystać, analizując wykresy, zwłaszcza podczas wykonywania codziennych czynności związanych z diagnostyką, raportowaniem wskaźników i planowaniem wydajności. W tym blogu omówimy metryki InnoDB i schemat wydajności MySQL, który jest bardzo ważny, szczególnie przy monitorowaniu transakcji InnoDB, we/wy dysku/procesora/pamięci, optymalizacji zapytań lub dostrajaniu wydajności serwera.

Ten blog porusza głęboki temat wydajności, biorąc pod uwagę, że InnoDB wymagałoby obszernego omówienia, jeśli zajmiemy się jego wewnętrznymi elementami. Schemat wydajności jest również obszerny, ponieważ obejmuje jądro i podstawowe części MySQL oraz silników pamięci masowej.

Zacznijmy przeglądać wykresy.

Wskaźniki MySQL InnoDB

Ten pulpit nawigacyjny jest świetny dla każdego administratora bazy danych MySQL lub operatora, ponieważ zapewnia bardzo dobry wgląd w silnik pamięci masowej InnoDB. Istnieją tutaj pewne wykresy, które użytkownik musi rozważyć, aby włączyć, ponieważ nie we wszystkich sytuacjach zmienne są ustawione poprawnie w konfiguracji MySQL.

• Wiek punktu kontrolnego Innodb

  Zgodnie z instrukcją, punkt kontrolny jest zdefiniowany w następujący sposób:„W miarę wprowadzania zmian na stronach danych, które są buforowane w puli buforów , te zmiany są zapisywane w plikach danych jakiś czas później proces znany jako płukanie . Punkt kontrolny to zapis ostatnich zmian (reprezentowany przez LSN wartość), które zostały pomyślnie zapisane w plikach danych ”. Ten wykres jest przydatny, gdy chcesz określić, w jaki sposób serwer wykonuje sprawdzanie danych na dysku. Może to być dobre odniesienie, jeśli dziennik transakcji (log ponawiania lub ib_logfile0) jest zbyt duży. Ten wykres jest również dobrym wskaźnikiem, jeśli musisz dostosować zmienne, takie jak innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct lub innodb_adaptive_flushing_method. Im bliżej wieku punktu kontrolnego jest maksymalny wiek punktu kontrolnego, tym bardziej wypełnione są dzienniki, a InnoDB będzie wykonywać więcej operacji we/wy, aby zachować trochę wolnego miejsca w dziennikach. Mechanizm sprawdzania różni się w subtelnych szczegółach między smakami opartymi na Percona XtraDB, MariaDB i wersją Oracle, można również znaleźć różnice w jego implementacji między wersjami MySQL.

• Transakcje InnoDB

  Ilekroć na Twoim serwerze MySQL odbywa się duża transakcja, ten wykres jest dobrym odniesieniem. Liczy transakcje, które zostały utworzone w określonym czasie, a długość historii (a właściwie długość listy historii znaleziona w SHOW ENGINE INNODB STATUS) to liczba stron w dzienniku cofania. Trendy, które tu zobaczysz, są dobrym źródłem informacji, aby sprawdzić, czy może to oznaczać, na przykład, że czyszczenie jest opóźnione z powodu bardzo wysokiej szybkości wstawiania ponownego ładowania danych lub z powodu długotrwałej transakcji, lub czy czyszczenie po prostu może nie nadążaj z powodu wysokiego dysku I/O w wolumenie, w którym znajduje się Twój $DATADIR.

• Operacje na wierszach Innodb

  W przypadku niektórych zadań DBA możesz chcieć określić liczbę operacji usunięcia, wstawienia, odczytów i zaktualizowanych wierszy. Następnie ten wykres jest tym, czego możesz użyć, aby to sprawdzić.

• Czas blokady wiersza Innodb

  Ten wykres jest dobrym źródłem informacji, gdy zauważysz, że Twoja aplikacja napotyka wiele wystąpień „Przekroczono limit czasu oczekiwania na blokadę; spróbuj ponownie uruchomić transakcję ”. Może to również pomóc w ustaleniu, czy możesz mieć wskazówkę do używania złych zapytań dotyczących obsługi blokad. Jest to również dobre odniesienie do optymalizacji zapytań, która obejmuje blokowanie wierszy. Jeśli czas oczekiwania jest zbyt długi, musisz sprawdzić dziennik powolnych zapytań lub uruchomić pt-query-digest i zobaczyć, jakie podejrzane zapytania powodują to rozdęcie na wykresie.

  

• We/Wy InnoDB

  Ilekroć chcesz określić ilość odczytów danych InnoDB, opróżnień dysku, zapisów i zapisów dziennika, ten wykres ma to, na co powinieneś zwrócić uwagę. Możesz użyć tego wykresu, aby określić, czy zmienne InnoDB są dobrze dostrojone do obsługi określonych wymagań. Na przykład, jeśli masz pamięć podręczną Battery Backup Module, ale nie zyskujesz zbyt wiele z jego optymalnej wydajności, możesz polegać na tym wykresie, aby określić, czy twoje fsyncs() są wyższe niż oczekiwano. Następnie zmiana zmiennej innodb_flush_method i użycie O_DSYNC może rozwiązać problem.

• Godzinowe wykorzystanie pliku dziennika InnoDB

  Ten wykres pokazuje tylko liczbę bajtów zapisanych w plikach dziennika przeróbek InnoDB oraz wzrost plików dziennika InnoDB w oparciu o 24-godzinny zakres czasu bieżącej daty.

• Wydajność rejestrowania InnoDB

  Ten wykres jest ściśle powiązany z wykresem godzinowym użycia pliku dziennika InnoDB. Musisz użyć tego wykresu, gdy chcesz określić, jak duży powinien być rozmiar pliku innodb_log_file_size. Możesz określić liczbę bajtów zapisywanych w plikach dziennika przeróbek InnoDB i jak skutecznie twój MySQL opróżnia dane z pamięci na dysk. Za każdym razem, gdy brakuje Ci czasu na użycie przestrzeni dziennika przeróbek, oznaczałoby to, że musisz zwiększyć rozmiar pliku innodb_log_file. W takim przypadku ten wykres powie ci, że musisz to zrobić. Jednak, aby zagłębić się bardziej w to, ile potrzebujesz dla swojego pliku innodb_log_file, bardziej sensowne może być sprawdzenie LSN (numer sekwencji dziennika) w SHOW ENGINE INNODB STATUS. Percona ma dobry blog na ten temat, który jest dobrym źródłem do obejrzenia.

• Zakleszczenia w InnoDB

  W pewnych sytuacjach, gdy klient aplikacji często doświadcza zakleszczeń lub gdy musisz sprawdzić, jak bardzo Twój MySQL doświadcza zakleszczeń, ten wykres służy temu celowi. Zakleszczenia wskazują, że masz kiepski projekt SQL, co prowadzi do tego, że Twoje transakcje powodują wyścig i zakleszczenia.

• Przesunięcie w dół warunku indeksu

  Trochę ostrzeżenia, patrząc na ten wykres. Najpierw musisz ustalić, czy twoja zmienna globalna MySQL innodb_monitor_enable ma ustawioną poprawną wartość, czyli module_icp. W przeciwnym razie zobaczysz komunikat „Brak punktów danych”, jak pokazano poniżej:

  

  Cel wykresu, jeśli punkty danych są zdefiniowane jako te, które mam w przykładowych danych wyjściowych, zapewni administratorowi baz danych przeoczenie, jak dobrze Twoje zapytania korzystają z funkcji Index Condition Pushdown lub w skrócie ICP. ICP to świetna funkcja w MySQL, która oferuje optymalizację zapytań. Zamiast odczytywania przez MySQL pełnych wierszy przefiltrowanych w zapytaniach WHERE po pobraniu, doda więcej kontroli po indeksach pomocniczych. Zwiększa to szczegółowość i oszczędza czas, w przeciwnym razie aparat musi odczytywać wiersze pełnej tabeli, gdy opiera się tylko na filtrowanym indeksie i nie jest używany ICP. Pozwala to uniknąć czytania pełnych wierszy odpowiadających krotkom indeksu, które pasują do indeksów dodatkowych.

  Pozwólcie, że omówię nieco ten wykres, powiedzmy, że mam tabelę o nazwie:

  mysql> show create table a\G
  *************************** 1. row ***************************
         Table: a
  Create Table: CREATE TABLE `a` (
    `id` int(11) NOT NULL,
    `age` int(11) NOT NULL,
    KEY `id` (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  1 row in set (0.00 sec)

  I ma kilka małych danych:

  mysql> select * from a;
  +----+-----+
  | id | age |
  +----+-----+
  |  1 |   1 |
  |  2 |   1 |
  |  3 |   1 |
  |  3 |  41 |
  |  4 |  41 |
  |  5 |   4 |
  |  4 |   4 |
  |  4 |   4 |
  +----+-----+
  8 rows in set (0.00 sec)

  Gdy ICP jest włączony, wyniki są bardziej wydajne i wykonalne:

  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  1 row in set, 2 warnings (0.00 sec)

  Niż bez ICP,

  mysql> set optimizer_switch='index_condition_pushdown=off';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  1 row in set, 2 warnings (0.00 sec)

  To jest prosty przykład ICP i jak ten wykres może przynieść korzyści administratorowi.

  

• Zawartość puli buforów InnoDB

  Podczas pracy z MySQL i korzystania z silnika InnoDB ten wykres jest jedną z najczęstszych wartości (innodb_buffer_pool*), którą należy dostroić, aby zoptymalizować wydajność MySQL. Mówiąc konkretnie na temat zawartości puli buforów, wyświetla trendy dotyczące zabrudzonych stron w stosunku do całkowitej zawartości puli buforów. Całkowita zawartość puli buforów obejmuje czyste strony oprócz stron brudnych. Ten wykres służy do określania, jak wydajnie Twój MySQL obsługuje pulę buforów.

• Strony puli buforów InnoDB

  Ten wykres jest pomocny, gdy chcesz sprawdzić, jak wydajnie MySQL wykorzystuje Twoją pulę buforów InnoDB. Możesz użyć tego wykresu, na przykład, jeśli Twój dzienny ruch nie wypełnia przypisanej wartości innodb_buffer_pool_size, może to oznaczać, że niektóre części aplikacji nie są przydatne lub nie służą żadnemu celowi lub jeśli ustawisz wartość innodb_buffer_pool_size na bardzo wysoką co może być dobre, aby obniżyć wartość i odzyskać miejsce w pamięci.

• We/wy puli buforów InnoDB

  Gdy musisz sprawdzić liczbę stron utworzonych i zapisanych w tabelach InnoDB lub odczytanych stron do puli buforów InnoDB przez operacje na tabelach InnoDB.

• Żądania puli buforów InnoDB

  Ten wykres służy temu, gdy chcesz określić, jak wydajnie Twoje zapytania uzyskują dostęp do puli buforów InnoDB. Ten wykres pokaże trendy w oparciu o punkty danych, jak działa twój serwer MySQL, gdy silnik InnoDB musi często uzyskiwać dostęp do dysku (wskazanie, że pula buforów jeszcze się nie rozgrzała), jak często żądania puli buforów obsługiwały żądania odczytu i zapisu prośby.

• Odczyt z wyprzedzeniem InnoDB

  Gdy zmienna innodb_random_read_ahead jest ustawiona na ON, dodaj ten wykres jako wartościowy trend, który należy traktować jako część procedury DBA. Pokazuje trendy dotyczące tego, w jaki sposób silnik pamięci masowej MySQL InnoDB zarządza pulą buforów za pomocą wątku odczytu z wyprzedzeniem w tle, jak zarządza tymi, które zostały następnie wykluczone bez dostępu do zapytań, oraz w jaki sposób InnoDB inicjuje losowy odczyt z wyprzedzeniem podczas skanowania zapytania duża część stołu, ale w losowej kolejności.

  

• Bufor zmian InnoDB

  Gdy masz uruchomiony Percona Server 5.7, ten wykres jest przydatny podczas monitorowania, jak dobrze InnoDB przydzielił buforowanie zmian. Te zmiany obejmują wstawienia, aktualizacje i usunięcia, które są określone przez zmienną innodb_change_buffering. Buforowanie zmian pomaga przyspieszyć zapytania, unikając znacznych operacji we/wy o dostępie swobodnym, które byłyby wymagane do wczytania stron indeksu wtórnego z dysku.

• Aktywność bufora zmian InnoDB

  Jest to związane z wykresem bufora zmian InnoDB, ale dzieli informacje na bardziej opłacalne punkty danych. Zapewniają one więcej informacji do monitorowania, jak InnoDB obsługuje buforowanie zmian. Jest to przydatne w konkretnym zadaniu DBA, aby określić, czy innodb_change_buffer_max_size ma ustawioną zbyt wysoką wartość, ponieważ buforowanie zmian współdzieli tę samą pamięć z pulą buforów InnoDB, zmniejszając ilość pamięci dostępnej dla stron danych w pamięci podręcznej. Być może trzeba będzie rozważyć wyłączenie buforowania zmian, jeśli zestaw roboczy prawie mieści się w puli buforów lub jeśli tabele mają stosunkowo niewiele indeksów pomocniczych. Pamiętaj, że buforowanie zmian nie powoduje dodatkowego obciążenia, ponieważ dotyczy tylko stron, które nie znajdują się w puli buforów. Ten wykres jest również przydatny, jeśli musisz określić, jak przydatne są scalania, jeśli musisz przetestować swoją aplikację na podstawie określonych żądań w określonych scenariuszach. Załóżmy, że masz wstawki zbiorcze, musisz ustawić innodb_change_buffering=insert i określić, czy wartości ustawione w puli buforów i innodb_change_buffer_max_size nie wpływają na we/wy dysku, szczególnie podczas odzyskiwania lub powolnego zamykania (konieczne, jeśli chcesz wykonać przełączanie awaryjne z niskimi wymaganiami dotyczącymi przestojów). Ponadto ten wykres może służyć do oceny niektórych scenariuszy, ponieważ scalanie bufora zmian może zająć kilka godzin, gdy istnieje wiele indeksów pomocniczych do zaktualizowania i wiele wierszy, których to dotyczy. W tym czasie zwiększane jest we/wy dysku, co może spowodować znaczne spowolnienie zapytań związanych z dyskami.

Schemat wydajności MySQL

Schemat wydajności MySQL to skomplikowany temat. To długa i trudna, ale zamierzam omówić tylko informacje, które są specyficzne dla wykresów, które mamy w SCUMM. Istnieją również pewne zmienne, które należy wziąć pod uwagę i upewnić się, że są ustawione prawidłowo. Upewnij się, że masz zmienną innodb_monitor_enable =all i userstat=1, aby zobaczyć punkty danych na wykresach. Dla przypomnienia, kiedy używam tutaj słowa „zdarzenie”, nie oznacza to, że jest to związane z harmonogramem zdarzeń MySQL. Mówię o konkretnych zdarzeniach, takich jak MySQL analizuje zapytanie, MySQL odczytuje lub zapisuje do pliku dziennika przekaźnika/binarnego itp.

Przejdźmy zatem do wykresów.

• Plik ze schematem wydajności IO (zdarzenia)

  Ten wykres pobiera punkty danych związane ze wszystkimi zdarzeniami, które wystąpiły w MySQL, które mogły być instrumentowane w celu utworzenia wielu wystąpień instrumentowanego obiektu (np. odczyty dzienników binarnych lub odczyty plików danych InnoDB). Każdy wiersz zawiera podsumowanie wydarzeń dla danej nazwy wydarzenia. Na przykład, jeśli istnieje instrument dla obiektu mutex, który jest tworzony dla każdego połączenia, może istnieć wiele wystąpień tego oprzyrządowanego zdarzenia, ponieważ istnieje wiele połączeń. Wiersz podsumowania instrumentu podsumowuje wszystkie te przypadki. Możesz sprawdzić te zdarzenia w podręczniku MySQL, aby uzyskać więcej informacji.

• Wydajność pliku we/wy (ładowanie)

  Ten wykres jest taki sam jak wykres „Performance Schema File IO (Events)”, z wyjątkiem tego, że jest oprzyrządowany na podstawie obciążenia.

• Plik we/wy pliku schematu wydajności (bajty)

  Ten wykres jest taki sam jak wykres „Wydajność we/wy pliku schematu wydajności (zdarzenia)”, z wyjątkiem tego, że jest oprzyrządowany na podstawie rozmiaru w bajtach. Na przykład, ile czasu zajęło określone zdarzenie, gdy MySQL wywołało zdarzenie wait/io/file/innodb/innodb_data_file.

• Schemat wydajności czeka (zdarzenia)

  Ten wykres zawiera wykres danych dla wszystkich czasów oczekiwania spędzonych na określonym wydarzeniu. Możesz sprawdzić tabele podsumowania zdarzeń oczekiwania w instrukcji, aby uzyskać więcej informacji.

  

• Schemat wydajności czeka (załadowanie)

  Taki sam jak wykres „Schemat wydajności czeka (zdarzenia)”, ale tym razem pokazuje trendy obciążenia.

• Operacje dostępu do indeksu (ładowanie)

  Ten wykres jest agregacją wszystkich zdarzeń oczekiwania we/wy indeksu tabeli pogrupowanych według indeksów tabeli, wygenerowanych przez instrument wait/io/table/sql/handler. Więcej informacji można znaleźć w instrukcji MySQL o tabeli schematów wydajności table_io_waits_summary_by_index_usage.

• Operacje dostępu do tabeli (ładowanie)

  Wykres „Taki sam jak operacje dostępu do indeksu (obciążenie)”, jest to agregacja wszystkich zdarzeń oczekiwania we/wy tabeli pogrupowanych według tabeli, wygenerowanych przez instrument wait/io/table/sql/handler. Jest to bardzo przydatne dla administratorów baz danych. Na przykład chcesz prześledzić, jak szybko zajmuje dostęp (pobieranie) lub aktualizacja (wstawianie, usuwanie, aktualizacja) określonej tabeli. Więcej informacji znajdziesz w instrukcji MySQL o tabeli schematów wydajności table_io_waits_summary_by_table.

  

• Schemat wydajności SQL i blokady zewnętrzne (zdarzenia)

  Ten wykres jest agregacją (liczba, ile razy wystąpił) wszystkich zdarzeń oczekiwania na blokadę tabeli, wygenerowanych przez instrument wait/lock/table/sql/handler, który jest pogrupowany według tabeli. Blokada SQL tutaj na wykresie oznacza blokady wewnętrzne. Te wewnętrzne blokady to normalny odczyt, odczyt ze współdzielonymi blokadami, odczyt o wysokim priorytecie, odczyt bez wstawiania, zapis zezwalający na zapis, współbieżny zapis wstawiania, zapis opóźniony, zapis o niskim priorytecie, zapis normalny. Podczas gdy zewnętrzne zamki są odczytywane zewnętrzne i pisane zewnętrzne. W każdym zadaniu DBA jest to bardzo przydatne, jeśli musisz śledzić i badać blokady w określonej tabeli, niezależnie od jej typu. Możesz sprawdzić tabelę table_lock_waits_summary_by_table, aby uzyskać więcej informacji.

• Schemat wydajności SQL i blokady zewnętrzne (sekundy)

  Taki sam jak wykres „Schemat wydajności SQL i blokady zewnętrzne (zdarzenia)”, ale określony w sekundach. Jeśli chcesz poszukać blokad w tabeli na podstawie sekund, w których były one utrzymywane, ten wykres jest dobrym źródłem informacji.

Wniosek

Metryki InnoDB i schemat wydajności MySQL to jedne z najbardziej dogłębnych i skomplikowanych części w domenie MySQL, zwłaszcza gdy nie ma wizualizacji wspomagającej interpretację. Dlatego przejście do ręcznego śledzenia i dochodzenia może zająć trochę czasu i ciężkiej pracy. Pulpity nawigacyjne SCUMM oferują bardzo wydajny i wykonalny sposób radzenia sobie z nimi i zmniejszają dodatkowe obciążenie każdego rutynowego zadania DBA.

W tym blogu dowiedziałeś się, jak używać pulpitów nawigacyjnych dla InnoDB i Performance Schema do poprawy wydajności bazy danych. Te pulpity nawigacyjne mogą zwiększyć wydajność analizowania wydajności.