Mit bloßem Auge: auf einen Blick über PostgreSQL-Abfrageprobleme

Wir öffnen weiterhin für den öffentlichen Zugriff die neuen Funktionen unseres Dienstes zur Analyse von Abfrageausführungsplänen in PostgreSQL EXPLAIN.tensor.ru . Heute werden wir lernen, wunde Stellen in großen und komplexen Plänen sofort zu identifizieren, indem wir sie nur mit einem bewaffneten Auge betrachten ...





Verschiedene Visualisierungsoptionen helfen uns dabei :

Reduzierte Textansicht

Der ursprüngliche Text eines ziemlich einfachen Plans verursacht bereits Probleme bei der Analyse:







Daher bevorzugen wir die abgekürzte Form, wenn die Schlüsselinformationen über die Ausführungszeit und die verwendeten Puffer jedes Knotens links und rechts herausgenommen werden und die Maxima sehr leicht zu erkennen sind:

Kuchendiagramm

Aber manchmal ist es nicht einfach zu verstehen, wo es am meisten weh tut, besonders wenn es mehrere zehn Knoten enthält und selbst die verkürzte Form des Plans 2-3 Bildschirme benötigt.







In diesem Fall







hilft das übliche Kreisdiagramm: Sofort können Sie sofort den ungefähren Anteil des Ressourcenverbrauchs durch jeden der Knoten sehen. Wenn Sie den Mauszeiger darüber halten, sehen Sie links in der Textansicht ein Symbol für den ausgewählten Knoten.

Fliese

Leider zeigt das Kreisdiagramm nicht die Beziehung zwischen verschiedenen Knoten und den "heißesten" Punkten. Dafür ist die Option "Kachel" viel besser geeignet:

Ausführungsdiagramm

Beide Optionen zeigen jedoch nicht die gesamte Kette der Anhänge von Dienstknoten anCTE/InitPlain/SubPlan - sie sind nur im tatsächlichen Ausführungsdiagramm zu sehen:

Weitere Metriken erforderlich!

Wenn Sie den Plan der tatsächlichen Ausführung der Abfrage als aufnehmen EXPLAIN (ANALYZE), wird dort nur die verstrichene Zeit angezeigt . Aber sehr oft reicht dies nicht für korrekte Schlussfolgerungen!



Wenn Sie beispielsweise eine Abfrage in einem "kalten" Cache ausführen, erhalten Sie (aber Sie werden es nicht sehen!) Den Zeitpunkt des Empfangs von Daten von den Medien und überhaupt nicht die Arbeit der Abfrage selbst.



Daher ein paar Empfehlungen:

• Verwenden Sie diese Option , um das Volumen der abgezogenen Datenseiten anzuzeigen. Dieser Wert unterliegt praktisch keinen Schwankungen durch die Auslastung des Servers selbst und kann als Metrik für die Optimierung verwendet werden.EXPLAIN (ANALYZE, BUFFERS)
• Verwenden Sie track_io_timingdiese Option , um genau zu verstehen, wie lange es gedauert hat, mit dem Netzbetreiber zu arbeiten .

Wenn Ihr Plan nicht nur Zeit , sondern auch buffersoder enthält i/o timings, können Sie für jede der Diagrammoptionen in den Analysemodus für diese Metriken wechseln. Manchmal können Sie beispielsweise sofort feststellen, dass mehr als die Hälfte aller Messwerte auf einen einzelnen Problemknoten fielen:







Frühere Artikel zum Thema:

• Noch komfortableres Verständnis von PostgreSQL-Abfrageplänen
• Rezepte für angeschlagene SQL-Abfragen
• Worüber EXPLAIN schweigt und wie man ihn zum Reden bringt