Monitorowanie wydajności przy użyciu magazynu zapytań
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Funkcja magazynu zapytań na serwerze elastycznym usługi Azure Database for PostgreSQL umożliwia śledzenie wydajności zapytań w czasie. Magazyn zapytań upraszcza rozwiązywanie problemów z wydajnością, pomagając szybko znaleźć najdłużej działające i najwięcej zapytań intensywnie korzystających z zasobów. Magazyn zapytań automatycznie przechwytuje historię zapytań i statystyk środowiska uruchomieniowego i zachowuje je do przeglądu. Wycinekuje dane według czasu, aby można było zobaczyć wzorce użycia czasowego. Dane dla wszystkich użytkowników, baz danych i zapytań są przechowywane w bazie danych o nazwie azure_sys w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL.
Ważne
Nie należy modyfikować bazy danych azure_sys ani jej schematu. Uniemożliwi to prawidłowe działanie magazynu zapytań i powiązanych funkcji wydajności.
Włączanie magazynu zapytań
Magazyn zapytań jest dostępny we wszystkich regionach bez dodatkowych opłat. Jest to funkcja zgody, więc nie jest domyślnie włączona na serwerze. Magazyn zapytań można włączyć lub wyłączyć globalnie dla wszystkich baz danych na danym serwerze i nie można włączyć ani wyłączyć dla każdej bazy danych.
Ważne
Nie należy włączać magazynu zapytań w warstwie cenowej z możliwością zwiększenia szybkości, ponieważ spowodowałoby to wpływ na wydajność.
Włączanie magazynu zapytań w witrynie Azure Portal
- Zaloguj się do witryny Azure Portal i wybierz wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL.
- Wybierz pozycję Parametry serwera w sekcji Ustawienia menu.
pg_qs.query_capture_modeWyszukaj parametr .- Ustaw wartość na
TOPlubALL, w zależności od tego, czy chcesz śledzić zapytania najwyższego poziomu, czy też zagnieżdżone zapytania (wykonywane wewnątrz funkcji lub procedury), a następnie kliknij przycisk Zapisz. Poczekaj do 20 minut na utrwalenie pierwszej partii danych w bazie danych azure_sys.
Włączanie próbkowania oczekiwania magazynu zapytań
pgms_wait_sampling.query_capture_modeWyszukaj parametr .- Ustaw wartość na
ALLi Zapisz.
Informacje w magazynie zapytań
Magazyn zapytań składa się z dwóch magazynów:
- Magazyn statystyk środowiska uruchomieniowego do utrwalania informacji dotyczących statystyk wykonywania zapytań.
- Magazyn statystyk oczekiwania na utrwalanie informacji statystycznych dotyczących oczekiwania.
Typowe scenariusze korzystania z magazynu zapytań obejmują:
- Określenie, ile razy zapytanie zostało wykonane w danym przedziale czasu.
- Porównanie średniego czasu wykonywania zapytania w oknach czasu w celu wyświetlenia dużych różnic.
- Identyfikowanie najdłużej uruchomionych zapytań w ciągu ostatnich kilku godzin.
- Identyfikowanie pierwszych N zapytań oczekujących na zasoby.
- Zrozumienie natury oczekiwania dla określonego zapytania.
Aby zminimalizować użycie miejsca, statystyki wykonywania środowiska uruchomieniowego w magazynie statystyk środowiska uruchomieniowego są agregowane w stałym, konfigurowalnym przedziale czasu. Informacje w tych magazynach można wykonywać przy użyciu widoków.
Uzyskiwanie dostępu do informacji o magazynie zapytań
Dane magazynu zapytań są przechowywane w bazie danych azure_sys w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL. Następujące zapytanie zwraca informacje o zapytaniach w magazynie zapytań:
SELECT * FROM query_store.qs_view;
Lub to zapytanie dotyczące statystyk oczekiwania:
SELECT * FROM query_store.pgms_wait_sampling_view;
Znajdowanie zapytań oczekiwania
Typy zdarzeń oczekiwania łączą różne zdarzenia oczekiwania w zasobniki według podobieństwa. Magazyn zapytań udostępnia typ zdarzenia oczekiwania, konkretną nazwę zdarzenia oczekiwania i pytanie. Możliwość skorelowania tych informacji oczekiwania ze statystykami środowiska uruchomieniowego zapytania oznacza, że możesz lepiej zrozumieć, co przyczynia się do charakterystyki wydajności zapytań.
Poniżej przedstawiono kilka przykładów sposobu uzyskiwania większego wglądu w obciążenie przy użyciu statystyk oczekiwania w magazynie zapytań:
| Obserwacja | Akcja |
|---|---|
| Oczekiwanie na wysoką blokadę | Sprawdź teksty zapytań pod kątem zapytań, których dotyczy problem, i zidentyfikuj jednostki docelowe. Poszukaj w magazynie zapytań pod kątem innych zapytań modyfikujących tę samą jednostkę, która jest wykonywana często i/lub ma wysoki czas trwania. Po zidentyfikowaniu tych zapytań rozważ zmianę logiki aplikacji w celu poprawy współbieżności lub użyj mniej restrykcyjnego poziomu izolacji. |
| Wysokie oczekiwania we/wy buforu | Znajdź zapytania z dużą liczbą operacji odczytu fizycznego w magazynie zapytań. Jeśli pasują one do zapytań z dużymi oczekiwaniami we/wy, rozważ wprowadzenie indeksu w jednostce bazowej, aby wykonać wyszukiwanie zamiast skanowania. Zminimalizowałoby to obciążenie operacji we/wy zapytań. Sprawdź zalecenia dotyczące wydajności serwera w portalu, aby sprawdzić, czy istnieją zalecenia dotyczące indeksu dla tego serwera, które zoptymalizują zapytania. |
| Oczekiwanie na wysoką ilość pamięci | Znajdź zapytania zużywające najwięcej pamięci w magazynie zapytań. Te zapytania prawdopodobnie opóźniają dalszy postęp zapytań, których dotyczy problem. Sprawdź zalecenia dotyczące wydajności serwera w portalu, aby sprawdzić, czy istnieją zalecenia dotyczące indeksu, które zoptymalizują te zapytania. |
Opcje konfiguracji
Gdy magazyn zapytań jest włączony, zapisuje dane w oknach agregacji o długości określonej przez pg_qs.interval_length_minutes parametr serwera (domyślnie do 15 minut). Dla każdego okna przechowuje maksymalnie 500 unikatowych zapytań (z unikatowymi identyfikatorami użytkownika, dbid i queryid) na okno. Jeśli w interwale liczba odrębnych zapytań osiągnie 500, 5% z niższym użyciem zostanie cofnięto przydział, aby zapewnić więcej miejsca.
Dostępne są następujące opcje konfigurowania parametrów magazynu zapytań:
| Parametr | Opis | Wartość domyślna | Zakres |
|---|---|---|---|
| pg_qs.query_capture_mode | Zestawy, które instrukcje są śledzone. | Brak | brak, góra, wszystko |
| pg_qs.interval_length_minutes (*) | Ustawia interwał przechwytywania query_store w minutach dla pg_qs — jest to częstotliwość trwałości danych. | 15 | 1 - 30 |
| pg_qs.store_query_plans | Włącza lub wyłącza plany zapytań dla pg_qs. | wył. | włączone, wyłączone |
| pg_qs.max_plan_size | Ustawia maksymalną liczbę bajtów, które zostaną zapisane dla tekstu planu zapytania dla pg_qs; dłuższe plany zostaną obcięte. | 7500 | 100–10 tys. |
| pg_qs.max_query_text_length | Ustawia maksymalną długość zapytania, którą można zapisać; dłuższe zapytania zostaną obcięte. | 6000 | 100–10 000 |
| pg_qs.retention_period_in_days | Ustawia przedział okresu przechowywania w dniach dla pg_qs — po tym czasie dane zostaną usunięte. | 7 | 1 - 30 |
| pg_qs.track_utility | Określa, czy polecenia narzędzia są śledzone przez pg_qs. | on | włączone, wyłączone |
(*) Parametr serwera statycznego, który wymaga ponownego uruchomienia serwera, aby zmiany jego wartości zaczęły obowiązywać.
Następujące opcje mają zastosowanie specjalnie do statystyk oczekiwania:
| Parametr | Opis | Wartość domyślna | Zakres |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | Wybiera instrukcje śledzone przez rozszerzenie pgms_wait_sampling. | Brak | brak, wszystkie |
| Pgms_wait_sampling.history_period | Ustawia częstotliwość w milisekundach, w których są próbkowane zdarzenia oczekiwania. | 100 | 1-600000 |
Uwaga
pg_qs.query_capture_mode zastępuje pgms_wait_sampling.query_capture_mode. Jeśli pg_qs.query_capture_mode to NONE, ustawienie pgms_wait_sampling.query_capture_mode nie ma żadnego efektu.
Użyj witryny Azure Portal , aby uzyskać lub ustawić inną wartość parametru.
Widoki i funkcje
Wyświetlanie magazynu zapytań i zarządzanie nim przy użyciu następujących widoków i funkcji. Każda osoba w roli publicznej PostgreSQL może używać tych widoków do wyświetlenia danych w magazynie zapytań. Te widoki są dostępne tylko w bazie danych azure_sys .
Zapytania są znormalizowane przez przyjrzenie się ich strukturze i ignorowanie niczego, co nie jest semantycznie znaczące, na przykład literałów, stałych, aliasów lub różnic w wielkości liter.
Jeśli dwa zapytania są semantycznie identyczne, nawet jeśli używają różnych aliasów dla tych samych przywoływanych kolumn i tabel, są one identyfikowane z tym samym query_id. Jeśli dwa zapytania różnią się tylko wartościami literału używanymi w nich, są one również identyfikowane z tymi samymi query_id. W przypadku wszystkich zapytań zidentyfikowanych przy użyciu tego samego query_id ich sql_query_text będzie to zapytanie, które zostało wykonane najpierw od czasu rozpoczęcia działania rejestrowania przez magazyn zapytań lub od czasu ostatniego odrzucenia utrwalone dane, ponieważ funkcja query_store.qs_reset została wykonana.
Jak działa normalizacja zapytań
Poniżej przedstawiono kilka przykładów, aby spróbować zilustrować, jak działa normalizacja:
Załóżmy, że tworzysz tabelę z następującą instrukcją:
create table tableOne (columnOne int, columnTwo int);
Możesz włączyć zbieranie danych magazynu zapytań, a jeden lub wielu użytkowników wykonuje następujące zapytania w tej dokładnej kolejności:
select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";
Wszystkie poprzednie zapytania współdzielą te same query_id. Tekst, który przechowuje magazyn zapytań, to pierwszy zapytanie wykonywane po włączeniu zbierania danych. W związku z tym byłoby to select * from tableOne;.
Następujący zestaw zapytań, po normalizacji, nie pasuje do poprzedniego zestawu zapytań, ponieważ klauzula WHERE sprawia, że są one semantycznie różne:
select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;
Jednak wszystkie zapytania w tym ostatnim zestawie współużytkują te same query_id, a tekst użyty do zidentyfikowania ich wszystkich to pierwsze zapytanie w partii select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.
Na koniec znajdź poniżej kilka zapytań, które nie pasują do query_id tych w poprzedniej partii, i przyczyna, dla której nie są one następujące:
Zapytanie:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
Przyczyna braku dopasowania: Lista kolumn odwołuje się do tych samych dwóch kolumn (columnOne i ColumnTwo), ale kolejność, w której są one odwoływanych, jest odwrócona z columnOne, ColumnTwo poprzedniej partii do ColumnTwo, columnOne w tej kwerendzie.
Zapytanie:
select * from tableOne where columnTwo = 25 and columnOne = 25;
Przyczyna braku dopasowania: Kolejność, w której wyrażenia obliczane w klauzuli WHERE są odwrócione z columnOne = ? and ColumnTwo = ? poprzedniej partii do ColumnTwo = ? and columnOne = ? w tym zapytaniu.
Zapytanie:
select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;
Przyczyna braku dopasowania: pierwsze wyrażenie na liście kolumn nie columnOne jest już zgodne, ale funkcja abs obliczana na columnOne (abs(columnOne)), która nie jest równoważna semantycznie.
Zapytanie:
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;
Przyczyna braku dopasowania: pierwsze wyrażenie w klauzuli WHERE nie ocenia już równości columnOne z literałem, ale z wynikiem funkcji ceiling obliczonej na literał, który nie jest semantycznie równoważny.
Widoki
query_store.qs_view
Ten widok zwraca wszystkie dane, które zostały już utrwalone w tabelach pomocniczych magazynu zapytań. Dane, które są rejestrowane w pamięci dla aktualnie aktywnego przedziału czasu, nie są widoczne do czasu zakończenia przedziału czasu, a jego dane nietrwałe w pamięci są zbierane i utrwalane w tabelach przechowywanych na dysku. Ten widok zwraca inny wiersz dla każdej odrębnej bazy danych (db_id), użytkownika (user_id) i zapytania (query_id).
| Nazwa/nazwisko | Type | Dokumentacja | Opis |
|---|---|---|---|
| runtime_stats_entry_id | bigint | Identyfikator z tabeli runtime_stats_entries. | |
| user_id | Oid | pg_authid.oid | Identyfikator OID użytkownika, który wykonał instrukcję . |
| db_id | Oid | pg_database.oid | Identyfikator OID bazy danych, w której wykonano instrukcję. |
| query_id | bigint | Wewnętrzny kod skrótu obliczany z drzewa analizy instrukcji. | |
| query_sql_text | varchar(10000) | Tekst oświadczenia przedstawiciela. Różne zapytania o tej samej strukturze są grupowane razem; ten tekst jest tekstem pierwszego zapytania w klastrze. Wartość domyślna maksymalnej długości tekstu zapytania to 6000 i można ją zmodyfikować przy użyciu parametru pg_qs.max_query_text_lengthmagazynu zapytań . Jeśli tekst zapytania przekracza tę maksymalną wartość, zostanie obcięty z pierwszymi pg_qs.max_query_text_length znakami. |
|
| plan_id | bigint | Identyfikator planu odpowiadającego temu zapytaniu. | |
| start_time | timestamp | Zapytania są agregowane według przedziałów czasu, których przedział czasu jest definiowany przez parametr pg_qs.interval_length_minutes serwera (wartość domyślna to 15 minut). Jest to czas rozpoczęcia odpowiadający przedziałowi czasu dla tego wpisu. |
|
| end_time | timestamp | Godzina zakończenia odpowiadająca przedziałowi czasu dla tego wpisu. | |
| Wywołania | bigint | Ile razy zapytanie zostało wykonane w tym przedziale czasu. Zwróć uwagę, że w przypadku zapytań równoległych liczba wywołań dla każdego wykonania odpowiada 1 procesowi zaplecza, który napędza wykonywanie zapytania, oraz tyle innych jednostek dla każdego procesu roboczego zaplecza, które uruchomiono w celu współpracy przy wykonywaniu równoległych gałęzi drzewa wykonywania. | |
| total_time | podwójna precyzja | Łączny czas wykonywania zapytania w milisekundach. | |
| min_time | podwójna precyzja | Minimalny czas wykonywania zapytania w milisekundach. | |
| max_time | podwójna precyzja | Maksymalny czas wykonywania zapytania w milisekundach. | |
| mean_time | podwójna precyzja | Średni czas wykonywania zapytania w milisekundach. | |
| stddev_time | podwójna precyzja | Odchylenie standardowe czasu wykonywania zapytania w milisekundach. | |
| wiersze | bigint | Łączna liczba wierszy pobranych lub dotkniętych instrukcją . Zwróć uwagę, że w przypadku zapytań równoległych liczba wierszy dla każdego wykonania odpowiada liczbie wierszy zwróconych klientowi przez proces zaplecza, który powoduje wykonanie zapytania, oraz sumę wszystkich wierszy, które każdy proces roboczy zaplecza, uruchomiony w celu współpracy z równoległą gałęzią drzewa wykonywania, powraca do procesu zaplecza jazdy. | |
| shared_blks_hit | bigint | Łączna liczba trafień udostępnionej pamięci podręcznej bloków według instrukcji . | |
| shared_blks_read | bigint | Łączna liczba udostępnionych bloków odczytanych przez instrukcję . | |
| shared_blks_dirtied | bigint | Łączna liczba udostępnionych bloków brudnych przez instrukcję . | |
| shared_blks_written | bigint | Łączna liczba udostępnionych bloków napisanych przez instrukcję . | |
| local_blks_hit | bigint | Łączna liczba trafień lokalnej pamięci podręcznej bloków według instrukcji . | |
| local_blks_read | bigint | Łączna liczba bloków lokalnych odczytanych przez instrukcję . | |
| local_blks_dirtied | bigint | Łączna liczba bloków lokalnych zabrudowanych przez instrukcję . | |
| local_blks_written | bigint | Łączna liczba bloków lokalnych zapisanych przez instrukcję . | |
| temp_blks_read | bigint | Łączna liczba bloków tymczasowych odczytanych przez instrukcję . | |
| temp_blks_written | bigint | Łączna liczba bloków tymczasowych zapisanych przez instrukcję . | |
| blk_read_time | podwójna precyzja | Łączny czas spędzony na blokach odczytu w milisekundach (jeśli track_io_timing jest włączony, w przeciwnym razie zero). | |
| blk_write_time | podwójna precyzja | Łączny czas spędzony na zapisywaniu bloków w milisekundach (jeśli track_io_timing jest włączony, w przeciwnym razie zero). | |
| is_system_query | boolean | Określa, czy zapytanie zostało wykonane przez rolę z user_id = 10 (azuresu), które ma uprawnienia administratora i jest używane do wykonywania operacji okienka sterowania. Ponieważ ta usługa jest zarządzaną usługą PaaS, tylko firma Microsoft jest częścią tej roli administratora. | |
| query_type | text | Typ operacji reprezentowanej przez zapytanie. Możliwe wartości to unknown, selectmergeupdatedeleteutilityinsert, . undefinednothing |
query_store.query_text_view
Ten widok zwraca dane tekstowe zapytania w magazynie zapytań. Istnieje jeden wiersz dla każdego odrębnego query_sql_text.
| Nazwa/nazwisko | Typ | Opis |
|---|---|---|
| query_text_id | bigint | Identyfikator tabeli query_texts |
| query_sql_text | varchar(10000) | Tekst oświadczenia przedstawiciela. Różne zapytania o tej samej strukturze są grupowane razem; ten tekst jest tekstem pierwszego zapytania w klastrze. |
| query_type | smallint | Typ operacji reprezentowanej przez zapytanie. W wersji bazy danych PostgreSQL <= 14 możliwe wartości to 0 (nieznany), (select), 2 1 (update), (insert), 3 (delete 5 ), 4 (utility), 6 (nothing). W wersji bazy danych PostgreSQL >= 15 możliwe wartości to 0 (nieznany), (select), 1 2 (update), (insert), 3 (delete 5 ), 4 (merge), 6 (utility), 7 (nothing). |
query_store.pgms_wait_sampling_view
Ten widok zwraca dane zdarzeń oczekiwania w magazynie zapytań. Ten widok zwraca inny wiersz dla każdej odrębnej bazy danych (db_id), użytkownika (user_id), zapytania (query_id) i zdarzenia (zdarzenie).
| Nazwa/nazwisko | Type | Dokumentacja | Opis |
|---|---|---|---|
| start_time | timestamp | Zapytania są agregowane według przedziałów czasu, których przedział czasu jest definiowany przez parametr pg_qs.interval_length_minutes serwera (wartość domyślna to 15 minut). Jest to czas rozpoczęcia odpowiadający przedziałowi czasu dla tego wpisu. |
|
| end_time | timestamp | Godzina zakończenia odpowiadająca przedziałowi czasu dla tego wpisu. | |
| user_id | Oid | pg_authid.oid | Identyfikator OID użytkownika, który wykonał instrukcję . |
| db_id | Oid | pg_database.oid | Identyfikator OID bazy danych, w której wykonano instrukcję. |
| query_id | bigint | Wewnętrzny kod skrótu obliczany z drzewa analizy instrukcji. | |
| event_type | text | Typ zdarzenia, dla którego zaplecze oczekuje. | |
| event | text | Nazwa zdarzenia oczekiwania, jeśli zaplecze oczekuje obecnie. | |
| Wywołania | integer | Liczba przechwyconych zdarzeń. |
Uwaga
Aby uzyskać listę możliwych wartości w kolumnach event_type i zdarzeń widoku query_store.pgms_wait_sampling_view, zapoznaj się z oficjalną dokumentacją pg_stat_activity i poszukaj informacji odwołująjących się do kolumn o tych samych nazwach.
query_store.query_plans_view
Ten widok zwraca plan zapytania, który został użyty do wykonania zapytania. Istnieje jeden wiersz dla każdego unikatowego identyfikatora bazy danych i identyfikator zapytania. Spowoduje to przechowywanie tylko planów zapytań dla zapytań, które nie są wykorzystywane.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | bigint | Wartość skrótu z znormalizowanego planu zapytania wygenerowanego przez firmę EXPLAIN. Jest on uznawany za znormalizowany, ponieważ wyklucza szacowane koszty węzłów planu i użycie. | |
| db_id | Oid | pg_database.oid | Identyfikator OID bazy danych, w której wykonano instrukcję. |
| query_id | bigint | Wewnętrzny kod skrótu obliczany z drzewa analizy instrukcji. | |
| plan_text | varchar(10000) | Plan wykonania instrukcji podanej jako costs=false, buffers=false i format=text. Są to te same dane wyjściowe podane przez element WYJAŚNIJ. |
Funkcje
query_store.qs_reset
Ta funkcja odrzuca wszystkie statystyki zebrane do tej pory przez magazyn zapytań. Odrzuca ona zarówno statystyki dla już zamkniętych okien czasu, które zostały utrwalone w tabelach dysków, jak i dla bieżącego przedziału czasu, które są nadal przechowywane w pamięci. Tę funkcję można wykonać tylko przez rolę administratora serwera (azure_pg_admin).
query_store.staging_data_reset
Ta funkcja odrzuca wszystkie statystyki zebrane w pamięci przez magazyn zapytań (czyli dane w pamięci, które nie zostały jeszcze opróżnione do tabel dysków obsługujących trwałość zebranych danych dla magazynu zapytań). Tę funkcję można wykonać tylko przez rolę administratora serwera (azure_pg_admin).
Tryb tylko do odczytu
Gdy wystąpienie usługi Azure Database for PostgreSQL — serwer elastyczny jest w trybie tylko do odczytu, na przykład gdy default_transaction_read_only parametr jest ustawiony na on, lub jeśli tryb tylko do odczytu jest automatycznie włączony z powodu osiągnięcia pojemności magazynu, magazyn zapytań nie przechwytuje żadnych danych.