{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Grundlagen der PostgreSQL-\u00dcberwachung. Alexey Lesovskiy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich lade Sie ein, sich mit der Pr\u00e4sentation von Alexey Lesovsky von Data Egret \"Grundlagen der PostgreSQL-\u00dcberwachung\" vertraut zu machen.<\/strong><\/p>\n

<\/p>\n

In dieser Pr\u00e4sentation wird Alexey Lesovsky die Schl\u00fcsselpunkte der PostgreSQL-Statistiken erl\u00e4utern, was sie bedeuten und warum sie in der \u00dcberwachung wichtig sind. Er wird darauf eingehen, welche Grafiken in der \u00dcberwachung enthalten sein sollten, wie man sie hinzuf\u00fcgt und wie man sie interpretiert. Die Pr\u00e4sentation ist f\u00fcr Datenbankadministratoren, Systemadministratoren und Entwickler, die sich f\u00fcr die Fehlersuche in PostgreSQL interessieren, von gro\u00dfem Nutzen.<\/p>\n

\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Mein Name ist Alexey Lesovskiy und ich vertrete das Unternehmen Data Egret. <\/p>\n

<\/p>\n

Ein paar Worte \u00fcber mich. Ich habe einst vor vielen Jahren als Systemadministrator angefangen. <\/p>\n

<\/p>\n

Ich habe verschiedene Linux-Systeme administriert, mich mit verschiedenen Linux-bezogenen Themen, wie Virtualisierung und \u00dcberwachung, besch\u00e4ftigt und mit Proxys gearbeitet. Aber irgendwann habe ich mich mehr mit Datenbanken besch\u00e4ftigt, insbesondere mit PostgreSQL. Es hat mir sehr gefallen. Schlie\u00dflich habe ich den Gro\u00dfteil meiner Arbeitszeit mit PostgreSQL verbracht und bin so allm\u00e4hlich PostgreSQL DBA geworden.<\/p>\n

<\/p>\n

In meiner gesamten Karriere haben mich immer die Themen Statistik, Monitoring und Telemetriedaten interessiert. W\u00e4hrend meiner Zeit als Systemadministrator habe ich mich intensiv mit Zabbix besch\u00e4ftigt und ein kleines Set an Skripten geschrieben, das zabbix-extensions<\/a><\/noindex>. Es erlangte zu seiner Zeit recht gro\u00dfe Beliebtheit. Damit konnte man eine Vielzahl von wichtigen Aspekten \u00fcberwachen, nicht nur Linux, sondern auch verschiedene andere Komponenten.<\/p>\n

<\/p>\n

Zurzeit arbeite ich mit PostgreSQL. Ich entwickle ein anderes Tool, das die Arbeit mit PostgreSQL-Statistiken erm\u00f6glicht. Es hei\u00dft pgCenter<\/a><\/noindex> (Artikel auf Habr \u2014 Postgres-Statistiken ohne Stress und Aufwand<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Eine kurze Einf\u00fchrung. Welche Situationen treten bei unseren Kunden auf? Es kommt zu einem Vorfall mit der Datenbank. Nachdem die Datenbank wiederhergestellt wurde, kommt der Abteilungsleiter oder der Entwicklungsleiter und sagt: \u201eFreunde, wir sollten die Datenbank \u00fcberwachen, denn es ist etwas Schlimmes passiert und wir m\u00fcssen verhindern, dass so etwas in Zukunft nochmals passiert.\u201c Hier beginnt der spannende Prozess, ein \u00dcberwachungssystem auszuw\u00e4hlen oder ein bestehendes System anzupassen, um die eigene Datenbank \u2013 sei es PostgreSQL, MySQL oder eine andere \u2013 zu \u00fcberwachen. Die Kollegen fangen an, Vorschl\u00e4ge zu machen: \u201eIch habe geh\u00f6rt, dass es diese oder jene Datenbank gibt. Lasst uns die nutzen.\u201c Die Kollegen fangen an, untereinander zu streiten. Am Ende w\u00e4hlen wir eine Datenbank aus, aber die \u00dcberwachung von PostgreSQL ist darin ziemlich schwach ausgepr\u00e4gt, sodass st\u00e4ndig Anpassungen notwendig sind. Man muss bestimmte Repositories von GitHub herunterladen, sie klonen, Skripte anpassen und wie auch immer nachjustieren. Letztlich f\u00fchrt dies zu einer Menge manueller Arbeit. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

In diesem Bericht werde ich Ihnen vermitteln, wie Sie Monitoring-L\u00f6sungen nicht nur f\u00fcr PostgreSQL, sondern auch f\u00fcr andere Datenbanken ausw\u00e4hlen k\u00f6nnen. Ziel ist es, Ihr Monitoring so zu optimieren, dass Sie daraus echten Nutzen ziehen k\u00f6nnen, um Ihre Datenbank effektiv zu \u00fcberwachen und rechtzeitig auf bevorstehende Probleme oder Ausf\u00e4lle reagieren zu k\u00f6nnen. <\/p>\n

<\/p>\n

Die Ideen in diesem Bericht lassen sich direkt auf jede Datenbank anwenden, sei es eine relationale Datenbank oder NoSQL. Daher werden nicht nur Aspekte von PostgreSQL behandelt; Sie finden auch viele Ans\u00e4tze, wie Sie Monitoring in PostgreSQL umsetzen k\u00f6nnen. Es werden Abfragebeispiele und Entit\u00e4ten gezeigt, die in PostgreSQL f\u00fcr das Monitoring zur Verf\u00fcgung stehen. Wenn Ihre Datenbank \u00e4hnliche Funktionen bietet, die Sie in Ihr Monitoring integrieren k\u00f6nnen, k\u00f6nnen Sie diese ebenfalls adaptieren und umsetzen.<\/p>\n

<\/p>\n

\"GrundlagenIn dem Bericht werde ich nicht
\ndarlegen, wie Metriken erfasst und gespeichert werden. Ich werde nichts \u00fcber die Datenverarbeitung und deren Bereitstellung f\u00fcr den Benutzer sagen und auch nichts \u00fcber das Alerting erw\u00e4hnen.
\nIm Verlauf des Berichts werde ich verschiedene Screenshots bestehender Monitoring-Tools zeigen und diese kritisieren. Dennoch werde ich versuchen, keine Marken zu nennen, um keine Werbung oder gegen diese Produkte gerichtete Werbung zu machen. Daher sind alle \u00dcbereinstimmungen zuf\u00e4llig und dem Leser \u00fcberlassen.
\n\"Grundlagen
\nLassen Sie uns zun\u00e4chst kl\u00e4ren, was Monitoring bedeutet. Monitoring ist ein \u00e4u\u00dferst wichtiges Element, das jeder haben sollte. Das ist allgemein bekannt. Aber gleichzeitig z\u00e4hlt Monitoring nicht als direktes Gesch\u00e4ftsprodukt und hat keinen unmittelbaren Einfluss auf den Gewinn eines Unternehmens. Daher wird Monitoring oft nur nachrangig behandelt. Wenn wir Zeit haben, k\u00fcmmern wir uns um das Monitoring; wenn nicht, dann bleibt es einfach im Backlog und wird irgendwann sp\u00e4ter angegangen. <\/p>\n

<\/p>\n

In unserer Erfahrung, wenn wir zu Kunden kommen, ist das Monitoring h\u00e4ufig unvollst\u00e4ndig und weist keine interessanten Funktionen auf, die uns bei der Arbeit mit der Datenbank helfen k\u00f6nnten. Daher muss das Monitoring immer weiter verbessert werden. <\/p>\n

<\/p>\n

Datenbanken sind komplexe Systeme, die ebenfalls \u00fcberwacht werden m\u00fcssen, da sie als Informationsspeicher fungieren. Informationen sind f\u00fcr ein Unternehmen von gro\u00dfer Bedeutung und d\u00fcrfen nicht verloren gehen. Gleichzeitig sind Datenbanken jedoch sehr komplexe Softwarekomponenten, die aus zahlreichen Elementen bestehen, von denen viele \u00fcberwacht werden m\u00fcssen. <\/p>\n

<\/p>\n

\"GrundlagenBetrachten wir konkret PostgreSQL, so l\u00e4sst es sich als ein Schema darstellen, das aus vielen Komponenten besteht. Diese Komponenten interagieren miteinander. Zudem gibt es in PostgreSQL das sogenannte Stats Collector-System, das es erm\u00f6glicht, Statistiken \u00fcber die Leistung dieser Subsysteme zu sammeln und dem Administrator oder Benutzer eine Schnittstelle zu bieten, um diese Statistiken einzusehen. <\/p>\n

<\/p>\n

Diese Statistiken werden in Form eines Satzes von Funktionen und Views pr\u00e4sentiert, die auch als Tabellen bezeichnet werden k\u00f6nnen. Mit einem herk\u00f6mmlichen psql-Client k\u00f6nnen Sie sich mit der Datenbank verbinden, diese Funktionen und Views abfragen und konkrete Zahlen zur Leistung der PostgreSQL-Subsysteme erhalten. <\/p>\n

<\/p>\n

Sie k\u00f6nnen diese Zahlen in Ihr bevorzugtes \u00dcberwachungssystem einf\u00fcgen, Grafiken erstellen, Funktionen hinzuf\u00fcgen und langfristige Analysen erhalten. <\/p>\n

<\/p>\n

In diesem Bericht m\u00f6chte ich jedoch nicht alle diese Funktionen umfassend behandeln, da dies einen ganzen Tag in Anspruch nehmen k\u00f6nnte. Stattdessen werde ich mich auf nur zwei bis vier Punkte konzentrieren und erl\u00e4utern, wie sie die \u00dcberwachung verbessern.
\n\"Grundlagen
\nWenn es um die \u00dcberwachung der Datenbank geht, welche Aspekte sollten wir im Auge behalten? Zuerst einmal die Verf\u00fcgbarkeit, denn die Datenbank ist ein Dienst, der den Zugang zu Daten f\u00fcr unsere Kunden bereitstellt, und wir m\u00fcssen die Verf\u00fcgbarkeit \u00fcberwachen, sowie einige qualitative und quantitative Merkmale, die damit verbunden sind. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Au\u00dferdem sollten wir die Kunden \u00fcberwachen, die sich mit unserer Datenbank verbinden. Diese k\u00f6nnen sowohl normale Kunden als auch sch\u00e4dliche Nutzer sein, die der Datenbank schaden k\u00f6nnten. Auch deren Aktivit\u00e4ten m\u00fcssen \u00fcberwacht werden.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wenn Kunden auf die Datenbank zugreifen, arbeiten sie offensichtlich mit unseren Daten. Daher m\u00fcssen wir auch \u00fcberwachen, wie die Kunden mit den Daten interagieren: mit welchen Tabellen und in geringerem Ma\u00dfe mit welchen Indizes. Das hei\u00dft, wir m\u00fcssen die Arbeitslast (workload) bewerten, die durch unsere Kunden entsteht.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Die Arbeitslast setzt sich nat\u00fcrlich aus Anfragen zusammen. Anwendungen verbinden sich mit der Datenbank und greifen \u00fcber Anfragen auf die Daten zu. Deshalb ist es wichtig, die Anfragen in unserer Datenbank zu bewerten, ihre Angemessenheit zu \u00fcberwachen und sicherzustellen, dass sie nicht fehlerhaft geschrieben sind. Einige Optionen m\u00fcssen m\u00f6glicherweise \u00fcberarbeitet werden, damit sie schneller und mit besserer Leistung arbeiten. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wenn wir \u00fcber Datenbanken sprechen, sind Datenbanken immer mit Hintergrundprozessen verbunden. Diese Prozesse sorgen daf\u00fcr, dass die Leistung der Datenbank auf einem hohen Niveau bleibt, weshalb sie eine gewisse Menge an Ressourcen ben\u00f6tigen. Gleichzeitig k\u00f6nnen sie mit den Ressourcen der Clientanfragen in Konflikt geraten, und ein \u00fcberm\u00e4\u00dfiger Ressourcenverbrauch dieser Hintergrundprozesse kann die Leistung der Clientanfragen direkt beeinflussen. Daher ist es wichtig, auch diese Prozesse zu \u00fcberwachen und sicherzustellen, dass es keine Ungleichgewichte gibt. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

In Bezug auf das Monitoring von Datenbanken bleiben alle diese Aspekte innerhalb der Systemmetriken. Da jedoch die meisten unserer Infrastrukturen in die Cloud verlagert werden, r\u00fccken die Systemmetriken eines einzelnen Hosts h\u00e4ufig in den Hintergrund. In Datenbanken sind sie jedoch weiterhin relevant, und es ist nat\u00fcrlich auch notwendig, die Systemmetriken zu \u00fcberwachen. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Mit den Systemmetriken ist im Gro\u00dfen und Ganzen alles in Ordnung; alle modernen Monitoring-Systeme unterst\u00fctzen bereits diese Metriken. Dennoch fehlen insgesamt einige Komponenten, und es m\u00fcssen gewisse Dinge hinzugef\u00fcgt werden. Auch darauf werde ich eingehen; es wird mehrere Folien zu diesem Thema geben. <\/p>\n

<\/p>\n

\"Grundlagen
\nDer erste Punkt des Plans ist die Verf\u00fcgbarkeit. Was bedeutet Verf\u00fcgbarkeit? Meiner Meinung nach ist Verf\u00fcgbarkeit die F\u00e4higkeit der Datenbank, Verbindungen zu bedienen, d. h. die Datenbank ist aktiv und nimmt Verbindungen von Klienten entgegen. Diese Verf\u00fcgbarkeit kann anhand einiger Merkmale bewertet werden. Diese Merkmale lassen sich sehr gut auf Dashboards darstellen. <\/p>\n

<\/p>\n

\"Grundlagen
\nAlle wissen, was Dashboards sind. Es ist, wenn du einen kurzen Blick auf einen Bildschirm wirfst, auf dem die erforderlichen Informationen zusammengefasst sind. Und du kannst sofort feststellen, ob es ein Problem mit der Datenbank gibt oder nicht.
\nDaher ist es wichtig, die Verf\u00fcgbarkeit der Datenbank und andere Schl\u00fcsselmerkmale immer auf Dashboards darzustellen, damit diese Informationen zur Hand sind und stets verf\u00fcgbar sind. Zus\u00e4tzliche Details, die bei der Untersuchung von Vorf\u00e4llen oder Notfallsituationen helfen, sollten auf sekund\u00e4re Dashboards ausgegliedert oder in Drilldown-Links verborgen werden, die auf externe Monitoring-Systeme verweisen. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein Beispiel f\u00fcr ein bekanntes \u00dcberwachungssystem. Es handelt sich um ein sehr fortschrittliches \u00dcberwachungssystem. Es sammelt eine gro\u00dfe Menge an Daten, aber aus meiner Sicht hat es ein merkw\u00fcrdiges Verst\u00e4ndnis von Dashboards. Es gibt einen Link \u201eDashboard erstellen\u201c. Wenn Sie jedoch ein Dashboard erstellen, erstellen Sie eine Art Liste, die aus zwei Spalten besteht, eine Liste von Diagrammen. Und wenn Sie etwas ansehen m\u00f6chten, klicken Sie mit der Maus, scrollen und suchen nach dem gew\u00fcnschten Diagramm. Das kostet Zeit, das hei\u00dft, echte Dashboards gibt es nicht. Es gibt nur Listen von Diagrammen.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Was sollte man auf diese Dashboards hinzuf\u00fcgen? Man kann mit einer Kennzahl wie der Reaktionszeit beginnen. In PostgreSQL gibt es die Ansicht pg_stat_statements. Sie ist standardm\u00e4\u00dfig deaktiviert, aber es ist eine der wichtigen systemeigenen Ansichten, die immer aktiviert und verwendet werden sollte. Sie enth\u00e4lt Informationen \u00fcber alle ausgef\u00fchrten Abfragen, die in der Datenbank durchgef\u00fchrt wurden. <\/p>\n

<\/p>\n

Dementsprechend k\u00f6nnen wir davon ausgehen, dass wir die gesamte Ausf\u00fchrungszeit aller Anfragen nehmen und durch die Anzahl der Anfragen mithilfe der oben genannten Felder teilen. Aber das ist eine Durchschnittstemperatur f\u00fcr das gesamte Krankenhaus. Wir k\u00f6nnen uns auch an anderen Feldern orientieren \u2013 der minimalen, maximalen und medianen Ausf\u00fchrungszeit der Anfragen. Wir k\u00f6nnen sogar Perzentile erstellen, daf\u00fcr gibt es entsprechende Funktionen in PostgreSQL. Auf diese Weise k\u00f6nnen wir einige Zahlen erhalten, die die Reaktionszeit unserer Datenbank f\u00fcr bereits ausgef\u00fchrte Anfragen charakterisieren, d. h. wir f\u00fchren keine fiktive Anfrage 'select 1' aus und schauen uns die Reaktionszeit an, sondern analysieren die Antwortzeiten der bereits ausgef\u00fchrten Anfragen und stellen sie entweder als einzelne Zahl dar oder erstellen ein Diagramm basierend auf diesen Werten. <\/p>\n

<\/p>\n

Es ist auch wichtig, die Anzahl der derzeit von der System generierten Fehler zu \u00fcberwachen. Dazu kann die Ansicht pg_stat_database verwendet werden. Wir konzentrieren uns auf das Feld xact_rollback. Dieses Feld zeigt nicht nur die Anzahl der Rollbacks, die in der Datenbank stattfinden, sondern ber\u00fccksichtigt auch die Anzahl der Fehler. Wir k\u00f6nnen diese Zahl theoretisch in unser Dashboard integrieren und beobachten, wie viele Fehler wir derzeit haben. Wenn es viele Fehler gibt, ist das ein guter Anlass, die Logs zu \u00fcberpr\u00fcfen und herauszufinden, um welche Fehler es sich handelt und warum sie auftreten, um dann entsprechende Untersuchungen anzustellen und L\u00f6sungen zu finden.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Es ist m\u00f6glich, etwas wie einen Tacho hinzuzuf\u00fcgen. Dies zeigt die Anzahl der Transaktionen pro Sekunde und die Anzahl der Anfragen pro Sekunde an. Vereinfacht gesagt, k\u00f6nnen Sie diese Zahlen als aktuelle Leistung Ihrer Datenbank verwenden und beobachten, ob es hier zu Anfrage- oder Transaktionsspitzen kommt oder ob die Datenbank unterlastet ist, weil ein Backend ausgefallen ist. Diese Kennzahl sollte stets im Auge behalten werden. F\u00fcr unser Projekt ist diese Leistung normal, w\u00e4hrend Werte dar\u00fcber oder darunter problematisch und unklar sind. Das bedeutet, dass wir \u00fcberpr\u00fcfen m\u00fcssen, warum solche Zahlen auftreten.<\/p>\n

<\/p>\n

Um die Anzahl der Transaktionen zu bewerten, k\u00f6nnen wir erneut auf die Ansicht pg_stat_database zugreifen. Wir k\u00f6nnen die Anzahl der Commits und der Rollbacks addieren und die Anzahl der Transaktionen pro Sekunde ermitteln. <\/p>\n

<\/p>\n

Jeder versteht, dass in eine Transaktion mehrere Anfragen passen k\u00f6nnen? Daher sind TPS und QPS etwas unterschiedlich. <\/p>\n

<\/p>\n

Die Anzahl der Anfragen pro Sekunde kann \u00fcber pg_stat_statements ermittelt werden, indem man einfach die Summe aller ausgef\u00fchrten Anfragen berechnet. Es ist klar, dass wir den aktuellen Wert mit dem vorherigen vergleichen, die Differenz berechnen und die Anzahl erhalten.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Es k\u00f6nnen auf Wunsch zus\u00e4tzliche Metriken hinzugef\u00fcgt werden, die ebenfalls helfen, die Verf\u00fcgbarkeit unserer Datenbank zu bewerten und zu verfolgen, ob es irgendwelche Ausfallzeiten gab. <\/p>\n

<\/p>\n

Eine dieser Metriken ist die Uptime. Aber Uptime in PostgreSQL ist ein etwas kompliziertes Thema. Lassen Sie mich erkl\u00e4ren, warum. Sobald PostgreSQL gestartet ist, beginnt die Uptime zu z\u00e4hlen. Wenn jedoch zu einem bestimmten Zeitpunkt, zum Beispiel nachts, eine Aufgabe ausgef\u00fchrt wurde und der OOM-Killer einen untergeordneten Prozess von PostgreSQL zwangsweise beendet, beendet PostgreSQL in diesem Fall die Verbindung zu allen Clients, setzt den Bereich des shardierten Speichers zur\u00fcck und beginnt die Wiederherstellung von dem letzten Pr\u00fcfpunkte. W\u00e4hrend dieser Wiederherstellung nimmt die Datenbank keine Verbindungen an, was als Ausfallzeit betrachtet werden kann. Gleichzeitig wird der Uptime-Z\u00e4hler jedoch nicht zur\u00fcckgesetzt, da er die Zeit seit dem ersten Start des Postmasters z\u00e4hlt. Daher k\u00f6nnen solche Situationen \u00fcbersehen werden.<\/p>\n

<\/p>\n

Es ist auch wichtig, die Anzahl der Autovacuum-Arbeiter zu \u00fcberwachen. Wissen Sie, was Autovacuum in PostgreSQL ist? Es handelt sich um ein faszinierendes System innerhalb von PostgreSQL. Dar\u00fcber wurden zahlreiche Artikel verfasst und viele Vortr\u00e4ge gehalten. Es gibt viele Diskussionen \u00fcber das Vacuum und dar\u00fcber, wie es funktionieren sollte. Viele betrachten es als ein notwendiges \u00dcbel. Und das ist es tats\u00e4chlich. Es \u00e4hnelt einem Garbage Collector, der veraltete Zeilenversionen bereinigt, die von keiner Transaktion ben\u00f6tigt werden, und Platz in Tabellen und Indizes f\u00fcr neue Zeilen schafft. <\/p>\n

<\/p>\n

Warum ist es notwendig, das zu \u00fcberwachen? Weil das Vacuum manchmal gro\u00dfen Schaden anrichten kann. Es beansprucht eine erhebliche Menge an Ressourcen, was dazu f\u00fchrt, dass die Client-Anfragen darunter leiden. <\/p>\n

<\/p>\n

Die \u00dcberwachung sollte \u00fcber die Ansicht pg_stat_activity erfolgen, \u00fcber die ich im n\u00e4chsten Abschnitt sprechen werde. Diese Ansicht zeigt die aktuelle Aktivit\u00e4t in der Datenbank an. Anhand dieser Aktivit\u00e4t k\u00f6nnen wir die Anzahl der aktuell laufenden Vacuum-Prozesse verfolgen. Wir k\u00f6nnen die Vacuums beobachten und feststellen, dass, wenn wir das Limit \u00fcberschreiten, dies ein Grund ist, die PostgreSQL-Einstellungen zu \u00fcberpr\u00fcfen und die Vacuum-Arbeiten zu optimieren. <\/p>\n

<\/p>\n

Eine weitere Eigenschaft von PostgreSQL ist, dass es unter langen Transaktionen leidet. Besonders unter Transaktionen, die lange verweilen und keine Aktivit\u00e4ten durchf\u00fchren. Diese werden als stat idle-in-transaction bezeichnet. Eine solche Transaktion h\u00e4lt Sperren und behindert die Arbeit des Vacuum-Prozesses. Infolgedessen wachsen die Tabellen und nehmen an Gr\u00f6\u00dfe zu. Anfragen, die mit diesen Tabellen arbeiten, beginnen langsamer zu werden, weil alte Versionen der Zeilen aus dem Speicher auf die Festplatte und zur\u00fcck geschaufelt werden m\u00fcssen.<\/strong> Daher ist es wichtig, die Dauer der l\u00e4ngsten Transaktionen sowie die l\u00e4ngsten Anfragen des Vacuum-Prozesses zu \u00fcberwachen. Wenn wir Prozesse sehen, die bereits sehr lange laufen, also l\u00e4nger als 10-20-30 Minuten bei OLTP-Last, dann sollten wir darauf achten und sie entweder zwangl\u00e4ufig beenden oder die Anwendung optimieren, damit sie nicht so lange aufgerufen werden und h\u00e4ngen bleiben.<\/strong> Bei analytischer Last sind 10-20-30 Minuten normal; manchmal gibt es sogar noch l\u00e4ngere. <\/p>\n

<\/p>\n

\"Grundlagen
\nAls N\u00e4chstes haben wir die Option mit verbundenen Kunden. Sobald wir das Dashboard erstellt und die wichtigen Verf\u00fcgbarkeitsmetriken angezeigt haben, k\u00f6nnen wir auch zus\u00e4tzliche Informationen \u00fcber die verbundenen Kunden hinzuf\u00fcgen. <\/p>\n

<\/p>\n

Informationen \u00fcber die verbundenen Kunden sind wichtig, denn aus der Perspektive von PostgreSQL gibt es verschiedene Arten von Kunden. Es gibt gute Kunden und es gibt schlechte Kunden. <\/p>\n

<\/p>\n

Ein einfaches Beispiel: Mit Kunden meine ich Anwendungen. Eine Anwendung stellt eine Verbindung zur Datenbank her und beginnt sofort, ihre Anfragen zu senden. Die Datenbank verarbeitet diese Anfragen, f\u00fchrt sie aus und gibt die Ergebnisse an den Kunden zur\u00fcck. Das sind gute und richtige Kunden. <\/p>\n

<\/p>\n

Es gibt Situationen, in denen sich ein Kunde verbindet und die Verbindung aufrechterh\u00e4lt, aber dabei nichts tut. Er befindet sich im Zustand idle. <\/p>\n

<\/p>\n

Es gibt jedoch auch problematische Kunden. Ein Beispiel w\u00e4re ein Kunde, der sich anmeldet, eine Transaktion \u00f6ffnet, etwas in der Datenbank macht und dann zur Code-Ebene wechselt, um auf eine externe Quelle zuzugreifen oder um dort die erhaltenen Daten zu verarbeiten. Dabei schlie\u00dft er jedoch die Transaktion nicht. Dadurch bleibt die Transaktion in der Datenbank offen und blockiert eine Zeile. Das ist ein ung\u00fcnstiger Zustand. Wenn die Anwendung dann zuf\u00e4llig aufgrund eines Exceptions irgendwo im Inneren abst\u00fcrzt, kann die Transaktion \u00fcber einen sehr langen Zeitraum offen bleiben. Dies hat direkte Auswirkungen auf die Leistung von PostgreSQL. PostgreSQL wird langsamer arbeiten. Daher ist es wichtig, solche Kunden rechtzeitig zu \u00fcberwachen und ihre Arbeit gegebenenfalls zwangsweise zu beenden. Zudem muss die Anwendung optimiert werden, um solche Situationen zu vermeiden. <\/p>\n

<\/p>\n

Andere problematische Kunden sind wartende Kunden. Sie werden jedoch aus Umst\u00e4nden problematisch. Ein einfaches Beispiel sind wartende Transaktionen: Eine Transaktion kann eine Sperre auf bestimmte Zeilen setzen, dann kann sie irgendwo im Code fehlschlagen und es bleibt eine h\u00e4ngende Transaktion. Ein anderer Kunde k\u00f6nnte die gleichen Daten anfordern, aber er wird auf eine Sperre sto\u00dfen, weil die h\u00e4ngende Transaktion bereits Sperren auf bestimmte ben\u00f6tigte Zeilen h\u00e4lt. Die zweite Transaktion wird somit im Warten h\u00e4ngen bleiben, bis die erste Transaktion abgeschlossen ist oder ihr Administrator sie zwangsweise schlie\u00dft. Wartende Transaktionen k\u00f6nnen sich ansammeln und das Verbindungslimit zur Datenbank \u00fcberschreiten. Wenn das Limit \u00fcberschritten ist, kann die Anwendung nicht mehr mit der Datenbank arbeiten. Dies stellt eine Notfallsituation f\u00fcr das Projekt dar. Daher ist es wichtig, problematische Kunden zu \u00fcberwachen und zeitnah zu reagieren. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein weiteres Beispiel f\u00fcr das Monitoring. Hier sehen wir ein ansprechendes Dashboard. Oben finden Sie Informationen zu den Verbindungen. Insgesamt 8 DB-Verbindungen. Das ist alles. Wir haben keine Informationen dar\u00fcber, welche Kunden aktiv sind, welche nur im Leerlauf sind und nichts tun. Es fehlen Informationen zu h\u00e4ngenden Transaktionen und zu wartenden Verbindungen. Es handelt sich nur um eine Zahl, die die Anzahl der Verbindungen anzeigt, und das war's. Weiter m\u00fcssen Sie selbst raten.
\n\"Grundlagen
\nUm diese Informationen im Monitoring zu integrieren, m\u00fcssen Sie die Systemansicht pg_stat_activity nutzen. Wenn Sie viel Zeit mit PostgreSQL verbringen, wird diese Ansicht zu Ihrem besten Freund, da sie die aktuelle Aktivit\u00e4t in PostgreSQL anzeigt, also was dort gerade passiert. Jeder Prozess hat eine eigene Zeile, die Informationen zu diesem Prozess darstellt: von welchem Host die Verbindung hergestellt wurde, unter welchem Benutzer, unter welchem Namen, wann die Transaktion gestartet wurde, welcher aktuelle Befehl ausgef\u00fchrt wird und welcher Befehl zuletzt ausgef\u00fchrt wurde. Das Zustand des Clients kann anhand des Feldes stat bewertet werden. Wir k\u00f6nnen dies gruppieren und die aktuellen Stats in der Datenbank sowie die Anzahl der Verbindungen mit diesem stat in der Datenbank ermitteln. Diese Zahlen k\u00f6nnen wir dann in unser Monitoring einspeisen und Diagramme daf\u00fcr erstellen.
\nEs ist auch wichtig, die Dauer der Transaktionen zu bewerten. Ich habe bereits gesagt, dass die Dauer der Vakuumprozesse wichtig ist, aber die Transaktionen werden auf die gleiche Weise bewertet. Es gibt die Felder xact_start und query_start. Diese zeigen, sozusagen, den Startzeitpunkt der Transaktion und den Startzeitpunkt der Anfrage an. Wir verwenden die Funktion now(), die den aktuellen Zeitstempel anzeigt, und subtrahieren den Timestamp der Transaktion und der Anfrage. So erhalten wir die Dauer der Transaktion und die Dauer der Anfrage. <\/p>\n

<\/p>\n

Wenn wir lange Transaktionen sehen, sollten wir diese bereits abschlie\u00dfen. F\u00fcr OLTP-Lasten gelten Transaktionen von mehr als 1-2-3 Minuten als lang.<\/strong>. F\u00fcr OLAP-Lasten sind lange Transaktionen normal, aber wenn sie l\u00e4nger als zwei Stunden dauern, ist das ebenfalls ein Zeichen daf\u00fcr, dass es irgendwo ein Ungleichgewicht gibt.<\/strong> <\/p>\n

<\/p>\n

\"Grundlagen
\nWenn die Kunden mit der Datenbank verbunden sind, beginnen sie mit unseren Daten zu arbeiten. Sie greifen auf Tabellen zu, sie greifen auf Indizes zu, um Daten aus der Tabelle abzurufen. Es ist wichtig zu bewerten, wie die Kunden mit diesen Daten arbeiten.<\/p>\n

<\/p>\n

Dies dient dazu, unsere Arbeitslast zu bewerten und ein ungef\u00e4hres Verst\u00e4ndnis daf\u00fcr zu bekommen, welche Tabellen bei uns am \"hei\u00dfesten\" sind. Beispielsweise ist dies n\u00f6tig, wenn wir \"hei\u00dfe\" Tabellen auf einen schnellen SSD-Speicher legen m\u00f6chten. Archivierte Tabellen, die wir seit langem nicht mehr verwenden, k\u00f6nnen wir auf ein \"kaltes\" Archiv, auf SATA-Festplatten, verschieben, wo sie verbleiben k\u00f6nnen, und der Zugriff erfolgt nach Bedarf. <\/p>\n

<\/p>\n

Es ist auch n\u00fctzlich, um Anomalien nach verschiedenen Releases und Deployments zu erkennen. Angenommen, das Projekt hat eine neue Funktion eingef\u00fchrt. Beispielsweise wurde eine neue Funktionalit\u00e4t f\u00fcr die Arbeit mit der Datenbank hinzugef\u00fcgt. Wenn wir Grafiken zur Nutzung der Tabellen erstellen, k\u00f6nnen wir diese Anomalien leicht auf diesen Grafiken erkennen. Beispielsweise pl\u00f6tzliche Anstiege bei Updates oder Deletes. Das wird sehr gut sichtbar sein.<\/p>\n

<\/p>\n

Auch Anomalien einer \"verzerrten\" Statistik k\u00f6nnen festgestellt werden. Was bedeutet das? PostgreSQL verf\u00fcgt \u00fcber einen sehr leistungsstarken und hochwertigen Abfrageplaner. Die Entwickler widmen viel Zeit dessen Optimierung. Wie funktioniert er? Um gute Pl\u00e4ne zu erstellen, sammelt PostgreSQL in regelm\u00e4\u00dfigen Abst\u00e4nden Statistiken \u00fcber die Verteilung der Daten in den Tabellen. Dazu geh\u00f6ren h\u00e4ufige Werte wie die Anzahl der einzigartigen Werte, Informationen \u00fcber NULL in der Tabelle und eine gro\u00dfe Menge an weiteren Informationen. <\/p>\n

<\/p>\n

Basierend auf diesen Statistiken erstellt der Planer mehrere Abfragen, w\u00e4hlt die optimalste aus und verwendet diesen Abfrageplan zur Ausf\u00fchrung der Abfrage und zur R\u00fcckgabe der Daten. <\/p>\n

<\/p>\n

Es kommt vor, dass die Statistiken \"schwanken\". Die Daten bez\u00fcglich Qualit\u00e4t und Menge haben sich in der Tabelle ver\u00e4ndert, aber die Statistiken wurden nicht aktualisiert. Daher k\u00f6nnen die erstellten Pl\u00e4ne suboptimal sein. Wenn unsere Pl\u00e4ne anhand des gesammelten Monitorings und der Tabellen als suboptimal erweisen, k\u00f6nnen wir diese Anomalien identifizieren. Beispielsweise, wenn sich die Daten qualitativ ver\u00e4ndert haben und der Index zusammen mit dem sequentiellen Durchlauf durch die Tabelle genutzt wird. Das bedeutet, wenn der Abfrage nur 100 Zeilen zur\u00fcckgegeben werden sollen (mit einer Begrenzung von limit 100), wird eine vollst\u00e4ndige Durchsuchung durchgef\u00fchrt. Das wirkt sich immer negativ auf die Leistung aus. <\/p>\n

<\/p>\n

Wir werden dies im Monitoring erkennen k\u00f6nnen. Wir k\u00f6nnen bereits diese Abfrage anschauen, ein Explain daf\u00fcr durchf\u00fchren, Statistiken sammeln und einen neuen zus\u00e4tzlichen Index erstellen. So k\u00f6nnen wir auf dieses Problem reagieren. Daher ist das wichtig. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein weiteres Beispiel f\u00fcr Monitoring. Ich denke, viele werden es erkannt haben, weil es sehr popul\u00e4r ist. Wer es in seinen Projekten verwendet, Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Aber hier gibt es einen Nachteil. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Es gibt mehrere Diagramme, in denen als Einheit Bytes angegeben sind, d.h. insgesamt f\u00fcnf Diagramme: Insert-Daten, Update-Daten, Delete-Daten, Fetch-Daten und Return-Daten. Als Ma\u00dfeinheit sind Bytes angegeben. Das Problem ist jedoch, dass die Statistik in PostgreSQL Daten in Tuples (Zeilen) zur\u00fcckliefert. Entsprechend sind diese Diagramme eine ausgezeichnete M\u00f6glichkeit, Ihre Arbeitslast um ein Vielfaches zu senken, denn ein Tuple entspricht nicht einem Byte; ein Tuple ist eine Zeile, die viele Bytes umfasst und immer variable L\u00e4nge hat. Es ist also eine \u00e4u\u00dferst komplizierte oder sogar unm\u00f6gliche Aufgabe, die Arbeitslast in Bytes anhand von Tuples zu berechnen. Daher ist es wichtig, bei der Verwendung eines Dashboards oder einer integrierten \u00dcberwachung stets zu verstehen, dass diese korrekt funktioniert und Ihnen angemessen bewertete Daten liefert. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wie erh\u00e4lt man Statistiken f\u00fcr diese Tabellen? PostgreSQL bietet daf\u00fcr eine bestimmte Reihe von Views. Die wichtigste View ist pg_stat_user_tables<\/a><\/noindex>. User_tables bedeutet, dass die Tabellen im Namen des Benutzers erstellt wurden. Im Gegensatz dazu gibt es System-Views, die von PostgreSQL selbst verwendet werden. Und es gibt eine aggregierte Tabelle Alltables, die sowohl System- als auch Benutzertabellen umfasst. Sie k\u00f6nnen je nach Vorliebe auf einer der beiden basieren.<\/p>\n

<\/p>\n

\u00dcber die oben genannten Felder kann man die Anzahl von Insert, Update und Delete bewerten. Das Dashboard-Beispiel, das ich verwendet habe, nutzt genau diese Felder zur Einsch\u00e4tzung der Workload-Eigenschaften. Daher k\u00f6nnen wir uns auch darauf st\u00fctzen. Es ist jedoch wichtig zu beachten, dass es sich um Tuples und nicht um Bytes handelt, weshalb wir dies nicht einfach in Bytes umrechnen k\u00f6nnen.<\/p>\n

<\/p>\n

Auf Grundlage dieser Daten k\u00f6nnen wir sogenannte TopN-Tabellen erstellen, zum Beispiel Top-5 oder Top-10. Damit l\u00e4sst sich verfolgen, welche Tabellen st\u00e4rker beansprucht werden als andere. Beispielsweise die 5 'hei\u00dfen' Tabellen im Hinblick auf Inserts. Anhand dieser TopN-Tabellen bewerten wir unsere Workload und k\u00f6nnen auch Spitzenlasten nach verschiedenen Releases, Updates und Deployments einsch\u00e4tzen. <\/p>\n

<\/p>\n

Es ist ebenfalls wichtig, die Gr\u00f6\u00dfe der Tabellen zu bewerten, da Entwickler manchmal neue Funktionen ausrollen und unsere Tabellen aufgrund des Hinzuf\u00fcgens zus\u00e4tzlicher Datenmenge stark anwachsen. Dabei wird jedoch h\u00e4ufig nicht vorhergesehen, wie sich dies auf die Gr\u00f6\u00dfe der Datenbank auswirkt. Solche F\u00e4lle k\u00f6nnen f\u00fcr uns ebenfalls \u00fcberraschend sein. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Und jetzt eine kurze Frage an Sie. Welche Fragen kommen auf, wenn Sie eine Belastung auf einem Server mit einer Datenbank feststellen? Welche Fragen stellen Sie sich als N\u00e4chstes? <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Tats\u00e4chlich stellt sich jedoch die folgende Frage: Welche Anfragen verursachen die Belastung? Es ist nicht interessant zu beobachten, welche Prozesse die Belastung verursachen. Es ist klar, dass, wenn der Host eine Datenbank verwaltet, dort eine Datenbank l\u00e4uft, und logisch ist, dass nur Datenbanken dort Ressourcen nutzen. Wenn wir Top \u00f6ffnen, sehen wir eine Liste von Prozessen in PostgreSQL, die etwas tun. Aus dem Top wird jedoch nicht ersichtlich, was genau sie tun. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Daher m\u00fcssen wir die Anfragen identifizieren, die die gr\u00f6\u00dfte Belastung verursachen, da die Optimierung dieser Anfragen in der Regel mehr Vorteile bringt als die Optimierung der PostgreSQL-Konfiguration, des Betriebssystems oder sogar der Hardware. Nach meiner Einsch\u00e4tzung liegt dieser Gewinn bei etwa 80-85-90 %. Und das geht viel schneller. Es ist schneller, eine Anfrage zu optimieren, als die Konfiguration zu \u00e4ndern, einen Neustart zu planen, insbesondere wenn die Datenbank nicht neu gestartet werden kann, oder zus\u00e4tzliche Hardware hinzuzuf\u00fcgen. Es ist einfacher, eine Anfrage umzuformulieren oder einen Index hinzuzuf\u00fcgen, um bereits bessere Ergebnisse aus dieser Anfrage zu erzielen. <\/p>\n

<\/p>\n

\"Grundlagen
\nDementsprechend m\u00fcssen Anfragen und deren Angemessenheit \u00fcberwacht werden. Nehmen wir ein weiteres Beispiel f\u00fcr das Monitoring. Auch hier gibt es ein ansprechendes Monitoring. Es sind Informationen zur Replikation vorhanden, Informationen zur Bandbreite, zu Blockierungen und zur Ressourcennutzung. Alles sieht gut aus, aber es fehlen Informationen zu den Anfragen. Unklar bleibt, welche Anfragen in unserer Datenbank ausgef\u00fchrt werden, wie lange sie dauern und wie viele Anfragen es sind. Im Monitoring m\u00fcssen wir diese Informationen immer vorliegen haben. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

F\u00fcr den Erhalt dieser Informationen k\u00f6nnen wir das Modul pg_stat_statements verwenden. Darauf basierend lassen sich verschiedenste Grafiken erstellen. Zum Beispiel k\u00f6nnen wir die Informationen zu den h\u00e4ufigsten Anfragen abrufen, also zu denjenigen Anfragen, die am h\u00e4ufigsten ausgef\u00fchrt werden. Nach Deployments ist es ebenfalls sehr hilfreich, einen Blick darauf zu werfen und zu pr\u00fcfen, ob es zu einem Anstieg der Anfragen gekommen ist. <\/p>\n

<\/p>\n

Wir k\u00f6nnen auch die l\u00e4ngsten Anfragen \u00fcberwachen, also diejenigen, die am l\u00e4ngsten ausgef\u00fchrt werden. Diese beanspruchen die CPU und verbrauchen E\/A-Ressourcen. Auch das k\u00f6nnen wir anhand der Felder total_time, mean_time, blk_write_time und blk_read_time bewerten. <\/p>\n

<\/p>\n

Wir k\u00f6nnen die ressourcenintensivsten Anfragen bewerten und \u00fcberwachen, insbesondere solche, die von der Festplatte lesen, mit dem Speicher arbeiten oder umgekehrt eine Schreiblast erzeugen.<\/p>\n

<\/p>\n

Wir sind in der Lage, die gro\u00dfz\u00fcgigsten Anfragen zu bewerten. Dies sind Anfragen, die eine gro\u00dfe Menge an Zeilen zur\u00fcckgeben. Zum Beispiel k\u00f6nnte das eine Anfrage sein, bei der man vergessen hat, ein Limit zu setzen, sodass sie einfach den gesamten Inhalt der Tabelle oder der angeforderten Tabellen zur\u00fcckgibt.<\/p>\n

<\/p>\n

Wir k\u00f6nnen auch Anfragen \u00fcberwachen, die tempor\u00e4re Dateien oder tempor\u00e4re Tabellen verwenden. <\/p>\n

<\/p>\n

\"Grundlagen
\nUnd da sind auch unsere Hintergrundprozesse zu beachten. Hintergrundprozesse sind in erster Linie Checkpoints, auch Kontrollpunkte genannt, sowie Autovacuum und Replikation. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein weiteres Beispiel f\u00fcr die \u00dcberwachung. Es gibt auf der linken Seite einen Reiter \"Wartung\", den wir aufrufen und hoffen, etwas N\u00fctzliches zu sehen. Aber hier gibt es nur die Betriebszeit des Vacuum und der Statistiksammlung, nichts weiter. Diese Informationen sind sehr sp\u00e4rlich, weshalb es immer wichtig ist zu wissen, wie unsere Hintergrundprozesse in der Datenbank arbeiten und ob es dabei zu Problemen kommt. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wenn wir \u00fcber Kontrollpunkte sprechen, sollten wir ber\u00fccksichtigen, dass diese 'schmutzigen' Seiten aus dem shardierten Speicher auf die Festplatte geschrieben werden, bevor ein Kontrollpunkt erstellt wird. Dieser Kontrollpunkt kann dann als Ausgangspunkt f\u00fcr eine Wiederherstellung verwendet werden, falls PostgreSQL unerwartet beendet wird. <\/p>\n

<\/p>\n

Um alle 'schmutzigen' Seiten auf die Festplatte zu schreiben, ist eine gewisse Menge an Schreibvorg\u00e4ngen erforderlich. In Systemen mit viel RAM kann das sehr viel sein. Wenn Kontrollpunkte in kurzen Abst\u00e4nden sehr h\u00e4ufig durchgef\u00fchrt werden, kann dies die Festplattenleistung stark beeintr\u00e4chtigen. Das f\u00fchrt dazu, dass Kundenanfragen unter Ressourcenmangel leiden. Sie werden um Ressourcen k\u00e4mpfen und es wird an Leistung fehlen. <\/p>\n

<\/p>\n

\u00dcber die pg_stat_bgwriter k\u00f6nnen wir die Anzahl der aufgetretenen Checkpoints anhand der angegebenen Felder \u00fcberwachen. Wenn wir in einem bestimmten Zeitraum (z. B. 10-15-20 Minuten oder eine halbe Stunde) eine hohe Anzahl von Checkpoints verzeichnen, beispielsweise 3-4-5, k\u00f6nnte das bereits ein Problem darstellen. In diesem Fall sollten wir die Datenbank und die Konfiguration untersuchen, um herauszufinden, was diese Vielzahl an Checkpoints verursacht. M\u00f6glicherweise l\u00e4uft eine gro\u00dfe Schreiboperation. Anhand unserer Workload-Diagramme k\u00f6nnen wir die Situation bereits einsch\u00e4tzen, da wir diese Grafiken hinzugef\u00fcgt haben. Wir k\u00f6nnen die Parameter f\u00fcr die Checkpoints entsprechend anpassen, um sicherzustellen, dass sie die Anfragen nicht negativ beeinflussen.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ich komme erneut auf das Thema Autovacuum zur\u00fcck, denn wie bereits erw\u00e4hnt, kann es sowohl die Leistung der Festplatten als auch der Anfragen erheblich beeintr\u00e4chtigen. Daher ist es immer wichtig, die Anzahl der Autovacuum-L\u00e4ufe zu bewerten. <\/p>\n

<\/p>\n

Die Anzahl der Autovacuum-Worker in der Datenbank ist begrenzt. Standardm\u00e4\u00dfig gibt es drei. Wenn also st\u00e4ndig drei Worker in der Datenbank aktiv sind, deutet das darauf hin, dass das Autovacuum nicht optimal konfiguriert ist. In diesem Fall sollten die Limits angehoben und die Autovacuum-Einstellungen \u00fcberpr\u00fcft werden.
\nEs ist wichtig zu bewerten, welche Vakuum-Worker bei uns aktiv sind. Entweder ist es ein vom Benutzer initiiertes Vakuum, das durch einen DBA manuell gestartet wurde und dadurch eine Last erzeugt hat, was zu einem Problem gef\u00fchrt hat. Oder es handelt sich um die Anzahl der Vakuum-Operationen, die den Transaktionsz\u00e4hler zur\u00fccksetzen. F\u00fcr einige Versionen von PostgreSQL k\u00f6nnen diese Vakuum-Operationen sehr ressourcenintensiv sein, da sie die gesamte Tabelle lesen und alle Bl\u00f6cke in dieser Tabelle scannen. <\/p>\n

<\/p>\n

Und nat\u00fcrlich die Dauer der Vakuumprozesse. Wenn wir lange Vakuumprozesse haben, die sehr lange dauern, bedeutet das, dass wir die Vakuumkonfiguration erneut pr\u00fcfen und m\u00f6glicherweise anpassen sollten. Denn es kann zu einer Situation kommen, in der das Vakuum lange an einer Tabelle arbeitet (3-4 Stunden), aber in der Zwischenzeit sich wieder eine gro\u00dfe Anzahl toter Zeilen in der Tabelle angesammelt hat. Sobald das Vakuum beendet ist, muss es diese Tabelle erneut verarbeiten. Das f\u00fchrt zu einem Zustand \u2013 einem endlosen Vakuum. In diesem Fall kann das Vakuum seine Aufgabe nicht erf\u00fcllen, und die Tabellen beginnen allm\u00e4hlich zu wachsen, obwohl das Volumen an n\u00fctzlichen Daten gleich bleibt. Daher \u00fcberpr\u00fcfen wir bei langen Vakuumprozessen immer die Konfiguration und versuchen, sie zu optimieren, ohne die Leistung der Benutzeranfragen zu beeintr\u00e4chtigen. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Aktuell gibt es kaum eine PostgreSQL-Installation, die keine Streaming-Replikation hat. Replikation ist der Prozess der \u00dcbertragung von Daten vom Master zur Replik.<\/p>\n

<\/p>\n

Die Replikation in PostgreSQL erfolgt \u00fcber das Transaktionsprotokoll. Der Master erstellt das Transaktionsprotokoll. \u00dcber eine Netzwerkverbindung wird das Protokoll an die Replik \u00fcbertragen, wo es dann reproduziert wird. Ganz einfach. <\/p>\n

<\/p>\n

Zur \u00dcberwachung des Replikationslag wird die Ansicht pg_stat_replication verwendet. Aber damit ist nicht alles einfach. In Version 10 wurde die Ansicht ge\u00e4ndert. Erstens wurden einige Felder umbenannt. Zudem wurden einige Felder hinzugef\u00fcgt. In der Version 10 sind Felder hinzugekommen, die die Einsch\u00e4tzung des Replikationslags in Sekunden erm\u00f6glichen. Das ist sehr praktisch. In Version 10 gab es auch weiterhin die M\u00f6glichkeit, den Lag in Bytes zu bewerten. Diese M\u00f6glichkeit besteht nach wie vor in Version 10, d. h. Sie k\u00f6nnen w\u00e4hlen, was Ihnen besser passt \u2013 den Lag in Bytes oder in Sekunden zu bewerten. Viele nutzen beides.<\/p>\n

<\/p>\n

Um den Replikations-Lag zu bewerten, m\u00fcssen wir jedoch die Journal-Position in der Transaktion kennen. Diese Positionen der Transaktionsjournale sind in der Ansicht pg_stat_replication enthalten. Mit der Funktion pg_xlog_location_diff() k\u00f6nnen wir sozusagen zwei Punkte im Transaktionsjournal festlegen, die Differenz zwischen ihnen berechnen und den Replikations-Lag in Bytes erhalten. Das ist sehr praktisch und einfach. <\/p>\n

<\/p>\n

In der Version 10 wurde diese Funktion in pg_wal_lsn_diff() umbenannt. Generell wurde in allen Funktionen, Sichten und Tools, in denen das Wort \u201exlog\u201c vorkam, es durch \u201ewal\u201c ersetzt. Dies gilt sowohl f\u00fcr Sichten als auch f\u00fcr Funktionen. Das ist eine solche Neuerung. <\/p>\n

<\/p>\n

Au\u00dferdem wurden in der 10. Version spezifische Zeilen hinzugef\u00fcgt, die den Lag anzeigen. Dazu geh\u00f6ren Write Lag, Flush Lag und Replay Lag. Es ist wichtig, diese Werte zu \u00fcberwachen. Wenn wir sehen, dass es einen Replikations-Lag gibt, m\u00fcssen wir untersuchen, warum er aufgetreten ist, woher er kommt und das Problem beheben. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Mit den Systemmetriken ist fast alles in Ordnung. Bei jedem Monitoring, das entsteht, beginnen wir mit den Systemmetriken. Dazu geh\u00f6ren die Auslastung von Prozessoren, Speicher, Swap, Netzwerk und Festplatte. Dennoch fehlen viele Parameter standardm\u00e4\u00dfig. <\/p>\n

<\/p>\n

Wenn die Prozessnutzung in Ordnung ist, gibt es Probleme mit der Datentr\u00e4gernutzung. Entwickler von Monitoring-Tools f\u00fcgen in der Regel Informationen zur Bandbreite hinzu. Diese kann in IOPS oder Bytes angegeben werden. Doch sie vergessen oft die Latenz und die Auslastung der Speicherger\u00e4te. Dies sind entscheidende Parameter, die helfen zu beurteilen, wie stark unsere Festplatten belastet sind und wie stark sie verlangsamen. Wenn die Latenz hoch ist, bedeutet das, dass es Probleme mit den Festplatten gibt. Eine hohe Auslastung deutet darauf hin, dass die Festplatten \u00fcberlastet sind.<\/strong> Diese Parameter sind qualitativ hochwertiger als die Bandbreite.<\/p>\n

<\/p>\n

Obwohl diese Statistiken auch aus dem Dateisystem \/proc abgerufen werden k\u00f6nnen, wie es bei der CPU-Auslastung der Fall ist. Warum diese Informationen nicht in Monitoring-Tools integriert werden, wei\u00df ich nicht. Nichtsdestotrotz ist es wichtig, diese in deinem Monitoring zu haben.<\/strong> <\/p>\n

<\/p>\n

Das Gleiche gilt f\u00fcr Netzwerkinterfaces. Es gibt Informationen zur Netzwerkbandbreite in Paketen oder Bytes, aber es fehlen Informationen zur Latenz und zur Auslastung, obwohl diese ebenfalls n\u00fctzlich w\u00e4ren.<\/strong> <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Jede \u00dcberwachung hat ihre Schw\u00e4chen. Egal, welches Monitoring Sie ausw\u00e4hlen, es wird immer gewissen Kriterien nicht gerecht werden. Dennoch entwickeln sie sich weiter, neue Funktionen und Features kommen hinzu. W\u00e4hlen Sie also etwas aus und passen Sie es an. <\/p>\n

<\/p>\n

Um Anpassungen vorzunehmen, ist es wichtig, stets zu verstehen, was die \u00fcbermittelten Statistiken bedeuten und wie man sie zur Probleml\u00f6sung nutzen kann. <\/p>\n

<\/p>\n

Hier sind einige Schl\u00fcssel\u00fcberlegungen:<\/p>\n

<\/p>\n