Monitorování výkonu pomocí úložiště dotazů
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
- Přihlaste se k webu Azure Portal a vyberte instanci flexibilního serveru Azure Database for PostgreSQL.
- V části Nastavení nabídky vyberte Parametry serveru.
- Vyhledejte
pg_qs.query_capture_modeparametr. - Nastavte hodnotu na
TOPhodnotu neboALLv 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ů
- Vyhledejte
pgms_wait_sampling.query_capture_modeparametr. - Nastavte hodnotu na
ALLa Uložte.
Informace v úložišti dotazů
Úložiště dotazů se skládá ze dvou úložišť:
- Úložiště statistik modulu runtime pro zachování informací o statistikách provádění dotazů.
- 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á až 500 jedinečných dotazů (s jedinečným id uživatele, dbid a id dotazu). Pokud během intervalu počet jedinečných dotazů dosáhne 500, uvolní se 5 % s nižším využitím, aby se uvolnilo místo pro další využití.
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), 4 5 (utility), 6 (nothing). Ve verzi PostgreSQL >= 15 jsou 0 možné hodnoty (neznámé), 1 (select), 2 (update), (insert), 3 (delete), 4 5 (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. |
Funkce
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).
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.