Prestaties bewaken met Query Store
VAN TOEPASSING OP:
Azure Database for PostgreSQL - Flexibele server
De functie Query Store in azure Database for PostgreSQL flexibele server biedt een manier om queryprestaties in de loop van de tijd bij te houden. Query Store vereenvoudigt het oplossen van prestatieproblemen doordat u snel de langst lopende en meest resource-intensieve query's kunt vinden. Query Store legt automatisch een geschiedenis van query's en runtimestatistieken vast en behoudt deze voor uw beoordeling. Hiermee worden de gegevens gesegmenteerd op tijd, zodat u tijdelijke gebruikspatronen kunt zien. Gegevens voor alle gebruikers, databases en query's worden opgeslagen in een database met de naam azure_sys in het flexibele serverexemplaren van Azure Database for PostgreSQL.
Belangrijk
Wijzig de azure_sys database of het bijbehorende schema niet. Als u dit doet, werken Query Store en gerelateerde prestatiefuncties niet goed.
Query Store inschakelen
Query Store is beschikbaar in alle regio's zonder extra kosten. Het is een opt-in-functie, dus deze is niet standaard ingeschakeld op een server. Querystore kan globaal worden ingeschakeld of uitgeschakeld voor alle databases op een bepaalde server en kan niet per database worden ingeschakeld of uitgeschakeld.
Belangrijk
Schakel Query Store niet in op de prijscategorie Burstable, omdat dit invloed zou hebben op de prestaties.
Query Store inschakelen in Azure Portal
- Meld u aan bij Azure Portal en selecteer uw exemplaar van flexibele Azure Database for PostgreSQL-server.
- Selecteer Serverparameters in de sectie Instellingen van het menu.
- Zoek de
pg_qs.query_capture_modeparameter. - Stel de waarde in op
TOPofALL, afhankelijk van of u query's op het hoogste niveau of geneste query's wilt bijhouden (die worden uitgevoerd in een functie of procedure) en klik op Opslaan. Wacht 20 minuten tot de eerste batch met gegevens is vastgelegd in database azure_sys.
Query Store wachtsampling inschakelen
- Zoek de
pgms_wait_sampling.query_capture_modeparameter. - Stel de waarde in op
ALLen sla deze op.
Informatie in Query Store
Query Store bestaat uit twee winkels:
- Een runtimestatistiekenarchief voor het persistent maken van de gegevens van de queryuitvoeringsstatistieken.
- Een wachtstatistiekenarchief voor persistente informatie over wachtstatistieken.
Veelvoorkomende scenario's voor het gebruik van Query Store zijn:
- Bepalen hoe vaak een query in een bepaald tijdvenster is uitgevoerd.
- Vergelijk de gemiddelde uitvoeringstijd van een query in tijdvensters om grote verschillen te zien.
- Het identificeren van langst lopende query's in de afgelopen uren.
- De belangrijkste N-query's identificeren die op resources wachten.
- Inzicht in de wachtaard voor een bepaalde query.
Om het ruimtegebruik te minimaliseren, worden de uitvoeringsstatistieken van runtime in het archief met runtimestatistieken geaggregeerd in een vast, configureerbaar tijdvenster. De informatie in deze winkels kan worden opgevraagd met behulp van weergaven.
Query Store-gegevens openen
Query Store-gegevens worden opgeslagen in de azure_sys-database op uw flexibele serverexemplaren van Azure Database for PostgreSQL. De volgende query retourneert informatie over query's in Query Store:
SELECT * FROM query_store.qs_view;
Of deze query voor wachtstatistieken:
SELECT * FROM query_store.pgms_wait_sampling_view;
Wachtquery's zoeken
Wachtgebeurtenissen combineren verschillende wachtgebeurtenissen in buckets op gelijkenis. Query Store biedt het wacht-gebeurtenistype, de specifieke naam van de wacht gebeurtenis en de betreffende query. Als u deze wachtinformatie kunt correleren met de statistieken van de queryruntime, krijgt u meer inzicht in wat bijdraagt aan de prestatiekenmerken van query's.
Hier volgen enkele voorbeelden van hoe u meer inzicht krijgt in uw workload met behulp van de wachtstatistieken in Query Store:
| Observatie | Actie |
|---|---|
| Hoge vergrendelingswachttijden | Controleer de queryteksten voor de betrokken query's en identificeer de doelentiteiten. Zoek in Query Store naar andere query's die dezelfde entiteit wijzigen, die regelmatig wordt uitgevoerd en/of een hoge duur hebben. Nadat u deze query's hebt geïdentificeerd, kunt u overwegen de toepassingslogica te wijzigen om gelijktijdigheid te verbeteren of een minder beperkend isolatieniveau te gebruiken. |
| IO-wachttijden met hoge buffer | Zoek de query's met een groot aantal fysieke leesbewerkingen in Query Store. Als ze overeenkomen met de query's met hoge IO-wachttijden, kunt u overwegen om een index op de onderliggende entiteit te introduceren om te zoeken in plaats van scans. Hierdoor wordt de IO-overhead van de query's geminimaliseerd. Controleer de prestatie-Aanbevelingen voor uw server in de portal om te zien of er indexaankopen zijn voor deze server waarmee de query's worden geoptimaliseerd. |
| Wachttijden met hoog geheugen | Zoek de query's die het meest veel geheugen verbruiken in Query Store. Deze query's vertragen waarschijnlijk verdere voortgang van de betrokken query's. Controleer de prestatie-Aanbevelingen voor uw server in de portal om te zien of er indexaankopen zijn die deze query's zouden optimaliseren. |
Configuratieopties
Wanneer Query Store is ingeschakeld, worden gegevens opgeslagen in aggregatievensters van lengte die worden bepaald door de pg_qs.interval_length_minutes serverparameter (standaard ingesteld op 15 minuten). Voor elk venster worden de 500 afzonderlijke query's per venster opgeslagen.
De volgende opties zijn beschikbaar voor het configureren van Query Store-parameters:
| Parameter | Beschrijving | Standaard | Bereik |
|---|---|---|---|
| pg_qs.query_capture_mode | Hiermee stelt u in welke instructies worden bijgehouden. | Geen | none, top, all |
| pg_qs.interval_length_minutes (*) | Hiermee stelt u het interval voor het vastleggen van query_store in minuten in voor pg_qs. Dit is de frequentie van gegevenspersistentie. | 15 | 1 - 30 |
| pg_qs.store_query_plans | Hiermee schakelt u het opslaan van queryplannen in of uit voor pg_qs. | uit | aan, uit |
| pg_qs.max_plan_size | Hiermee stelt u het maximum aantal bytes in dat wordt opgeslagen voor queryplantekst voor pg_qs; langere abonnementen worden afgekapt. | 7500 | 100 - 10k |
| pg_qs.max_query_text_length | Hiermee stelt u de maximale querylengte in die kan worden opgeslagen; langere query's worden afgekapt. | 6000 | 100 - 10K |
| pg_qs.retention_period_in_days | Hiermee stelt u het bewaarperiodevenster in dagen voor pg_qs in. Na deze tijd worden gegevens verwijderd. | 7 | 1 - 30 |
| pg_qs.track_utility | Hiermee stelt u in of hulpprogrammaopdrachten worden bijgehouden door pg_qs. | op | aan, uit |
(*) Statische serverparameter waarvoor een server opnieuw moet worden opgestart voor een wijziging in de waarde ervan, wordt van kracht.
De volgende opties zijn specifiek van toepassing op wachtstatistieken:
| Parameter | Beschrijving | Standaard | Bereik |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | Selecteert welke instructies worden bijgehouden door de pgms_wait_sampling-extensie. | Geen | geen, alle |
| Pgms_wait_sampling.history_period | Hiermee stelt u de frequentie in milliseconden in, waarbij wachtgebeurtenissen worden bemonsterd. | 100 | 1-600000 |
Notitie
pg_qs.query_capture_mode vervangt pgms_wait_sampling.query_capture_mode. Als pg_qs.query_capture_mode NONE is, heeft de instelling pgms_wait_sampling.query_capture_mode geen effect.
Gebruik Azure Portal om een andere waarde voor een parameter op te halen of in te stellen.
Weergaven en functies
Query Store weergeven en beheren met behulp van de volgende weergaven en functies. Iedereen in de openbare PostgreSQL-rol kan deze weergaven gebruiken om de gegevens in Query Store te bekijken. Deze weergaven zijn alleen beschikbaar in de azure_sys-database .
Query's worden genormaliseerd door naar hun structuur te kijken en niets te negeren dat niet semantisch significant is, zoals letterlijke, constanten, aliassen of verschillen in hoofdletters.
Als twee query's s semantisch identiek zijn, zelfs als ze verschillende aliassen gebruiken voor dezelfde kolommen en tabellen waarnaar wordt verwezen, worden ze geïdentificeerd met dezelfde query_id. Als twee query's alleen verschillen in de letterlijke waarden die in deze query's worden gebruikt, worden ze ook geïdentificeerd met dezelfde query_id. Voor alle query's die zijn geïdentificeerd met dezelfde query_id, is hun sql_query_text die van de query die het eerst wordt uitgevoerd sinds Query Store de opnameactiviteit heeft gestart of sinds de laatste keer dat de persistente gegevens zijn verwijderd omdat de functie query_store.qs_reset is uitgevoerd.
Hoe querynormalisatie werkt
Hier volgen enkele voorbeelden om te illustreren hoe deze normalisatie werkt:
Stel dat u een tabel maakt met de volgende instructie:
create table tableOne (columnOne int, columnTwo int);
U schakelt Query Store-gegevensverzameling in en één of meerdere gebruikers voeren de volgende query's uit, in deze exacte volgorde:
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";
Alle vorige query's delen dezelfde query_id. En de tekst die Query Store bewaart, is die van de eerste query die wordt uitgevoerd na het inschakelen van gegevensverzameling. Daarom zou het zijn select * from tableOne;.
De volgende set query's, zodra genormaliseerd, komt niet overeen met de vorige set query's, omdat de WHERE-component ze semantisch anders maakt:
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;
Alle query's in deze laatste set delen echter dezelfde query_id en de tekst die wordt gebruikt om ze allemaal te identificeren, is dat van de eerste query in de batch select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.
Ten slotte vindt u hieronder enkele query's die niet overeenkomen met de query_id van die in de vorige batch, en de reden waarom ze niet:
Query:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
Reden om niet overeen te komen: lijst met kolommen verwijst naar dezelfde twee kolommen (columnOne en ColumnTwo), maar de volgorde waarin ze worden verwezen, wordt omgekeerd, van columnOne, ColumnTwo in de vorige batch naar ColumnTwo, columnOne in deze query.
Query:
select * from tableOne where columnTwo = 25 and columnOne = 25;
Reden om niet overeen te komen: volgorde waarin de expressies die in de WHERE-component worden geëvalueerd, worden omgekeerd van columnOne = ? and ColumnTwo = ? in de vorige batch naar ColumnTwo = ? and columnOne = ? in deze query.
Query:
select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;
Reden om niet overeen te komen: de eerste expressie in de kolomlijst is niet columnOne meer, maar de functie abs wordt geëvalueerd over columnOne (abs(columnOne)), wat niet semantisch equivalent is.
Query:
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;
Reden om niet overeen te komen: De eerste expressie in de WHERE-component evalueert niet meer de gelijkheid van columnOne een letterlijke waarde, maar met het resultaat van de functie ceiling die wordt geëvalueerd over een letterlijke waarde, wat niet semantisch equivalent is.
Weergaven
query_store.qs_view
Deze weergave retourneert alle gegevens die al zijn opgeslagen in de ondersteunende tabellen van Query Store. Gegevens die in het geheugen worden vastgelegd voor het momenteel actieve tijdvenster, zijn pas zichtbaar als het tijdvenster aan een einde komt en de vluchtige gegevens in het geheugen worden verzameld en bewaard in tabellen die op schijf zijn opgeslagen. Deze weergave retourneert een andere rij voor elke afzonderlijke database (db_id), gebruiker (user_id) en query (query_id).
| Naam | Type | Naslaginformatie | Beschrijving |
|---|---|---|---|
| runtime_stats_entry_id | bigint | Id uit de runtime_stats_entries tabel. | |
| user_id | oid | pg_authid.oid | OID van de gebruiker die de instructie heeft uitgevoerd. |
| db_id | oid | pg_database.oid | OID van de database waarin de instructie is uitgevoerd. |
| query_id | bigint | Interne hashcode, berekend op basis van de parseringsstructuur van de instructie. | |
| query_sql_text | varchar(10000) | Tekst van een representatieve verklaring. Verschillende query's met dezelfde structuur worden samen geclusterd; deze tekst is de tekst voor de eerste van de query's in het cluster. De standaardwaarde voor de maximale lengte van querytekst is 6000 en kan worden gewijzigd met de query store-parameter pg_qs.max_query_text_length. Als de tekst van de query deze maximumwaarde overschrijdt, wordt deze afgekapt tot de eerste pg_qs.max_query_text_length tekens. |
|
| plan_id | bigint | Id van het plan dat overeenkomt met deze query. | |
| begintijd | timestamp | Query's worden geaggregeerd op tijdvensters, waarvan de tijdsduur is gedefinieerd door de serverparameter pg_qs.interval_length_minutes (standaard is 15 minuten). Dit is de begintijd die overeenkomt met het tijdvenster voor deze vermelding. |
|
| end_time | timestamp | Eindtijd die overeenkomt met het tijdvenster voor deze vermelding. | |
| Oproepen | bigint | Aantal keren dat de query in dit tijdvenster wordt uitgevoerd. U ziet dat voor parallelle query's het aantal aanroepen voor elke uitvoering overeenkomt met 1 voor het back-endproces dat de uitvoering van de query aangeeft, plus net zoveel andere eenheden voor elk back-endwerkproces, dat wordt gestart om samen te werken aan de parallelle vertakkingen van de uitvoeringsstructuur. | |
| total_time | dubbele precisie | Totale uitvoeringstijd van query's, in milliseconden. | |
| min_time | dubbele precisie | Minimale uitvoeringstijd van query's, in milliseconden. | |
| max_time | dubbele precisie | Maximale uitvoeringstijd van query's, in milliseconden. | |
| mean_time | dubbele precisie | Gemiddelde uitvoeringstijd van query's, in milliseconden. | |
| stddev_time | dubbele precisie | Standaarddeviatie van de uitvoeringstijd van de query, in milliseconden. | |
| rijen | bigint | Het totale aantal rijen dat is opgehaald of beïnvloed door de instructie. U ziet dat voor parallelle query's het aantal rijen voor elke uitvoering overeenkomt met het aantal rijen dat door het back-endproces wordt geretourneerd aan de client, waardoor de uitvoering van de query wordt uitgevoerd, plus de som van alle rijen die elk back-endwerkproces zijn gestart om samen te werken aan het uitvoeren van de parallelle vertakkingen van de uitvoeringsstructuur, terugkeert naar het rijdende back-endproces. | |
| shared_blks_hit | bigint | Het totale aantal gedeelde blokcachetreffers door de instructie. | |
| shared_blks_read | bigint | Het totale aantal gedeelde blokken dat door de instructie is gelezen. | |
| shared_blks_dirtied | bigint | Het totale aantal gedeelde blokken dat door de instructie wordt veroorzaakt. | |
| shared_blks_written | bigint | Het totale aantal gedeelde blokken dat door de instructie is geschreven. | |
| local_blks_hit | bigint | Totaal aantal lokale blokcachetreffers door de instructie. | |
| local_blks_read | bigint | Het totale aantal lokale blokken dat door de instructie is gelezen. | |
| local_blks_dirtied | bigint | Het totale aantal lokale blokken dat door de instructie wordt veroorzaakt. | |
| local_blks_written | bigint | Totaal aantal lokale blokken dat door de instructie is geschreven. | |
| temp_blks_read | bigint | Totaal aantal tijdelijke blokken dat door de instructie wordt gelezen. | |
| temp_blks_written | bigint | Totaal aantal tijdelijke blokken dat door de instructie is geschreven. | |
| blk_read_time | dubbele precisie | Totale tijd die de instructie heeft besteed aan leesblokken, in milliseconden (als track_io_timing is ingeschakeld, anders nul). | |
| blk_write_time | dubbele precisie | Totale tijd die de instructie heeft besteed aan het schrijven van blokken, in milliseconden (als track_io_timing is ingeschakeld, anders nul). | |
| is_system_query | boolean | Bepaalt of de query is uitgevoerd op rol met user_id = 10 (azuresu), die supergebruikersbevoegdheden heeft en wordt gebruikt om bewerkingen in het besturingsvenster uit te voeren. Omdat deze service een beheerde PaaS-service is, maakt alleen Microsoft deel uit van die supergebruikerrol. | |
| query_type | sms verzenden | Type bewerking dat wordt vertegenwoordigd door de query. Mogelijke waarden zijnunknown, select, update, , insert, delete, merge, utility, , nothing. undefined |
query_store.query_texts_view
Deze weergave retourneert querytekstgegevens in Query Store. Er is één rij voor elke afzonderlijke query_sql_text.
| Naam | Type | Beschrijving |
|---|---|---|
| query_text_id | bigint | Id voor de query_texts tabel |
| query_sql_text | varchar(10000) | Tekst van een representatieve verklaring. Verschillende query's met dezelfde structuur worden samen geclusterd; deze tekst is de tekst voor de eerste van de query's in het cluster. |
| query_type | smallint | Type bewerking dat wordt vertegenwoordigd door de query. In versie van PostgreSQL <= 14 zijn 0 mogelijke waarden (onbekend), 1 (select), 2 (update), (insert), 34 (delete), (utility), 56 (niets). In versie van PostgreSQL >= 15 zijn 0 mogelijke waarden (onbekend), 1 (select), 2 (update), (invoegen), 34 (verwijderen), (samenvoegen), 56 (hulpprogramma), 7 (niets). |
query_store.pgms_wait_sampling_view
Deze weergave retourneert wacht gebeurtenisgegevens in Query Store. Deze weergave retourneert een andere rij voor elke afzonderlijke database (db_id), gebruiker (user_id), query (query_id) en gebeurtenis (gebeurtenis).
| Naam | Type | Naslaginformatie | Beschrijving |
|---|---|---|---|
| begintijd | timestamp | Query's worden geaggregeerd op tijdvensters, waarvan de tijdsduur is gedefinieerd door de serverparameter pg_qs.interval_length_minutes (standaard is 15 minuten). Dit is de begintijd die overeenkomt met het tijdvenster voor deze vermelding. |
|
| end_time | timestamp | Eindtijd die overeenkomt met het tijdvenster voor deze vermelding. | |
| user_id | oid | pg_authid.oid | OID van de gebruiker die de instructie heeft uitgevoerd. |
| db_id | oid | pg_database.oid | OID van de database waarin de instructie is uitgevoerd. |
| query_id | bigint | Interne hashcode, berekend op basis van de parseringsstructuur van de instructie. | |
| event_type | sms verzenden | Het type gebeurtenis waarvoor de back-end wacht. | |
| gebeurtenis | sms verzenden | De naam van de wacht gebeurtenis als de back-end momenteel wacht. | |
| Oproepen | geheel getal | Aantal keren dat dezelfde gebeurtenis is vastgelegd. |
Notitie
Raadpleeg de officiële documentatie van pg_stat_activity voor een lijst met mogelijke waarden in de event_type- en gebeurteniskolommen van de weergave query_store.pgms_wait_sampling_view en zoek naar de informatie die verwijst naar kolommen met dezelfde namen.
query_store.query_plans_view
Deze weergave retourneert het queryplan dat is gebruikt om een query uit te voeren. Er is één rij per afzonderlijke database-id en query-id. Hiermee worden alleen queryplannen opgeslagen voor niet-gebruikte query's.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | bigint | De hashwaarde van het genormaliseerde queryplan dat wordt geproduceerd door EXPLAIN. Het wordt als genormaliseerd beschouwd omdat de geschatte kosten van planknooppunten en het gebruik van buffers worden uitgesloten. | |
| db_id | oid | pg_database.oid | OID van de database waarin de instructie is uitgevoerd. |
| query_id | bigint | Interne hashcode, berekend op basis van de parseringsstructuur van de instructie. | |
| plan_text | varchar(10000) | Uitvoeringsplan van de instructie opgegeven kosten=false, buffers=false en format=text. Dit is dezelfde uitvoer die door EXPLAIN wordt gegeven. |
Functions
query_store.qs_reset
Met deze functie worden alle statistieken verwijderd die tot nu toe zijn verzameld door Query Store. Het verwijdert zowel de statistieken voor reeds gesloten tijdvensters, die zijn bewaard op schijftabellen, en die voor het huidige tijdvenster, die nog steeds in het geheugen worden bewaard. Deze functie kan alleen worden uitgevoerd door de serverbeheerdersrol (azure_pg_admin).
query_store.staging_data_reset
Met deze functie worden alle statistieken die in het geheugen zijn verzameld door Query Store verwijderd (de gegevens in het geheugen die nog niet zijn leeggemaakt naar de schijftabellen die persistentie van verzamelde gegevens voor Query Store ondersteunen). Deze functie kan alleen worden uitgevoerd door de serverbeheerdersrol (azure_pg_admin).
Beperkingen en bekende problemen
Compatibiliteit met Azure Storage en Query Store
Vanwege compatibiliteitsproblemen kunt u Azure Storage- en Query Store-extensies niet tegelijkertijd inschakelen. Schakel slechts één van deze extensies tegelijk in om een goede werking te garanderen en potentiële conflicten te voorkomen.
Azure Storage gebruiken:
- Schakel Query Store uit door de parameter
pg_qs.query_capture_modein te stellen opNONE. Deze parameter is dynamisch, dus u hoeft niet opnieuw op te starten.
Query Store gebruiken:
- Schakel de Azure Storage-extensie uit door deze uit te geven
DROP EXTENSION azure_storage;. - Verwijder Azure Storage uit
shared_preload_libraries. - Start de databaseserver opnieuw op.
Deze stappen zijn nodig om conflicten te voorkomen en ervoor te zorgen dat uw systeem correct werkt. We werken aan het oplossen van deze compatibiliteitsproblemen en houden u op de hoogte van eventuele updates.
Modus Alleen-lezen
Wanneer een Exemplaar van Azure Database for PostgreSQL - Flexible Server zich in de modus Alleen-lezen bevindt, zoals wanneer de default_transaction_read_only parameter is ingesteld onop, of als de modus Alleen-lezen automatisch wordt ingeschakeld vanwege het bereiken van de opslagcapaciteit, worden er geen gegevens vastgelegd in Query Store.