Inleiding tot auto_explain:hoe trage Postgres-queryplannen automatisch te loggen

Wilt u weten waarom een ​​PostgreSQL-query traag is? Dan is EXPLAIN ANALYZE een prima startpunt. Maar queryplannen kunnen afhankelijk zijn van andere serveractiviteit, kunnen even duren om te worden uitgevoerd en kunnen in de loop van de tijd veranderen, dus als u de daadwerkelijke uitvoeringsplannen van uw langzaamste query's wilt zien, is auto_explain de tool die u nodig hebt. In dit bericht zullen we onderzoeken wat het doet, hoe het te configureren en hoe u die logboeken kunt gebruiken om uw zoekopdrachten te versnellen.

Wat is auto_explain?

auto_explain is een PostgreSQL-extensie waarmee u de queryplannen kunt loggen voor query's die langzamer zijn dan een (configureerbare) drempel. Dit is ongelooflijk handig voor het debuggen van langzame query's, vooral als ze soms problematisch zijn. Het is een van de bijdragemodules, dus het kan eenvoudig worden geïnstalleerd en geconfigureerd op reguliere PostgreSQL, en is zo handig dat we het standaard hebben ingeschakeld op ScaleGrid.

Grote dank aan Takahiro Itagaki, de hoofdauteur achter de eerste versie van auto_explain (commit, thread), Dean Rasheed, wiens eerste patch en suggestie het was, en de vele bijdragers en recensenten sindsdien.

Welke auto_explain-parameters moet ik gebruiken?

Hieronder bespreken we de belangrijkste parameters, maar bekijk de onderstaande tabel of de officiële documentatie voor meer informatie over de volledige reeks dingen die u kunt volgen.

De belangrijkste parameter voor auto_explain is log_min_duration . Standaard is dit ingesteld op -1 , wat betekent dat er niets wordt gelogd - dus als we wat logs willen, moeten we dit wijzigen! De standaardeenheid is ms, dus een instelling van 100 logt de queryplannen voor alle query's die de 100ms overschrijden. Dit is wat we als standaard hebben gekozen in ScaleGrid, maar het kan worden geconfigureerd onder Admin -> Config. Als u, om wat voor reden dan ook, het zoekplan voor elke zoekvraag wilt loggen, kunt u dit instellen op 0 – maar pas op, dit kan ernstige gevolgen hebben voor de prestaties.

Aangezien de query's al op de server worden uitgevoerd, wilt u waarschijnlijk ook auto_explain.log_analyze inschakelen . Dit maakt de uitvoer gelijk aan het uitvoeren van EXPLAIN ANALYZE . Standaard betekent dit ook dat timings per bewerking worden bijgehouden. Dit gaat gepaard met wat extra overhead, die kan worden geminimaliseerd door auto_explain.log_timing uit te schakelen (standaard aan met log_analyze ). Maar natuurlijk zijn timings per bewerking erg handig bij het debuggen van langzame query's! Onze interne tests hebben hiervoor acceptabele overheadkosten aangetoond, dus het is standaard ingeschakeld in ScaleGrid, maar test zoals altijd uw werkbelasting om te zien of de overhead in uw geval acceptabel is. Er is momenteel beperkte openbaar beschikbare informatie over dit onderwerp, maar een recent bericht van het pgMustard-team toonde aan dat, in ieder geval bij een kleine transactiebelasting, de overhead zo laag kan zijn als 2%. Zoals ze opmerkten, zou dit kunnen worden verminderd met de auto_explain.sample_rate parameter, ten koste van het bijhouden van een subset van uw zoekopdrachten.

De laatste parameter die we wat gedetailleerder zullen bespreken, is auto_explain.log_format . De standaarduitvoer is TEKST, wat waarschijnlijk het meest bekend is bij het gebruik van EXPLAIN .

Hier is een eenvoudig voorbeeld van hoe auto_explain-uitvoer in TEXT-indeling eruit kan zien:

2021-09-10 15:32:04.606 BST [22770] LOG:  duration: 3184.383 ms  plan:
	Query Text: select * from table1 order by column1;
	Sort  (cost=12875.92..13125.92 rows=100000 width=37) (actual time=2703.799..3055.401 rows=100000 loops=1)
	  Sort Key: column1
	  Sort Method: external merge  Disk: 4696kB
	  Buffers: shared hit=837, temp read=587 written=589
	  ->  Seq Scan on table  (cost=0.00..1834.01 rows=100000 width=37) (actual time=0.033..27.795 rows=100000 loops=1)
	        Buffers: shared hit=834

Hier kunt u zien dat u de duur van de zoekopdracht aan het begin krijgt, wat u normaal gesproken aan het einde van queryplannen gewend bent. U ziet ook de vraagtekst, inclusief eventuele parameters.

De populaire visualisatietools Explain.depesz en Explain.dalibo accepteren beide queryplannen in TEXT-indeling, maar ze ondersteunen beide ook JSON-indeling. Als een deel van je team liever tools zoals PEV en pgMustard gebruikt, die alleen het JSON-formaat ondersteunen, wil je dat misschien als het formaat instellen. Voor klanten op ScaleGrid hebben we gekozen voor het JSON-formaat, deels omdat we het gemakkelijker wilden ontleden voor onze eigen langzame query-analysefunctie.

Hier is een volledige lijst van de auto_explain-parameters en hun standaardwaarden:

Auto_explain installeren

Op ScaleGrid is auto_explain standaard ingeschakeld, met een drempel van 100 ms. U kunt dit configureren onder Admin -> Config.

Op vanilla PostgreSQL kunt u auto_explain installeren door het eenvoudig toe te voegen aan een van de session_preload_libraries of shared_preload_libraries . De eerste heeft de voordelen dat a) geen herstart nodig is (maar alleen in nieuwe sessies wordt geladen) en b) het mogelijk maakt om het alleen voor sommige gebruikers in te schakelen (door deze parameter in te stellen met ALTER ROLE SET ).

Als zodanig zou een basisconfiguratie voor auto_explain er als volgt uit kunnen zien:

session_preload_libraries = auto_explain
auto_explain.log_min_duration = 100
auto_explain.log_analyze = true
auto_explain.log_buffers = true
auto_explain.log_format = JSON

Als je een andere hostingprovider gebruikt, is het de moeite waard om te controleren of deze auto_explain ondersteunt. RDS Postgres doet dat bijvoorbeeld, maar in tegenstelling tot ScaleGrid is het standaard uitgeschakeld, dus u moet de configuratie bewerken om het te laten werken.

Auto_explain in één sessie laden

Als je niet wilt dat auto_explain automatisch in sessies wordt uitgevoerd, heb je als supergebruiker ook de mogelijkheid om het in een enkele sessie te laden:

LOAD 'auto_explain';

Dit kan ontzettend handig zijn voor eenmalige foutopsporingssessies, maar is natuurlijk niet nodig als je het al kunt laten draaien.

auto_explain beperkingen en valkuilen

We hebben er al enkele terloops genoemd, maar het lijkt een verstandig moment om onszelf te herinneren aan enkele nadelen en beperkingen van auto_explain.

Ten eerste, vooral bij het bijhouden van timings per bewerking, kan er meetbare overhead zijn bij het gebruik van auto_explain. Het kan laag zijn, zelfs als de timing wordt gemeten, maar zoals altijd is het de moeite waard om zelf te testen.

Ten tweede zijn auto_explain-timings exclusief de planningstijd voor query's. De planningstijd is vaak klein bij langzame zoekopdrachten, maar in uitzonderlijke gevallen kan dit verantwoordelijk zijn voor het grootste deel van het probleem. Houd er daarom rekening mee dat deze gevallen mogelijk niet in uw logboeken worden weergegeven, of als ze dat wel doen, een discrepantie met wat u in totale latentie ziet, te maken kan hebben met de planningstijd. Een handleiding EXPLAIN ANALYZE zal je snel helpen dit te herkennen.

Hoe de uitvoer uit te leggen om zoekopdrachten te versnellen

Zodra je de uitvoer van de uitleg voor je langzaamste zoekopdrachten hebt, kun je beginnen met het versnellen ervan!

U moet de queryplannen uit de logboeken halen, waarvoor u pgBadger kunt gebruiken als u geen beheerde service gebruikt die dit voor u doet.

Het beoordelen van EXPLAIN-plannen is een groot onderwerp op zich. De PostgreSQL-documentatie bevat een goede maar korte introductie tot het gebruik van EXPLAIN, en het artikel van Thoughbot over het lezen van EXPLAIN ANALYZE is een goede volgende stap. Als je liever een gesprek van een uur wilt, was EXPLAIN Explained door Josh Berkus uitstekend. Voor meer informatie heeft Depesz een reeks berichten genaamd Explaining the unexplainable en het pgMustard-team heeft een vrij uitgebreide EXPLAIN-woordenlijst.

Als je hulp nodig hebt van PostgreSQL-experts om je databases te beheren en je langzame query's te versnellen, probeer dan ScaleGrid. We bieden gratis 24/7 ondersteuning op ondernemingsniveau die u door deze langzame vragen kan leiden en u kan helpen om ze allemaal te optimaliseren. Onze gratis proefperiode van 30 dagen geeft je voldoende tijd om onze vele functies voor PostgreSQL en onze andere ondersteunde databases uit te proberen.

We hopen dat dit je alles geeft wat je nodig hebt om aan de slag te gaan met auto_explain en om trage vragen die je hebt te versnellen. Als je nog iets wilt weten, neem dan contact met ons op.