Udostępnij za pośrednictwem

Monitorowanie wydajności przy użyciu magazynu zapytań

  • Artykuł

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

  1. Zaloguj się do witryny Azure Portal i wybierz wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL.
  2. Wybierz pozycję Parametry serwera w sekcji Ustawienia menu.
  3. pg_qs.query_capture_mode Wyszukaj parametr .
  4. Ustaw wartość na TOP lub ALL, 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ń

  1. pgms_wait_sampling.query_capture_mode Wyszukaj parametr .
  2. Ustaw wartość na ALL i Zapisz.

Informacje w magazynie zapytań

Magazyn zapytań składa się z dwóch magazynów:

  1. Magazyn statystyk środowiska uruchomieniowego do utrwalania informacji dotyczących statystyk wykonywania zapytań.
  2. 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 500 odrębnych zapytań na okno. 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), 21 (update), (insert), 3 (delete 5 ), 4 (utility), 6 (nothing). W wersji bazy danych PostgreSQL >= 15 możliwe wartości to 0 (nieznany), (select), 12 (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).

Ograniczenia i znane problemy

Zgodność usługi Azure Storage i magazynu zapytań

Ze względu na problemy ze zgodnością nie można jednocześnie włączyć rozszerzeń usługi Azure Storage i magazynu zapytań. Aby zapewnić prawidłowe działanie i uniknąć potencjalnych konfliktów, włącz jednocześnie tylko jedno z tych rozszerzeń.

Aby użyć usługi Azure Storage:

  • Wyłącz magazyn zapytań, ustawiając parametr pg_qs.query_capture_mode na NONE. Ten parametr jest dynamiczny, więc nie trzeba ponownie uruchamiać.

Aby użyć magazynu zapytań:

  1. Wyłącz rozszerzenie usługi Azure Storage, wydając polecenie DROP EXTENSION azure_storage;.
  2. Usuń usługę Azure Storage z shared_preload_librariesusługi .
  3. Uruchom ponownie serwer bazy danych.

Te kroki są niezbędne do zapobiegania konfliktom i zapewnienia prawidłowego działania systemu. Pracujemy nad rozwiązaniem tych problemów ze zgodnością i poinformujemy Cię o wszelkich aktualizacjach.

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.

Powiązana zawartość