Monitorování výkonu pomocí úložiště dotazů
PLATÍ PRO: 
Flexibilní server Azure Database for PostgreSQL
Úložiště dotazů je funkce flexibilního serveru Azure Database for PostgreSQL, která poskytuje způsob sledování výkonu 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 pojmenované azure_sys v instanci flexibilního serveru Azure Database for PostgreSQL.
Povolení úložiště dotazů
Úložiště dotazů je možné používat 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 (ty, které se spouštějí uvnitř funkce nebo procedury) a vyberte Uložit. Počkejte až 20 minut, než se první dávka dat bude uchovávat vazure_sysdatabázi.
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é variace.
- Identifikace nejdéle běžících dotazů za posledních několik hodin
- Identifikace hlavních N dotazů, které čekají na prostředky
- Pochopení 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í.
Přístup k informacím o úložišti dotazů
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, které byly zaznamenány v úložišti dotazů:
SELECT * FROM query_store.qs_view;
A tento dotaz vrátí informace o statistikách č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. Hledejte v úložišti dotazů další dotazy, které se provádějí často nebo mají vysokou dobu trvání a upravují stejnou entitu. 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 povolení funkce automatického ladění indexů, abyste zjistili, jestli může doporučit vytvoření některých indexů, které by mohly snížit počet fyzických čtení pro tyto dotazy. |
| Vysoké čekání na paměť | 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ů. |
Možnosti konfigurace
Pokud je úložiště dotazů povolené, uloží data v agregačních oknech o délce určené parametrem serveru pg_qs.interval_length_minutes (výchozí hodnota je 15 minut). Pro každé okno ukládá až 500 různých dotazů na okno. Atributy, které rozlišují jedinečnost každého dotazu, jsou user_id (identifikátor uživatele, který dotaz spouští), db_id (identifikátor databáze, v jehož kontextu se dotaz spustí) a query_id (celočíselná hodnota jedinečně identifikující spuštěný dotaz). Pokud počet jedinečných dotazů dosáhne 500 během nakonfigurovaného intervalu, uvolní se 5 % zaznamenaných dotazů, aby se uvolnilo místo pro více. Ty, které byly uvolněny jako první, jsou ty, které byly provedeny nejméně kolikrát.
Pro konfiguraci parametrů úložiště dotazů jsou k dispozici následující možnosti:
| Parametr | Popis | Výchozí | Rozsah |
|---|---|---|---|
pg_qs.interval_length_minutes (*) |
Interval zachytávání v minutách pro úložiště dotazů Definuje frekvenci trvalosti dat. | 15 |
1 - 30 |
pg_qs.is_enabled_fs |
Pouze interní použití: Tento parametr se používá jako přepínač přepsání funkce. Pokud se zobrazí jako vypnuté, úložiště dotazů je zakázané, i když je nastavena pg_qs.query_capture_modehodnota . |
on |
on, off |
pg_qs.max_plan_size |
Maximální počet bajtů uložených z textu plánu dotazu podle úložiště dotazů; delší plány jsou zkráceny. | 7500 |
100 - 10000 |
pg_qs.max_query_text_length |
Maximální délka dotazu, kterou lze uložit; delší dotazy jsou zkráceny. | 6000 |
100 - 10000 |
pg_qs.parameters_capture_mode |
Určuje, jestli a kdy zachytit poziční parametry dotazu. | capture_parameterless_only |
capture_parameterless_only, capture_first_sample |
pg_qs.query_capture_mode |
Příkazy ke sledování | none |
none, , topall |
pg_qs.retention_period_in_days |
Interval doby uchovávání ve dnech úložiště dotazů. Starší data se automaticky odstraní. | 7 |
1 - 30 |
pg_qs.store_query_plans |
Určuje, jestli se plány dotazů mají ukládat do úložiště dotazů. | off |
on, off |
pg_qs.track_utility |
Určuje, jestli úložiště dotazů musí sledovat příkazy nástroje. | on |
on, off |
(*) 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.history_period |
Frekvence v milisekundách, ve kterých se vzorkují události čekání. | 100 |
1 - 600000 |
pgms_wait_sampling.is_enabled_fs |
Pouze interní použití: Tento parametr se používá jako přepínač přepsání funkce. Pokud se zobrazí jako off, je vzorkování čekání zakázané i přes hodnotu nastavenou pro pgms_wait_sampling.query_capture_mode. |
on |
on, off |
pgms_wait_sampling.query_capture_mode |
Které příkazy pgms_wait_sampling musí rozšíření sledovat. |
none |
none, all |
Poznámka:
pg_qs.query_capture_modepgms_wait_sampling.query_capture_modenahrazuje . Pokud pg_qs.query_capture_mode ano none, pgms_wait_sampling.query_capture_mode nastavení nemá žádný vliv.
Na webu Azure Portal můžete získat nebo nastavit jinou hodnotu parametru.
Zobrazení a funkce
Můžete se dotazovat na informace zaznamenané úložištěm dotazů a odstranit je pomocí některých zobrazení a funkcí dostupných ve query_store schématu azure_sys databáze. 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 dotazů identifikovaných se stejným query_id je 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 těch 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 vyhodnocuje (abs(columnOne)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á jsou uložená v podpůrných tabulkách úložiště dotazů. Data, která stále nahrá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 bajty. |
|
plan_id |
bigint | ID plánu odpovídající tomuto dotazu. | |
start_time |
časové razítko | Dotazy se agregují podle časových intervalů. Parametr pg_qs.interval_length_minutes serveru definuje časové rozpětí těchto oken (výchozí hodnota je 15 minut). Tento sloupec odpovídá počátečnímu času okna, ve kterém byla tato položka zaznamenána. |
|
end_time |
časové razítko | Koncový čas odpovídající časovému intervalu pro tuto položku. | |
calls |
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ý spustí spolupráci při 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 | |
rows |
bigint | Celkový počet řádků načtených nebo ovlivněných příkazem Všimněte si, že 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é jednotlivé back-endové pracovní procesy spustily pro spolupráci při provádění paralelních větví stromu spuštění, se vrátí do back-endového procesu, který řídí provádění dotazu. | |
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 se dotaz spustil pomocí user_id = 10 (azuresu). Tento uživatel má oprávnění superuživatele a slouží k provádění operací řídicí roviny. 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 |
|
search_path |
text | Hodnota search_path nastavená v době zachycení dotazu. | |
query_parameters |
text | Textové znázornění objektu JSON s hodnotami předanými pozičním parametrům parametrizovaného dotazu. Tento sloupec naplní hodnotu pouze ve dvou případech: 1) pro neparametrizované dotazy. 2) Pro parametrizované dotazy, pokud pg_qs.parameters_capture_mode je nastavena na capture_first_sample, a pokud úložiště dotazů může načíst hodnoty parametrů dotazu v době provádění. |
|
parameters_capture_status |
text | Typ operace reprezentovaný dotazem Možné hodnoty jsou succeeded (dotaz nebyl parametrizován nebo se jedná o parametrizovaný dotaz a hodnoty byly úspěšně zachyceny), disabled (dotaz byl parametrizován, ale parametry nebyly zachyceny, protože pg_qs.parameters_capture_mode byly nastaveny na capture_parameterless_only), too_long_to_capture (dotaz byl parametrizován, ale parametry nebyly zachyceny, protože délka výsledného JSON, která by se zobrazila ve query_parameters sloupci tohoto zobrazení, byla považována za příliš dlouhou dobu, než se úložiště dotazů zachová). too_many_to_capture (dotaz byl parametrizován, ale parametry nebyly zachyceny, protože celkový počet parametrů, byly považovány za nadměrné, aby úložiště dotazů trvalo), serialization_failed (dotaz byl parametrizován, ale alespoň jedna z hodnot předaných jako parametr nemohl být serializována na text). |
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ů. Parametr pg_qs.interval_length_minutes serveru definuje časové rozpětí těchto oken (výchozí hodnota je 15 minut). Tento sloupec odpovídá počátečnímu času okna, ve kterém byla tato položka zaznamenána. |
|
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 objektu uživatele, který příkaz spustil. |
db_id |
Oid | pg_database.oid | Identifikátor objektu 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á. | |
calls |
integer | Kolikrát byla zaznamenána stejná událost. |
Poznámka:
Seznam možných hodnot v event_type zobrazení a event sloupcích 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. Úložiště dotazů zaznamenává pouze plány dotazů pro dotazy, které nejsou využitelné.
| Název | Typ | Odkazy | Popis |
|---|---|---|---|
plan_id |
bigint | Hodnota hash z normalizovaného plánu dotazu vytvořeného aplikací EXPLAIN. Je v normalizované podobě, 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. Identický výstup jako výstup vytvořený pomocí funkce EXPLAIN. |
Funkce
query_store.qs_reset
Tato funkce zahodí všechny statistiky shromážděné doposud podle úložiště dotazů. Zahodí statistiky pro již uzavřená časová období, která jsou již zachována v tabulkách na disku. Zahodí také statistiku aktuálního časového intervalu, který existuje pouze v paměti. Tuto funkci můžou spustit jenom členové 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ě nejsou vyprázdněná do tabulek disků podporující trvalost shromážděných dat pro úložiště dotazů). Tuto funkci můžou spustit jenom členové 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 onhodnotu , 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.
Povolení úložiště dotazů na serveru s replikami pro čtení automaticky nepovoluje úložiště dotazů na žádné z replik pro čtení. I když ho povolíte na některé z replik pro čtení, úložiště dotazů nezaznamená dotazy spuštěné u žádné repliky pro čtení, protože fungují v režimu jen pro čtení, dokud je neupřednostníte na primární.
Sdílejte své návrhy a chyby s produktovým týmem Azure Database for PostgreSQL.
Související obsah
- Scénáře použití úložiště dotazů na flexibilním serveru Azure Database for PostgreSQL
- Osvědčené postupy pro úložiště dotazů na flexibilním serveru Azure Database for PostgreSQL
- Query Performance Insight na flexibilním serveru Azure Database for PostgreSQL