Wprowadzenie filozoficzne
Jak wiadomo, istnieją tylko dwie metody rozwiązywania problemów:
- Metoda analizy lub metoda dedukcji lub od ogółu do szczegółu.
- Metoda syntezy lub metoda indukcji lub od szczegółu do ogółu.
Aby rozwiązać problem „poprawy wydajności bazy danych”, może to wyglądać tak.
Analiza — analizujemy problem na osobne części i rozwiązując je staramy się poprawić wydajność bazy danych jako całości.
W praktyce analiza wygląda mniej więcej tak:
- Wystąpił problem (incydent związany z wydajnością)
- Zbieranie informacji statystycznych o stanie bazy danych
- Szukasz wąskich gardeł
- Rozwiązujemy problemy z wąskich gardeł
Wąskie gardła w bazach danych — infrastruktura (CPU, pamięć, dyski, sieć, system operacyjny), ustawienia (postgresql.conf), zapytania:
Infrastruktura: Możliwości wpływu i zmiany dla inżyniera są prawie zerowe.
Ustawienia bazy danych: możliwości zmian są nieco większe niż w poprzednim przypadku, ale z reguły nadal są dość trudne, szczególnie w chmurach.
wnioski do bazy danych: jedyne pole manewru.
Synteza — poprawiamy wydajność poszczególnych części, oczekując, że w rezultacie poprawi się wydajność bazy danych.
Wprowadzenie liryczne, czyli dlaczego to wszystko jest konieczne
Jaki jest proces rozwiązywania incydentów związanych z wydajnością, jeśli wydajność bazy danych nie jest monitorowana:
Klient - „wszystko z nami jest źle, to trwa za długo, zrób dla nas coś dobrego”
Inżynier - „Jak źle jest?”
Klient – „tak jest teraz (godzinę temu, wczoraj, ostatni raz), powoli”
Inżynier - „kiedy było dobrze?”
Klient – „tydzień (dwa tygodnie) temu nie było źle. „(To szczęście)
Klient - „Nie pamiętam kiedy było dobrze, ale teraz jest źle” (zwykła odpowiedź)
Rezultatem jest klasyczny obraz:
Kto jest winien i co robić?
Odpowiedź na pierwszą część pytania jest najłatwiejsza – zawsze winny jest inżynier DBA.
Odpowiedź na drugą część również nie jest zbyt trudna - należy wdrożyć system monitorowania wydajności bazy danych.
Powstaje pierwsze pytanie – co monitorować?
Ścieżka 1. Będziemy WSZYSTKO monitorować
Obciążenie procesora, liczba operacji odczytu/zapisu na dysku, rozmiar przydzielonej pamięci i kolejna megatona różnych liczników, które może zapewnić każdy mniej lub bardziej działający system monitorowania.
Rezultatem jest masa wykresów, tabel przestawnych i ciągłe powiadomienia e-mailowe oraz w 100% zajęty inżynier rozwiązujący kilka identycznych zgłoszeń, jednak z reguły o standardowym brzmieniu – „Problem tymczasowy. Żadne działania nie są potrzebne.” Ale wszyscy są zajęci i zawsze jest coś do pokazania klientowi - praca idzie pełną parą.
Sposób 2. Monitoruj tylko to, co jest potrzebne, a to, co nie jest potrzebne, nie wymaga monitorowania
Możesz monitorować, trochę inaczej, tylko podmioty i zdarzenia:
- Na który inżynier DBA może mieć wpływ
- Dla których istnieje algorytm postępowania w przypadku wystąpienia zdarzenia lub zmiany podmiotu.
Opierając się na tym założeniu i pamiętając”Wprowadzenie filozoficzne„aby uniknąć regularnych powtórzeń”Wprowadzenie liryczne, czyli dlaczego to wszystko jest konieczne„Warto byłoby monitorować wydajność poszczególnych zapytań w celu optymalizacji i analizy, co w efekcie powinno przełożyć się na poprawę wydajności całej bazy danych.
Aby jednak ulepszyć ciężkie zapytanie, które wpływa na ogólną wydajność bazy danych, należy je najpierw znaleźć.
Pojawiają się zatem dwa powiązane ze sobą pytania:
- które żądanie jest uważane za trudne
- jak wyszukiwać trudne zapytania.
Oczywiście trudne zapytanie to zapytanie, które wymaga dużej ilości zasobów systemu operacyjnego w celu uzyskania wyniku.
Przejdźmy do drugiego pytania - jak wyszukiwać, a następnie monitorować ciężkie zapytania?
Jakie możliwości monitorowania zapytań ma PostgreSQL?
W porównaniu z Oracle możliwości jest niewiele, ale mimo to można coś zrobić.
PG_STAT_STATEMENTS
Standardowe rozszerzenie pg_stat_statements służy do wyszukiwania i monitorowania ciężkich zapytań w PostgreSQL.
Po zainstalowaniu rozszerzenia w docelowej bazie danych pojawia się widok o tej samej nazwie, który należy wykorzystać do celów monitorowania.
Docelowe kolumny pg_stat_statements do budowy systemu monitorowania:
- kwerenda Wewnętrzny kod skrótu obliczony na podstawie drzewa analizy operatora
- maksymalny_czas Maksymalny czas spędzony na wyciągu w milisekundach
Gromadząc i wykorzystując statystyki z tych dwóch kolumn, można zbudować system monitorowania.
Jak pg_stat_statements jest używane do monitorowania wydajności PostgreSQL
Aby monitorować wydajność zapytań, użyj:
Po stronie docelowej bazy danych - widok pg_stat_statements
Z boku serwer i monitorowania baz danych - zestawu skryptów bash i tabel usług.
Etap 1 – zbieranie danych statystycznych
Na hoście monitorującym cron regularnie uruchamiany jest skrypt, który kopiuje zawartość widoku pg_stat_statements z docelowej bazy danych do tabeli pg_stat_history w bazie danych monitorowania.
Tworzy to historię poszczególnych wykonań zapytań, która może służyć do generowania raportów wydajności i konfigurowania metryk.
Etap 2 – ustawienie wskaźników wydajności
Na podstawie zebranych danych wybieramy zapytania, których realizacja jest najważniejsza/ważna dla Klienta (aplikacji). W porozumieniu z klientem wartości wskaźników wydajnościowych ustalamy za pomocą pól queryid i max_time.
Wynik - rozpoczęcie monitorowania wydajności
- Po uruchomieniu skrypt monitorujący sprawdza skonfigurowane metryki wydajności, porównując wartość max_time metryki z wartością z widoku pg_stat_statements w docelowej bazie danych.
- Jeżeli wartość w docelowej bazie danych przekroczy wartość metryki, generowane jest ostrzeżenie (incydent w systemie biletowym)
Opcja dodatkowa 1
Historia planu zapytań
Aby później ułatwić rozwiązywanie problemów z wydajnością, warto mieć historię zmian planów wykonywania zapytań.
Tabela usług log_query służy do przechowywania historii. Tabela jest wypełniana podczas analizy załadowanego pliku dziennika PostgreSQL. Ponieważ plik logu w przeciwieństwie do widoku pg_stat_statements zawiera pełny tekst z wartościami parametrów wykonania, a nie tekst znormalizowany, możliwe jest rejestrowanie nie tylko czasu i czasu trwania żądań, ale także przechowywanie planów wykonania na bieżąco czas.
Opcja dodatkowa 2
Proces ciągłego doskonalenia wydajności
Monitorowanie poszczególnych zapytań w ogóle nie ma na celu rozwiązania problemu ciągłego doskonalenia wydajności bazy danych jako całości, ponieważ monitoruje i rozwiązuje problemy wydajnościowe tylko dla poszczególnych zapytań. Można jednak rozszerzyć metodę i skonfigurować zapytania monitorujące dla wszystkich baz danych.
Aby to zrobić, musisz wprowadzić dodatkowe wskaźniki wydajności:
- Na ostatnie dni
- Na okres bazowy
Skrypt wybiera zapytania z widoku pg_stat_statements w docelowej bazie danych i porównuje wartość max_time ze średnią wartością max_time w pierwszym przypadku za ostatnie dni lub za wybrany okres czasu (bazowy) w drugim przypadku.
Dlatego w przypadku pogorszenia wydajności dowolnego żądania ostrzeżenie zostanie wygenerowane automatycznie, bez ręcznej analizy raportów.
Co ma z tym wspólnego synteza?
W opisywanym podejściu, jak sugeruje metoda syntezy, ulepszając poszczególne części systemu, ulepszamy system jako całość.
- Zapytanie wykonane przez bazę danych – streszczenie
- Zmodyfikowany wniosek - antyteza
- Zmiana stanu układu - synteza
Rozwój systemu
- Rozszerzenie zbieranych statystyk o dodanie historii dla widoku systemu pg_stat_activity
- Rozszerzanie gromadzonych statystyk o dodanie historii statystyk poszczególnych tabel biorących udział w zapytaniach
- Integracja z systemem monitorowania chmury AWS
- A jednak można coś wymyślić...
Źródło: www.habr.com
