Sdílet prostřednictvím

Monitorování výkonu pomocí úložiště dotazů

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Funkce Úložiště dotazů na flexibilním serveru Azure Database for PostgreSQL poskytuje způsob, jak sledovat výkon dotazů v průběhu času. Úložiště dotazů zjednodušuje řešení potíží s výkonem tím, že vám pomůže rychle najít nejdéle běžící a nejvýkonnější dotazy náročné na prostředky. Úložiště dotazů automaticky zaznamenává historii dotazů a statistik modulu runtime a uchovává je pro vaši kontrolu. Data se rozkryjí podle času, abyste viděli vzory dočasného použití. Data pro všechny uživatele, databáze a dotazy se ukládají do databáze s názvem azure_sys v instanci flexibilního serveru Azure Database for PostgreSQL.

Důležité

Neupravujte databázi azure_sys ani její schéma. Tím zabráníte správnému fungování funkcí úložiště dotazů a souvisejících funkcí výkonu.

Povolení úložiště dotazů

Úložiště dotazů je dostupné ve všech oblastech bez dalších poplatků. Jedná se o funkci výslovného souhlasu, takže na serveru není ve výchozím nastavení povolená. Úložiště dotazů je možné povolit nebo zakázat globálně pro všechny databáze na daném serveru a není možné ho zapnout ani vypnout pro každou databázi.

Důležité

Nepovolujte úložiště dotazů na cenovou úroveň burstable, protože by to způsobilo dopad na výkon.

Povolení úložiště dotazů na webu Azure Portal

  1. Přihlaste se k webu Azure Portal a vyberte instanci flexibilního serveru Azure Database for PostgreSQL.
  2. V části Nastavení nabídky vyberte Parametryserveru.
  3. Vyhledejte pg_qs.query_capture_mode parametr.
  4. Nastavte hodnotu na TOP hodnotu nebo ALLv závislosti na tom, jestli chcete sledovat dotazy nejvyšší úrovně nebo také vnořené dotazy (spouštěné uvnitř funkce nebo procedury) a klikněte na Uložit. Umožňuje až 20 minut první dávky dat pro uchování v databázi azure_sys.

Povolení vzorkování čekání úložiště dotazů

  1. Vyhledejte pgms_wait_sampling.query_capture_mode parametr.
  2. Nastavte hodnotu na ALL a Uložte.

Informace v úložišti dotazů

Úložiště dotazů se skládá ze dvou úložišť:

  1. Úložiště statistik modulu runtime pro zachování informací o statistikách provádění dotazů.
  2. Statistika čekání ukládá informace o zachování statistik čekání.

Mezi běžné scénáře použití úložiště dotazů patří:

  • Určení počtu spuštění dotazu v daném časovém intervalu
  • Porovnáním průměrné doby provádění dotazu v časových oknech zobrazíte velké rozdíly.
  • Identifikace nejdéle běžících dotazů za posledních několik hodin
  • Identifikace hlavních N dotazů, které čekají na prostředky
  • Vysvětlení povahy čekání na konkrétní dotaz

Aby se minimalizovalo využití místa, statistiky spouštění modulu runtime v úložišti statistik modulu runtime se agregují v rámci pevného konfigurovatelného časového intervalu. Informace v těchto úložištích je možné dotazovat pomocí zobrazení.

Informace o úložišti dotazů accessu

Data úložiště dotazů se ukládají do azure_sys databáze na instanci flexibilního serveru Azure Database for PostgreSQL. Následující dotaz vrátí informace o dotazech v úložišti dotazů:

SELECT * FROM  query_store.qs_view;

Nebo tento dotaz na statistiky čekání:

SELECT * FROM  query_store.pgms_wait_sampling_view;

Vyhledání dotazů čekání

Typy událostí čekání kombinují různé události čekání do kontejnerů podle podobnosti. Úložiště dotazů poskytuje typ události čekání, konkrétní název události čekání a dotaz, který se týká. Schopnost korelovat tyto informace o čekání se statistikami modulu runtime dotazu znamená, že získáte hlubší přehled o tom, co přispívá k charakteristikám výkonu dotazů.

Tady je několik příkladů, jak můžete získat další přehled o úlohách pomocí statistik čekání v úložišti dotazů:

Pozorování Akce
Vysoké čekání zámků Zkontrolujte texty dotazů pro ovlivněné dotazy a identifikujte cílové entity. Vyhledejte v úložišti dotazů další dotazy, které upravují stejnou entitu, která se provádí často nebo mají vysokou dobu trvání. Po identifikaci těchto dotazů zvažte změnu logiky aplikace, aby se zlepšila souběžnost, nebo použijte méně omezující úroveň izolace.
Čekání vstupně-výstupních operací s vysokou vyrovnávací pamětí Vyhledejte dotazy s velkým počtem fyzických čtení v úložišti dotazů. Pokud odpovídají dotazům s velkými vstupně-výstupními čekáními, zvažte zavedení indexu u podkladové entity, aby se místo prohledávání hledaly. Tím se minimalizují režijní náklady na vstupně-výstupní operace dotazů. Zkontrolujte doporučení k výkonu serveru na portálu a zjistěte, jestli pro tento server existují doporučení indexu, která by optimalizovala dotazy.
Čekání s vysokým využitím paměti Vyhledejte dotazy s nejvyšším využitím paměti v úložišti dotazů. Tyto dotazy pravděpodobně zpozdí další průběh ovlivněných dotazů. Zkontrolujte doporučení k výkonu pro váš server na portálu a zjistěte, jestli existují doporučení indexu, která by tyto dotazy optimalizovala.

Možnosti konfigurace

Když je úložiště dotazů povolené, uloží data v agregačních oknech o délce určené parametrem pg_qs.interval_length_minutes serveru (výchozí hodnota je 15 minut). Pro každé okno ukládá 500 různých dotazů na okno. Pro konfiguraci parametrů úložiště dotazů jsou k dispozici následující možnosti:

Parametr Popis Výchozí Rozsah
pg_qs.query_capture_mode Nastaví, které příkazy se sledují. Žádná none, top, all
pg_qs.interval_length_minutes (*) Nastaví interval query_store zachytávání v minutách pro pg_qs – to je frekvence trvalosti dat. 15 1 - 30
pg_qs.store_query_plans Zapne nebo vypne ukládání plánů dotazů pro pg_qs. vypnuto zapnuto, vypnuto
pg_qs.max_plan_size Nastaví maximální počet bajtů, které budou uloženy pro text plánu dotazu pro pg_qs; delší plány budou zkráceny. 7 500 100 - 10 tisíc
pg_qs.max_query_text_length Nastaví maximální délku dotazu, kterou lze uložit; delší dotazy budou zkráceny. 6000 100 - 10 tisíc
pg_qs.retention_period_in_days Nastaví časový interval uchovávání ve dnech pro pg_qs – po tomto čase budou data odstraněna. 7 1 - 30
pg_qs.track_utility Nastaví, zda jsou příkazy nástroje sledovány pomocí pg_qs. on zapnuto, vypnuto

(*) Statický parametr serveru, který vyžaduje restartování serveru, aby se změna jeho hodnoty projevila.

Následující možnosti se vztahují konkrétně na statistiky čekání:

Parametr Popis Výchozí Rozsah
pgms_wait_sampling.query_capture_mode Vybere, které příkazy jsou sledovány rozšířením pgms_wait_sampling. Žádná žádná, vše
Pgms_wait_sampling.history_period Nastaví frekvenci v milisekundách, ve kterých se vzorkují události čekání. 100 1-600000

Poznámka:

pg_qs.query_capture_mode nahrazuje režim pgms_wait_sampling.query_capture_mode. Pokud je pg_qs.query_capture_mode NONE, nastavení pgms_wait_sampling.query_capture_mode nemá žádný vliv.

Na webu Azure Portal můžete získat nebo nastavit jinou hodnotu parametru.

Zobrazení a funkce

K zobrazení a správě úložiště dotazů použijte následující zobrazení a funkce. Tato zobrazení může zobrazit kdokoli ve veřejné roli PostgreSQL k zobrazení dat v úložišti dotazů. Tato zobrazení jsou k dispozici pouze v databázi azure_sys .

Dotazy jsou normalizovány tím, že se podíváte na jejich strukturu a ignorujete cokoli, co není sémanticky významné, jako jsou literály, konstanty, aliasy nebo rozdíly v písmenech.

Pokud jsou dva dotazy sémanticky identické, i když pro stejné odkazované sloupce a tabulky používají různé aliasy, jsou identifikovány se stejným query_id. Pokud se dva dotazy liší pouze v hodnotách literálů použitých v nich, jsou také identifikovány se stejnými query_id. U všech dotazů identifikovaných se stejnými query_id budou jejich sql_query_text dotazem, který se spustil jako první od spuštění aktivity záznamu úložiště dotazů, nebo od posledního zahození trvalých dat, protože funkce query_store.qs_reset byla provedena.

Jak funguje normalizace dotazů

Tady je několik příkladů, které vám pokusit ilustrovat, jak tato normalizace funguje:

Řekněme, že vytvoříte tabulku s následujícím příkazem:

create table tableOne (columnOne int, columnTwo int);

Povolíte shromažďování dat úložiště dotazů a v tomto přesném pořadí spustí jeden nebo více uživatelů následující dotazy:

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";

Všechny předchozí dotazy sdílejí stejné query_id. A text, který úložiště dotazů uchovává, je to, že první dotaz se spustí po povolení shromažďování dat. Proto by to bylo select * from tableOne;.

Následující sada dotazů po normalizaci neodpovídá předchozí sadě dotazů, protože klauzule WHERE je sémanticky liší:

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;

Všechny dotazy v této poslední sadě však sdílejí stejné query_id a text použitý k jejich identifikaci je to, že první dotaz v dávce select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Nakonec pod některými dotazy, které neodpovídají query_id z nich v předchozí dávce, a důvod, proč ne:

Dotaz:

select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

Důvod, proč se neshoduje: Seznam sloupců odkazuje na stejné dva sloupce (columnOne a ColumnTwo), ale pořadí, ve kterém jsou odkazovány, je obrácené, od columnOne, ColumnTwo předchozí dávky do ColumnTwo, columnOne tohoto dotazu.

Dotaz:

select * from tableOne where columnTwo = 25 and columnOne = 25;

Důvod, proč se neshoduje: Pořadí, ve kterém se výrazy vyhodnocované v klauzuli WHERE odkazují, jsou v předchozí dávce v ColumnTwo = ? and columnOne = ? tomto dotazu obrácenycolumnOne = ? and ColumnTwo = ?.

Dotaz:

select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;

Důvod, proč se neshoduje: První výraz v seznamu sloupců už není columnOne , ale funkce abs se vyhodnotí jako columnOne (abs(columnOne)), což není sémanticky ekvivalentní.

Dotaz:

select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;

Důvod, proč se neshoduje: První výraz v klauzuli WHERE už nevyhodnocuje rovnost columnOne s literálem, ale s výsledkem funkce ceiling vyhodnoceným přes literál, který není sémanticky ekvivalentní.

Zobrazení

query_store.qs_view

Toto zobrazení vrátí všechna data, která již byla uložena v podpůrných tabulkách úložiště dotazů. Data, která se zaznamenávají v paměti pro aktuálně aktivní časové období, se nezobrazují, dokud nedojde ke konci časového intervalu a data v paměti se shromažďují a uchovávají v tabulkách uložených na disku. Toto zobrazení vrátí jiný řádek pro každou odlišnou databázi (db_id), uživatele (user_id) a dotaz (query_id).

Název Typ Odkazy Popis
runtime_stats_entry_id bigint ID z tabulky runtime_stats_entries.
user_id Oid pg_authid.oid Identifikátor identifikátoru uživatele, který příkaz spustil.
db_id Oid pg_database.oid Identifikátor databáze, ve které byl příkaz proveden.
query_id bigint Interní hashovací kód vypočítaný ze stromu analýzy příkazu
query_sql_text varchar(10000) Text reprezentativního příkazu Různé dotazy se stejnou strukturou jsou seskupené dohromady; tento text je text pro první z dotazů v clusteru. Výchozí hodnota maximální délky textu dotazu je 6000 a lze ji upravit pomocí parametru pg_qs.max_query_text_lengthúložiště dotazů . Pokud text dotazu překročí tuto maximální hodnotu, zkrátí se na první pg_qs.max_query_text_length znaky.
plan_id bigint ID plánu odpovídající tomuto dotazu.
start_time časové razítko Dotazy se agregují podle časových intervalů, jejichž časové rozpětí je definováno parametrem pg_qs.interval_length_minutes serveru (výchozí hodnota je 15 minut). Toto je počáteční čas odpovídající časovému intervalu pro tuto položku.
end_time časové razítko Koncový čas odpovídající časovému intervalu pro tuto položku.
volá bigint Počet spuštění dotazu v tomto časovém intervalu Všimněte si, že u paralelních dotazů počet volání pro každé spuštění odpovídá 1 pro back-endový proces, který řídí provádění dotazu, a také tolik dalších jednotek pro každý back-endový pracovní proces, který se spustil za účelem spolupráce na provádění paralelních větví stromu spuštění.
total_time dvojitá přesnost Celková doba provádění dotazů v milisekundách
min_time dvojitá přesnost Minimální doba provádění dotazů v milisekundách
max_time dvojitá přesnost Maximální doba provádění dotazů v milisekundách
mean_time dvojitá přesnost Střední doba provádění dotazů v milisekundách
stddev_time dvojitá přesnost Směrodatná odchylka doby provádění dotazu v milisekundách
řádky bigint Celkový počet řádků načtených nebo ovlivněných příkazem Všimněte si, že u paralelních dotazů počet řádků pro každé spuštění odpovídá počtu řádků vrácených klientovi back-endovým procesem, který řídí provádění dotazu, a součet všech řádků, které každý back-endový pracovní proces spustil ke spolupráci při provádění paralelních větví stromu spuštění, se vrátí do procesu řízení back-endu.
shared_blks_hit bigint Celkový počet přístupů sdílené mezipaměti bloku příkazem.
shared_blks_read bigint Celkový počet sdílených bloků přečtených příkazem
shared_blks_dirtied bigint Celkový početsdílenýchch
shared_blks_written bigint Celkový počet sdílených bloků zapsaných příkazem
local_blks_hit bigint Celkový počet přístupů do místní mezipaměti bloků příkazem
local_blks_read bigint Celkový počet místních bloků přečtených příkazem.
local_blks_dirtied bigint Celkový počet místních bloků, které příkaz pošpinil.
local_blks_written bigint Celkový počet místních bloků zapsaných příkazem
temp_blks_read bigint Celkový počet dočasných bloků přečtených příkazem.
temp_blks_written bigint Celkový počet dočasných bloků zapsaných příkazem
blk_read_time dvojitá přesnost Celkový čas strávený čtením bloků v milisekundách (pokud je povolená track_io_timing, jinak nula).
blk_write_time dvojitá přesnost Celkový čas strávený zápisem bloků v milisekundách (pokud je povolená track_io_timing, jinak nula).
is_system_query boolean Určuje, jestli byl dotaz proveden rolí s user_id = 10 (azuresu), který má oprávnění superuživatele a používá se k provádění operací s podoknem řízení. Vzhledem k tomu, že je tato služba spravovanou službou PaaS, je součástí této role superuživatele pouze Microsoft.
query_type text Typ operace reprezentovaný dotazem Možné hodnoty jsou unknown, , select, update, deleteutilitynothinginsertmerge. undefined

query_store.query_text_view

Toto zobrazení vrátí textová data dotazu v úložišti dotazů. Každý samostatný query_sql_text má jeden řádek.

Název Typ Popis
query_text_id bigint ID tabulky query_texts
query_sql_text varchar(10000) Text reprezentativního příkazu Různé dotazy se stejnou strukturou jsou seskupené dohromady; tento text je text pro první z dotazů v clusteru.
query_type smallint Typ operace reprezentovaný dotazem Ve verzi PostgreSQL <= 14 jsou 0 možné hodnoty (neznámé), 1 (select), 2 (update), (insert), 3 (delete), 45 (utility), 6 (nothing). Ve verzi PostgreSQL >= 15 jsou 0 možné hodnoty (neznámé), 1 (select), 2 (update), (insert), 3 (delete), 45 (merge), 6 (utility), 7 (nothing).

query_store.pgms_wait_sampling_view

Toto zobrazení vrátí data událostí čekání v úložišti dotazů. Toto zobrazení vrátí jiný řádek pro každou odlišnou databázi (db_id), uživatele (user_id), dotaz (query_id) a událost (událost).

Název Typ Odkazy Popis
start_time časové razítko Dotazy se agregují podle časových intervalů, jejichž časové rozpětí je definováno parametrem pg_qs.interval_length_minutes serveru (výchozí hodnota je 15 minut). Toto je počáteční čas odpovídající časovému intervalu pro tuto položku.
end_time časové razítko Koncový čas odpovídající časovému intervalu pro tuto položku.
user_id Oid pg_authid.oid Identifikátor identifikátoru uživatele, který příkaz spustil.
db_id Oid pg_database.oid Identifikátor databáze, ve které byl příkaz proveden.
query_id bigint Interní hashovací kód vypočítaný ze stromu analýzy příkazu
event_type text Typ události, pro kterou back-end čeká.
event text Název události čekání, pokud back-end právě čeká.
volá integer Kolikrát byla zaznamenána stejná událost.

Poznámka:

Seznam možných hodnot ve sloupcích event_type a událostí query_store.pgms_wait_sampling_view najdete v oficiální dokumentaci pg_stat_activity a vyhledejte informace odkazující na sloupce se stejnými názvy.

query_store.query_plans_view

Toto zobrazení vrátí plán dotazu, který se použil k provedení dotazu. Každý jedinečný IDENTIFIKÁTOR databáze má jeden řádek a ID dotazu. Tím se budou ukládat pouze plány dotazů pro dotazy, které nejsou využitelné.

plan_id db_id query_id plan_text
plan_id bigint Hodnota hash z normalizovaného plánu dotazu vytvořeného aplikací EXPLAIN. Považuje se za normalizované, protože vylučuje odhadované náklady na uzly plánu a využití vyrovnávacích pamětí.
db_id Oid pg_database.oid Identifikátor databáze, ve které byl příkaz proveden.
query_id bigint Interní hashovací kód vypočítaný ze stromu analýzy příkazu
plan_text varchar(10000) Plán provádění příkazu s daným příkazem costs=false, buffers=false a format=text. Tento výstup je stejný jako funkce EXPLAIN.

Functions

query_store.qs_reset

Tato funkce zahodí všechny statistiky shromážděné doposud v úložišti dotazů. Zahodí obě statistiky pro již uzavřená časová období, která byla zachována v tabulkách disků, a statistiky pro aktuální časové období, které jsou stále v paměti. Tuto funkci může spustit jenom role správce serveru (azure_pg_admin).

query_store.staging_data_reset

Tato funkce zahodí všechny statistiky shromážděné v paměti úložištěm dotazů (to znamená data v paměti, která ještě nebyla vyprázdněna do tabulek disků podporující trvalost shromážděných dat pro úložiště dotazů). Tuto funkci může spustit jenom role správce serveru (azure_pg_admin).

Omezení a známé problémy

Kompatibilita azure Storage a úložiště dotazů

Kvůli problémům s kompatibilitou nemůžete povolit rozšíření Azure Storage a Úložiště dotazů najednou. Pokud chcete zajistit správné fungování a vyhnout se potenciálním konfliktům, povolte vždy jenom jedno z těchto rozšíření.

Použití Služby Azure Storage:

  • Zakažte úložiště dotazů nastavením parametru pg_qs.query_capture_mode na NONE. Tento parametr je dynamický, takže ho nemusíte restartovat.

Použití úložiště dotazů:

  1. Zakažte rozšíření Azure Storage vydáním DROP EXTENSION azure_storage;příkazu .
  2. Odeberte Službu Azure Storage z shared_preload_libraries.
  3. Restartujte databázový server.

Tyto kroky jsou nezbytné k zabránění konfliktům a k zajištění správného fungování systému. Pracujeme na řešení těchto problémů s kompatibilitou a budeme vás informovat o všech aktualizacích.

Režim jen pro čtení

Pokud je instance flexibilního serveru Azure Database for PostgreSQL v režimu jen pro čtení, například když default_transaction_read_only je parametr nastavený na on, nebo pokud je režim jen pro čtení automaticky povolený kvůli dosažení kapacity úložiště, úložiště dotazů nezachytává žádná data.

Související obsah