Proaktywne spostrzeżenia z Amazon DevOps Guru dla RDS

Przedstawiamy nowego guru Amazon DevOps w zakresie funkcji RDS: Proactive Insights. DevOps Guru for RDS to w pełni zarządzana usługa oparta na uczeniu maszynowym (ML), która wykorzystuje dane zebrane przez RDS Performance Insights do wykrywania i ostrzegania klientów o nietypowych zachowaniach w bazach danych Amazon Aurora. Od momentu wydania DevOps Guru for RDS zapewnia klientom informacje umożliwiające szybkie reagowanie na problemy z wydajnością i podejmowanie działań naprawczych. Teraz Proactive Insights dodaje zalecenia dotyczące problemów operacyjnych, które mogą zapobiec potencjalnym problemom w przyszłości.

Proactive Insights nie wymaga dodatkowej konfiguracji dla klientów, którzy już korzystają z DevOps Guru dla RDS, zarówno dla Amazon Aurora MySQL-Compatible Edition, jak i Amazon Aurora PostgreSQL-Compatible Edition.

Poniżej przedstawiono przykładowe przypadki użycia problemów operacyjnych dostępnych obecnie dla Proactive Insights, a z czasem pojawi się więcej spostrzeżeń i przemyśleń:

• Long InnoDB History for Aurora MySQL-Compatible engines – uruchamiana, gdy długość listy historii InnoDB staje się bardzo duża.
• Temporary tables created on disk for Aurora MySQL-Compatible engines – wyzwalane, gdy stosunek utworzonych tabel tymczasowych do wszystkich tabel tymczasowych przekracza próg.
• Idle In Transaction for Aurora PostgreSQL-Compatible engines – wyzwalana, gdy sesje połączone z bazą danych nie wykonują aktywnej pracy, ale mogą blokować zasoby bazy danych.

Aby rozpocząć, przejdź do pulpitu Amazon DevOps Guru Dashboard, gdzie możesz zobaczyć podsumowanie ogólnego stanu systemu, w tym bieżące proaktywne spostrzeżenia. Na poniższym zrzucie ekranu liczba trzy wskazuje, że istnieją trzy bieżące proaktywne spostrzeżenia. Wybierz ten numer, aby zobaczyć listę odpowiednich Proaktywnych Insights, które mogą obejmować RDS lub inne Proactive Insights obsługiwane przez Amazon DevOps Guru.

Bieżące problemy (w tym reaktywne i proaktywne spostrzeżenia) są również wyróżnione w Twojej instancji bazy danych na stronie listy Baza danych w konsoli Amazon RDS.

W poniższych sekcjach autorzy szczegółowo omówią przypadki użycia DevOps Guru dla RDS Proactive Insights.

Long InnoDB History for Aurora MySQL-Compatible engines

Lista historii InnoDB to globalna lista dzienników cofnięć dla zatwierdzonych transakcji. MySQL używa listy historii do czyszczenia rekordów i stron dziennika, gdy transakcje nie wymagają już historii. Jeśli długość listy historii InnoDB stanie się zbyt duża, co wskazuje na dużą liczbę starych wersji wierszy, zapytania, a nawet proces zamykania bazy danych może stać ulec spowolnieniu.

DevOps Guru for RDS wykrywa teraz, kiedy długość listy historii przekracza 1 milion rekordów i ostrzega użytkowników, aby zamknęli (przez zatwierdzenie lub wycofanie) wszelkie niepotrzebne długotrwałe transakcje przed wyzwoleniem zmian w bazie danych, które pociągają za sobą zamknięcie (obejmuje to ponowne uruchomienie i aktualizację wersji bazy danych).

Z konsoli DevOps Guru przejdź do Insights, wybierz Proactive, a następnie wybierz „RDS InnoDB History List Length Anomalous” Proactive Insight ze stanem bieżącym. Zauważysz, że Proactive Insights zapewnia „Przegląd informacji”, „Metryki” i „Rekomendacje”.

Insight overview zawiera podstawowe informacje na temat tego wglądu. W omawianym przypadku znacznie wzrosła lista historii zmian wierszy, co wpływa na wydajność zapytań i zamykania sesji.

Panel Metryki przedstawia graficzną reprezentację długości listy historii i osi czasu, umożliwiając skorelowanie jej z wszelkimi nietypowymi działaniami aplikacji, które mogły wystąpić w tym oknie.

Sekcja Zalecenia sugeruje działania, które można podjąć, aby złagodzić ten problem, zanim doprowadzi on do większego. Można również zauważyć uzasadnienie rekomendacji w części „Dlaczego DevOps Guru to poleca?”.

Tabele tymczasowe utworzone na dysku dla silników zgodnych z Aurora MySQL

Czasami konieczne jest, aby baza danych MySQL podczas przetwarzania zapytania utworzyła wewnętrzną tabelę tymczasową. Wewnętrzna tabela tymczasowa może być przechowywana w pamięci i przetwarzana przez silnik pamięci TempTable, MEMORY lub przechowywana na dysku przez silnik pamięci InnoDB. Zwiększenie liczby tabel tymczasowych tworzonych na dysku zamiast w pamięci może mieć wpływ na wydajność bazy danych.

DevOps Guru for RDS monitoruje teraz szybkość, z jaką baza danych tworzy tabele tymczasowe oraz odsetek tych tabel tymczasowych, które korzystają z dysku. Kiedy te wartości przekraczają zalecane poziomy w danym okresie, DevOps Guru for RDS tworzy wgląd w tę sytuację, zanim stanie się krytyczna.

Z konsoli DevOps Guru przejdź do Insights, wybierz Proactive, a następnie wybierz „RDS Temporary Tables On Disk Anomalous” Proactive Insight ze statusem w toku. Zauważysz, że ten proaktywny wgląd zapewnia „przegląd informacji”, „metryki” i „zalecenia”.

Insight overview zawiera podstawowe informacje na ten temat. W omawianym przypadku ponad 58% wszystkich tabel tymczasowych tworzonych na sekundę korzystało z dysku, przy stałym wskaźniku tworzenia dwóch tabel tymczasowych na dysku co sekundę, co wskazuje na spadek wydajności zapytań.

Panel Metryki przedstawia graficzną reprezentację informacji specyficznych dla tego wglądu. Zobaczysz ewolucję liczby tabel tymczasowych tworzonych na dysku na sekundę, procent tabel tymczasowych na dysku (z całkowitej liczby tabel tymczasowych utworzonych w bazie danych) oraz ogólną szybkość, z jaką tabele tymczasowe są tworzone (na sekundę).

Sekcja Zalecenia sugeruje działania, które pozwolą uniknąć takiej sytuacji, jeśli to oczywiście możliwe, jak rezygnacja z typów danych BLOB i TEXT, dostrajanie parametrów bazy danych tmp_table_size i max_heap_table_size, redukcja zbioru danych, indeksowanie kolumn i inne.

Dodatkowe wyjaśnienia dotyczące tego przypadku użycia można znaleźć, klikając link „Wyświetl dokument dotyczący rozwiązywania problemów”.

Idle In Transaction for Aurora PostgreSQL-Compatible engines

Połączenie, które było bezczynne w transakcji przez zbyt długi czas, może mieć wpływ na wydajność, wstrzymując blokady, blokując inne zapytania lub uniemożliwiając VACUUM (w tym autovacuum) czyszczenia martwych wierszy. Baza danych PostgreSQL wymaga okresowej konserwacji, zwanej „odkurzaniem”. Autovacuum w PostgreSQL automatyzuje wykonywanie poleceń VACUUM i ANALYZE. Ten proces gromadzi statystyki tabeli i usuwa martwe wiersze. Brak odkurzania ma negatywny wpływ na wydajność bazy danych. Prowadzi to do wzrostu obciążenia tabel i indeksów (przestrzeń dyskowa, która była używana przez tabelę lub indeks i jest dostępna do ponownego wykorzystania przez bazę danych, ale nie została odzyskana), prowadzi do nieaktualnych statystyk, a nawet może zakończyć się obejściem transakcji (kiedy liczba unikalnych identyfikatorów transakcji osiąga maksimum około dwóch miliardów).

DevOps Guru for RDS monitoruje czas spędzony przez sesje w bazie danych Aurora PostgreSQL w stanie bezczynności w stanie transakcji i początkowo generuje powiadomienie ostrzegawcze, a następnie powiadomienie alarmowe, jeśli stan bezczynności w stanie transakcji trwa nadal (obecne progi to 1800 sekund dla ostrzeżenia i 3600 sekund dla alarmu).

Z konsoli DevOps Guru przejdź do Insights, wybierz Proactive, a następnie wybierz „RDS Idle In Transaction Max Time Anomalous” Proactive Insight ze statusem w toku. Zauważysz, że Proactive Insights zapewnia „Przegląd informacji”, „Metryki” i „Rekomendacje”.

W Twoim przypadku połączenie było w stanie „bezczynne w transakcji” przez ponad 1800 sekund, co mogło wpłynąć na wydajność bazy danych.

Panel Metrics pokazuje graficzną reprezentację czasu rozpoczęcia długotrwałych połączeń „bezczynnych w transakcji”.

Podobnie jak w przypadku innych spostrzeżeń, wymieniono zalecane działania i podano łącze do dokumentu dotyczącego rozwiązywania problemów, aby uzyskać jeszcze więcej informacji na temat tego przypadku użycia.

Wnioski

Dzięki Proactive Insights, DevOpsGuru for RDS zwiększa swoje możliwości, aby pomóc Ci monitorować Twoje bazy danych, powiadamiając Cię o potencjalnych problemach operacyjnych, zanim staną się one bardziej zaawansowane w przyszłości. Aby rozpocząć, musisz upewnić się, że włączyłeś Performance Insights w instancjach bazy danych, które chcesz monitorować, a także upewnić się i potwierdzić, że DevOps Guru może monitorować te instancje (na przykład poprzez włączenie jej na poziomie konta, poprzez monitorowanie określonych stosów CloudFormation lub użycie tagów AWS dla określonych zasobów Aurora). Usługa Proactive Insights jest dostępna we wszystkich regionach, w których obsługiwana jest usługa DevOps Guru for RDS. Aby dowiedzieć się więcej o Proactive Insights, dołącz do twórców AWS w dniu 15 marca lub 12 kwietnia podczas bezpłatnego praktycznego dnia zanurzenia (dostępnego w trzech strefach czasowych).

Źródło: AWS