Övervaka prestanda med Query Store
GÄLLER FÖR:
Azure Database for PostgreSQL – flexibel server
Funktionen Query Store i Azure Database for PostgreSQL – flexibel server ger ett sätt att spåra frågeprestanda över tid. Query Store förenklar prestandafelsökningen genom att hjälpa dig att snabbt hitta de längsta och mest resursintensiva frågorna. Query Store samlar automatiskt in en historik över frågor och körningsstatistik, och den behåller dem för din granskning. Den delar upp data efter tid så att du kan se tidsmässiga användningsmönster. Data för alla användare, databaser och frågor lagras i en databas med namnet azure_sys i Azure Database for PostgreSQL– flexibel serverinstans.
Viktigt!
Ändra inte azure_sys-databasen eller dess schema. Detta förhindrar att Query Store och relaterade prestandafunktioner fungerar korrekt.
Aktivera Query Store
Query Store är tillgängligt i alla regioner utan extra avgifter. Det är en opt-in-funktion, så den är inte aktiverad som standard på en server. Frågearkiv kan aktiveras eller inaktiveras globalt för alla databaser på en viss server och kan inte aktiveras eller inaktiveras per databas.
Viktigt!
Aktivera inte Query Store på prisnivån Burstable eftersom det skulle orsaka prestandapåverkan.
Aktivera Query Store i Azure-portalen
- Logga in på Azure-portalen och välj din flexibla Serverinstans för Azure Database for PostgreSQL.
- Välj Serverparametrar i avsnittet Inställningar på menyn.
- Sök efter parametern
pg_qs.query_capture_mode. - Ange värdet till
TOPellerALL, beroende på om du vill spåra frågor på toppnivå eller även kapslade frågor (de som körs i en funktion eller procedur) och klicka på Spara. Vänta 20 minuter för den första databatchen ska hinna sparas i databasen azure_sys.
Aktivera väntesampling för Frågearkiv
- Sök efter parametern
pgms_wait_sampling.query_capture_mode. - Ange värdet till
ALLoch Spara.
Information i Query Store
Query Store består av två butiker:
- Ett körningsstatistiklager för att bevara information om frågekörningsstatistik.
- Ett väntestatistikarkiv för att spara information om väntestatistik.
Vanliga scenarier för att använda Query Store är:
- Fastställa hur många gånger en fråga kördes under en viss tidsperiod.
- Jämföra den genomsnittliga körningstiden för en fråga över tidsfönster för att se stora delta.
- Identifiera de frågor som har körts längst under de senaste timmarna.
- Identifiera de främsta N-frågorna som väntar på resurser.
- Förstå väntande natur för en viss fråga.
För att minimera utrymmesanvändningen aggregeras körningsstatistiken i statistikarkivet för körning över ett fast, konfigurerbart tidsfönster. Informationen i dessa butiker kan efterfrågas med hjälp av vyer.
Åtkomst till Information om Query Store
Query Store-data lagras i den azure_sys databasen på din flexibla Azure Database for PostgreSQL-serverinstans. Följande fråga returnerar information om frågor i Query Store:
SELECT * FROM query_store.qs_view;
Eller den här frågan för väntestatistik:
SELECT * FROM query_store.pgms_wait_sampling_view;
Hitta väntefrågor
Väntehändelsetyper kombinerar olika väntehändelser i bucketar efter likhet. Query Store innehåller typen av väntehändelse, ett specifikt namn på väntehändelsen och frågan i fråga. Om du kan korrelera den här vänteinformationen med frågekörningsstatistiken kan du få en djupare förståelse för vad som bidrar till frågeprestandaegenskaper.
Här följer några exempel på hur du kan få mer insikter om din arbetsbelastning med hjälp av väntestatistiken i Query Store:
| Observation | Åtgärd |
|---|---|
| Väntetider med högt lås | Kontrollera frågetexterna för de berörda frågorna och identifiera målentiteterna. Leta i Query Store efter andra frågor som ändrar samma entitet, som körs ofta och/eller har hög varaktighet. När du har identifierat dessa frågor kan du överväga att ändra programlogik för att förbättra samtidigheten eller använda en mindre restriktiv isoleringsnivå. |
| I/O-väntetider med hög buffert | Hitta frågorna med ett stort antal fysiska läsningar i Query Store. Om de matchar frågorna med höga I/O-väntetider bör du överväga att införa ett index på den underliggande entiteten för att söka i stället för genomsökningar. Detta skulle minimera I/O-omkostnaderna för frågorna. Kontrollera prestanda Rekommendationer för servern i portalen för att se om det finns indexrekommendationer för den här servern som skulle optimera frågorna. |
| Väntetider med högt minne | Hitta de vanligaste minneskrävande frågorna i Query Store. Dessa frågor fördröjer förmodligen ytterligare förlopp för de berörda frågorna. Kontrollera prestanda Rekommendationer för servern i portalen för att se om det finns indexrekommendationer som skulle optimera dessa frågor. |
Konfigurationsalternativ
När Query Store är aktiverat sparar det data i aggregeringsfönster med längd som bestäms av pg_qs.interval_length_minutes serverparametern (standardvärdet är 15 minuter). För varje fönster lagras 500 distinkta frågor per fönster.
Följande alternativ är tillgängliga för att konfigurera Query Store-parametrar:
| Parameter | Beskrivning | Standard | Intervall |
|---|---|---|---|
| pg_qs.query_capture_mode | Anger vilka instruktioner som spåras. | inget | none, top, all |
| pg_qs.interval_length_minutes (*) | Anger query_store avbildningsintervall i minuter för pg_qs – det här är frekvensen för datapersistence. | 15 | 1 - 30 |
| pg_qs.store_query_plans | Aktiverar eller inaktiverar sparande av frågeplaner för pg_qs. | av | på, av |
| pg_qs.max_plan_size | Anger det maximala antalet byte som ska sparas för frågeplanstext för pg_qs. längre planer trunkeras. | 7 500 | 100 -10k |
| pg_qs.max_query_text_length | Anger den maximala frågelängd som kan sparas. längre frågor trunkeras. | 6000 | 100–10 000 |
| pg_qs.retention_period_in_days | Anger kvarhållningsperioden i dagar för pg_qs – efter den här tiden tas data bort. | 7 | 1 - 30 |
| pg_qs.track_utility | Anger om verktygskommandon spåras av pg_qs. | on | på, av |
(*) Statisk serverparameter som kräver en omstart av servern för att en ändring av dess värde ska börja gälla.
Följande alternativ gäller specifikt för väntestatistik:
| Parameter | Beskrivning | Standard | Intervall |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | Väljer vilka instruktioner som spåras av pgms_wait_sampling-tillägget. | inget | ingen, alla |
| Pgms_wait_sampling.history_period | Anger frekvensen, i millisekunder, där väntehändelser samplas. | 100 | 1-600000 |
Kommentar
pg_qs.query_capture_mode ersätter pgms_wait_sampling.query_capture_mode. Om pg_qs.query_capture_mode är NONE har inställningen pgms_wait_sampling.query_capture_mode ingen effekt.
Använd Azure-portalen för att hämta eller ange ett annat värde för en parameter.
Vyer och funktioner
Visa och hantera Query Store med hjälp av följande vyer och funktioner. Alla i den offentliga Rollen PostgreSQL kan använda dessa vyer för att se data i Query Store. Dessa vyer är endast tillgängliga i azure_sys-databasen.
Frågor normaliseras genom att titta på deras struktur och ignorera allt som inte är semantiskt betydelsefullt, till exempel literaler, konstanter, alias eller skillnader i hölje.
Om två frågor är semantiskt identiska, även om de använder olika alias för samma refererade kolumner och tabeller, identifieras de med samma query_id. Om två frågor bara skiljer sig åt i de literalvärden som används i dem identifieras de också med samma query_id. För alla frågor som identifieras med samma query_id är deras sql_query_text den fråga som kördes först sedan Query Store startade inspelningsaktiviteten, eller sedan den senaste gången de sparade data togs bort eftersom funktionen query_store.qs_reset kördes.
Så här fungerar frågenormalisering
Här följer några exempel för att försöka illustrera hur den här normaliseringen fungerar:
Anta att du skapar en tabell med följande instruktion:
create table tableOne (columnOne int, columnTwo int);
Du aktiverar Query Store-datainsamling och en eller flera användare kör följande frågor i exakt den här ordningen:
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";
Alla tidigare frågor delar samma query_id. Och texten som Query Store behåller är den för den första frågan som körs efter aktivering av datainsamling. Därför skulle det vara select * from tableOne;.
Följande uppsättning frågor, när de har normaliserats, matchar inte den tidigare uppsättningen frågor eftersom WHERE-satsen gör dem semantiskt olika:
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;
Alla frågor i den senaste uppsättningen delar dock samma query_id och den text som används för att identifiera dem alla är den första frågan i batchen select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.
Slutligen hittar du nedan några frågor som inte matchar query_id av dem i föregående batch och orsaken till att de inte gör det:
Fråga:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
Orsak till att den inte matchar: Listan med kolumner refererar till samma två kolumner (columnOne och ColumnTwo), men ordningen som de refereras till är omvänd, från columnOne, ColumnTwo i föregående batch till ColumnTwo, columnOne i den här frågan.
Fråga:
select * from tableOne where columnTwo = 25 and columnOne = 25;
Orsak till att inte matcha: Ordningen där de uttryck som utvärderas i WHERE-satsen refereras återförs från columnOne = ? and ColumnTwo = ? i föregående batch till ColumnTwo = ? and columnOne = ? i den här frågan.
Fråga:
select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;
Orsak till att inte matcha: Det första uttrycket i kolumnlistan är inte columnOne längre, utan funktionen abs utvärderas över columnOne (abs(columnOne)), vilket inte är semantiskt likvärdigt.
Fråga:
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;
Orsak till att inte matcha: Det första uttrycket i WHERE-satsen utvärderar inte likheten columnOne med en literal längre, utan med resultatet av funktionen ceiling utvärderad över en literal, vilket inte är semantiskt likvärdigt.
Vyer
query_store.qs_view
Den här vyn returnerar alla data som redan har sparats i stödtabellerna i Query Store. Data som registreras i minnet för det aktiva tidsfönstret visas inte förrän tidsfönstret har upphört och dess minnesinterna data samlas in och sparas i tabeller som lagras på disken. Den här vyn returnerar en annan rad för varje distinkt databas (db_id), användare (user_id) och fråga (query_id).
| Namn | Typ | Referenser | Beskrivning |
|---|---|---|---|
| runtime_stats_entry_id | bigint | ID från tabellen runtime_stats_entries. | |
| user_id | Oid | pg_authid.oid | OID för användare som körde -instruktionen. |
| db_id | Oid | pg_database.oid | OID för databasen där -instruktionen kördes. |
| query_id | bigint | Intern hash-kod som beräknas från instruktionens parsningsträd. | |
| query_sql_text | varchar(10000) | Text för en representativ instruktion. Olika frågor med samma struktur grupperas tillsammans. den här texten är texten för den första av frågorna i klustret. Standardvärdet för den maximala frågetextlängden är 6 000 och kan ändras med frågelagringsparametern pg_qs.max_query_text_length. Om texten i frågan överskrider det maximala värdet trunkeras den till de första pg_qs.max_query_text_length tecknen. |
|
| plan_id | bigint | ID för planen som motsvarar den här frågan. | |
| start_time | timestamp | Frågor aggregeras efter tidsfönster, vars tidsintervall definieras av serverparametern pg_qs.interval_length_minutes (standardvärdet är 15 minuter). Det här är starttiden som motsvarar tidsfönstret för den här posten. |
|
| end_time | timestamp | Sluttid som motsvarar tidsfönstret för den här posten. | |
| Samtal | bigint | Antal gånger som frågan kördes i det här tidsfönstret. Observera att för parallella frågor motsvarar antalet anrop för varje körning 1 för serverdelsprocessen som driver körningen av frågan, plus lika många andra enheter för varje backend worker-process, som startas för att samarbeta för att köra de parallella grenarna i körningsträdet. | |
| total_time | dubbel precision | Total körningstid för frågor i millisekunder. | |
| min_time | dubbel precision | Minsta körningstid för frågor i millisekunder. | |
| max_time | dubbel precision | Maximal körningstid för frågor i millisekunder. | |
| mean_time | dubbel precision | Genomsnittlig körningstid för frågor i millisekunder. | |
| stddev_time | dubbel precision | Standardavvikelse för frågekörningstiden i millisekunder. | |
| rader | bigint | Totalt antal rader som hämtats eller påverkats av -instruktionen. Observera att för parallella frågor motsvarar antalet rader för varje körning det antal rader som returneras till klienten av backend-processen som driver körningen av frågan, plus summan av alla rader som varje serverdelsprocess, som startas för att samarbeta med att köra de parallella grenarna i körningsträdet, återgår till den drivande serverdelsprocessen. | |
| shared_blks_hit | bigint | Totalt antal delade blockcacheträffar av -instruktionen. | |
| shared_blks_read | bigint | Totalt antal delade block som lästs av -instruktionen. | |
| shared_blks_dirtied | bigint | Totalt antal delade block som smutsas in av -instruktionen. | |
| shared_blks_written | bigint | Totalt antal delade block som skrivits av -instruktionen. | |
| local_blks_hit | bigint | Totalt antal lokala blockcacheträffar av -instruktionen. | |
| local_blks_read | bigint | Totalt antal lokala block som lästs av -instruktionen. | |
| local_blks_dirtied | bigint | Totalt antal lokala block som smutsas in av -instruktionen. | |
| local_blks_written | bigint | Totalt antal lokala block som skrivits av -instruktionen. | |
| temp_blks_read | bigint | Totalt antal temporära block som lästs av -instruktionen. | |
| temp_blks_written | bigint | Totalt antal temporära block som skrivits av -instruktionen. | |
| blk_read_time | dubbel precision | Total tid som instruktionen spenderade på att läsa block, i millisekunder (om track_io_timing är aktiverad, annars noll). | |
| blk_write_time | dubbel precision | Total tid som instruktionen spenderade på att skriva block, i millisekunder (om track_io_timing är aktiverad, annars noll). | |
| is_system_query | boolean | Avgör om frågan kördes av roll med user_id = 10 (azuresu), som har superanvändarbehörighet och används för att utföra kontrollfönsteråtgärder. Eftersom den här tjänsten är en hanterad PaaS-tjänst är endast Microsoft en del av den superanvändarrollen. | |
| query_type | text | Typ av åtgärd som representeras av frågan. Möjliga värden är unknown, select, update, insert, delete, merge, utility, , nothing, undefined. |
query_store.query_texts_view
Den här vyn returnerar frågetextdata i Query Store. Det finns en rad för varje distinkt query_sql_text.
| Namn | Typ | Beskrivning |
|---|---|---|
| query_text_id | bigint | ID för tabellen query_texts |
| query_sql_text | varchar(10000) | Text för en representativ instruktion. Olika frågor med samma struktur grupperas tillsammans. den här texten är texten för den första av frågorna i klustret. |
| query_type | smallint | Typ av åtgärd som representeras av frågan. I versionen av PostgreSQL <= 14 är 0 möjliga värden (okända), 1 (välj), 2 (uppdatera), 3 (infoga), 4 (ta bort), 5 (verktyg) 6 (ingenting). I versionen av PostgreSQL >= 15 är 0 möjliga värden (okända), 1 (välj), 2 (uppdatera), 3 (infoga), 4 (ta bort), 5 (sammanfoga), 6 (verktyg), 7 (ingenting). |
query_store.pgms_wait_sampling_view
Den här vyn returnerar väntehändelser i Query Store. Den här vyn returnerar en annan rad för varje distinkt databas (db_id), användare (user_id), fråga (query_id) och händelse (händelse).
| Namn | Typ | Referenser | Beskrivning |
|---|---|---|---|
| start_time | timestamp | Frågor aggregeras efter tidsfönster, vars tidsintervall definieras av serverparametern pg_qs.interval_length_minutes (standardvärdet är 15 minuter). Det här är starttiden som motsvarar tidsfönstret för den här posten. |
|
| end_time | timestamp | Sluttid som motsvarar tidsfönstret för den här posten. | |
| user_id | Oid | pg_authid.oid | OID för användare som körde -instruktionen. |
| db_id | Oid | pg_database.oid | OID för databasen där -instruktionen kördes. |
| query_id | bigint | Intern hash-kod som beräknas från instruktionens parsningsträd. | |
| event_type | text | Den typ av händelse som serverdelen väntar på. | |
| händelse | text | Namnet på väntehändelsen om serverdelen för närvarande väntar. | |
| Samtal | integer | Antal gånger samma händelse har registrerats. |
Kommentar
En lista över möjliga värden i event_type- och händelsekolumnerna i vyn query_store.pgms_wait_sampling_view finns i den officiella dokumentationen för pg_stat_activity och letar efter information som refererar till kolumner med samma namn.
query_store.query_plans_view
Den här vyn returnerar den frågeplan som användes för att köra en fråga. Det finns en rad per varje distinkt databas-ID och fråge-ID. Detta lagrar endast frågeplaner för frågor som inte gäller för problem.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | bigint | Hash-värdet från den normaliserade frågeplanen som skapats av EXPLAIN. Den anses normaliserad eftersom den exkluderar de uppskattade kostnaderna för plannoder och användningen av buffertar. | |
| db_id | Oid | pg_database.oid | OID för databasen där -instruktionen kördes. |
| query_id | bigint | Intern hash-kod som beräknas från instruktionens parsningsträd. | |
| plan_text | varchar(10000) | Körningsplan för instruktionen given costs=false, buffers=false och format=text. Det här är samma utdata som ges av EXPLAIN. |
Functions
query_store.qs_reset
Den här funktionen tar bort all statistik som hittills samlats in av Query Store. Den tar bort både statistiken för redan stängda tidsfönster, som har sparats på disktabeller, och de för det aktuella tidsfönstret, som fortfarande sparas i minnet. Den här funktionen kan bara köras av serveradministratörsrollen (azure_pg_admin).
query_store.staging_data_reset
Den här funktionen tar bort all statistik som samlas in i minnet av Query Store (det vill: de data i minnet som ännu inte har tömts till disktabellerna som stöder beständighet av insamlade data för Query Store). Den här funktionen kan bara köras av serveradministratörsrollen (azure_pg_admin).
Begränsningar och kända problem
Azure Storage- och Query Store-kompatibilitet
På grund av kompatibilitetsproblem kan du inte aktivera Azure Storage- och Query Store-tillägg samtidigt. För att säkerställa korrekt funktion och undvika potentiella konflikter aktiverar du bara ett av dessa tillägg i taget.
Så här använder du Azure Storage:
- Inaktivera Query Store genom att ange parametern
pg_qs.query_capture_modetillNONE. Den här parametern är dynamisk, så du behöver inte starta om.
Så här använder du Query Store:
- Inaktivera Azure Storage-tillägget genom att utfärda
DROP EXTENSION azure_storage;. - Ta bort Azure Storage från
shared_preload_libraries. - Starta om databasservern.
De här stegen är nödvändiga för att förhindra konflikter och för att säkerställa att systemet fungerar korrekt. Vi arbetar med att lösa dessa kompatibilitetsproblem och håller dig informerad om eventuella uppdateringar.
Skrivskyddat läge
När en Azure Database for PostgreSQL – flexibel server-instans är i skrivskyddat läge, till exempel när parametern default_transaction_read_only är inställd på on, eller om skrivskyddat läge aktiveras automatiskt på grund av att lagringskapaciteten har nåtts, samlar Query Store inte in några data.