{"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 des PostgreSQL-Monitorings. Alexej Lesowski","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich lade Sie ein, den Bericht von Alexey Lesovsky von Data Egret \u00fcber \"Grundlagen des Monitorings von PostgreSQL\" zu lesen.<\/strong><\/p>\n

<\/p>\n

In diesem Bericht wird Alexey Lesovsky die Schl\u00fcsselpunkte der PostgreSQL-Statistik erl\u00e4utern, was sie bedeuten und warum sie im Monitoring vorhanden sein sollten; welche Grafiken im Monitoring enthalten sein sollten, wie man sie hinzuf\u00fcgt und interpretiert. Der Bericht ist n\u00fctzlich f\u00fcr Datenbankadministratoren, Systemadministratoren und Entwickler, die an der Fehlersuche in PostgreSQL interessiert sind.<\/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 Alexej Lesowski, ich vertrete die Firma Data Egret. <\/p>\n

<\/p>\n

Ein paar Worte \u00fcber mich. Ich habe vor langer Zeit als Systemadministrator angefangen. <\/p>\n

<\/p>\n

Ich habe verschiedene Linux-Systeme verwaltet, mich mit unterschiedlichen Linux-bezogenen Themen besch\u00e4ftigt, d.h. Virtualisierung, Monitoring, Proxy-Arbeit usw. Aber irgendwann begann ich, mich mehr mit Datenbanken und insbesondere PostgreSQL zu besch\u00e4ftigen. Es hat mir sehr gefallen. Und nach einer gewissen Zeit widmete ich den Gro\u00dfteil meiner Arbeitszeit PostgreSQL. So wurde ich nach und nach PostgreSQL DBA.<\/p>\n

<\/p>\n

Throughout my career, I've always been interested in topics like statistics, monitoring, and telemetry. When I was a system administrator, I worked closely with Zabbix and wrote a small set of scripts, zabbix-extensions<\/a><\/noindex>. It was quite popular at the time, allowing for the monitoring of various important things, not just Linux, but also different components.<\/p>\n

<\/p>\n

Jetzt besch\u00e4ftige ich mich mit PostgreSQL und entwickle ein neues Tool, das die Arbeit mit PostgreSQL-Statistiken erm\u00f6glicht. Es hei\u00dft pgCenter<\/a><\/noindex> (Artikel auf Habr \u2014 PostgreSQL-Statistiken ohne Nerven und Stress<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Eine kurze Einf\u00fchrung. Welche Situationen gibt es bei unseren Auftragsgebern, bei unseren Kunden? Irgendetwas geschieht, das mit der Datenbank zusammenh\u00e4ngt. Und wenn die Datenbank schlie\u00dflich wiederhergestellt ist, kommt der Abteilungsleiter oder der Entwicklungsleiter und sagt: \u201eFreunde, wir sollten die Datenbank \u00fcberwachen, denn es ist etwas Schlechtes passiert und wir m\u00fcssen sicherstellen, dass so etwas in Zukunft nicht mehr passiert.\u201c Und hier beginnt der interessante Prozess der Auswahl eines \u00dcberwachungssystems oder der Anpassung eines bestehenden \u00dcberwachungssystems, um die eigene Datenbank zu \u00fcberwachen \u2013 PostgreSQL, MySQL oder andere. Und die Kollegen beginnen zu sagen: \u201eIch habe geh\u00f6rt, dass es eine solche Datenbank gibt. Lass sie uns verwenden.\u201c Die Kollegen beginnen miteinander zu streiten. Und am Ende w\u00e4hlen wir eine Datenbank aus, aber die PostgreSQL-\u00dcberwachung ist darin ziemlich schwach vertreten und man muss immer wieder etwas nachbessern. Man nimmt irgendwelche Repositories von GitHub, klont sie, passt die Skripte an, macht gewisse Anpassungen. Und letztendlich l\u00e4uft es auf eine Art Handarbeit hinaus. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Deshalb werde ich in diesem Vortrag versuchen, Ihnen einige Kenntnisse dar\u00fcber zu vermitteln, wie man die \u00dcberwachung nicht nur f\u00fcr PostgreSQL, sondern auch f\u00fcr Datenbanken ausw\u00e4hlt. Und Ihnen das Wissen zu geben, das es Ihnen erm\u00f6glicht, Ihre \u00dcberwachung zu verbessern, um von ihr einen Nutzen zu ziehen, um Ihre Datenbank sinnvoll zu \u00fcberwachen, damit Sie rechtzeitig auf bevorstehende Notfallsituationen reagieren k\u00f6nnen, die auftreten k\u00f6nnen. <\/p>\n

<\/p>\n

Die Ideen, die in diesem Vortrag pr\u00e4sentiert werden, k\u00f6nnen direkt auf jede Datenbank angepasst werden, sei es eine SQL-Datenbank oder eine NoSQL-Datenbank. Daher wird nicht nur PostgreSQL behandelt, sondern es gibt viele Rezepte, wie man dies in PostgreSQL umsetzt. Es wird Beispiele f\u00fcr Abfragen, Beispiele f\u00fcr Entit\u00e4ten geben, die es in PostgreSQL f\u00fcr die \u00dcberwachung gibt. Und wenn Ihre SQL-Datenbank \u00e4hnliche Funktionen hat, die in die \u00dcberwachung integriert werden k\u00f6nnen, k\u00f6nnen Sie diese ebenfalls anpassen und hinzuf\u00fcgen, das wird gut sein.<\/p>\n

<\/p>\n

\"GrundlagenIn dem Vortrag werde ich nicht
\ndar\u00fcber sprechen, wie man Metriken erfasst und speichert. Ich werde nichts \u00fcber die Nachbearbeitung von Daten und deren Bereitstellung f\u00fcr den Benutzer sagen. Und ich werde nichts \u00fcber das Alerting sagen.
\nIm Verlauf der Erz\u00e4hlung werde ich verschiedene Screenshots existierender \u00dcberwachungen zeigen und diese kritisieren. Dennoch werde ich versuchen, keine Markennamen zu nennen, um keine Werbung oder Antiwerbung f\u00fcr diese Produkte zu machen. Daher sind alle \u00dcbereinstimmungen zuf\u00e4llig und bleiben Ihrer Fantasie \u00fcberlassen.
\n\"Grundlagen
\nLassen Sie uns zun\u00e4chst kl\u00e4ren, was Monitoring ist. Monitoring ist eine sehr wichtige Sache, die man haben sollte. Das versteht jeder. Gleichzeitig geh\u00f6rt Monitoring jedoch nicht zu den Business-Produkten und beeinflusst nicht direkt den Gewinn des Unternehmens, weshalb dem Monitoring immer nur nachgelagert Aufmerksamkeit geschenkt wird. Wenn wir Zeit haben, k\u00fcmmern wir uns um das Monitoring, wenn keine Zeit vorhanden ist, ist es in Ordnung, wir setzen es in den Backlog und kehren irgendwann zu diesen Aufgaben zur\u00fcck. <\/p>\n

<\/p>\n

Aus unserer Erfahrung, wenn wir zu unseren Kunden kommen, ist das Monitoring oft unzureichend und enth\u00e4lt keine interessanten Aspekte, die uns helfen k\u00f6nnten, besser mit der Datenbank zu arbeiten. Daher muss das Monitoring immer weiter verfeinert werden. <\/p>\n

<\/p>\n

Datenbanken sind komplexe Systeme, die ebenfalls \u00fcberwacht werden m\u00fcssen, denn Datenbanken sind Informationsspeicher. Informationen sind f\u00fcr das Unternehmen sehr wichtig und d\u00fcrfen auf keinen Fall verloren gehen. Gleichzeitig sind Datenbanken jedoch sehr komplexe St\u00fccke Software. Sie bestehen aus einer Vielzahl von Komponenten. Viele dieser Komponenten m\u00fcssen \u00fcberwacht werden. <\/p>\n

<\/p>\n

\"GrundlagenWenn wir speziell \u00fcber PostgreSQL sprechen, kann man es sich als ein Schema vorstellen, das aus einer gro\u00dfen Anzahl von Komponenten besteht. Diese Komponenten interagieren miteinander. Gleichzeitig gibt es in PostgreSQL die sogenannte Stats Collector-Subsystem, die es erm\u00f6glicht, Statistiken \u00fcber die Arbeit dieser Subsysteme zu sammeln und eine Schnittstelle f\u00fcr Administratoren oder Benutzer bereitzustellen, um diese Statistiken einsehen zu k\u00f6nnen. <\/p>\n

<\/p>\n

Diese Statistiken werden in Form eines bestimmten Satzes von Funktionen und Views (Ansichten) dargestellt. Man kann sie auch Tabellen nennen. Das hei\u00dft, mit einem normalen psql-Client k\u00f6nnen Sie sich mit der Datenbank verbinden, ein Select auf diese Funktionen und Views ausf\u00fchren und bereits konkrete Zahlen zur Arbeitsweise der PostgreSQL-Subsysteme erhalten. <\/p>\n

<\/p>\n

Sie k\u00f6nnen diese Zahlen in Ihr bevorzugtes Monitoring-System hinzuf\u00fcgen, Grafiken zeichnen, Funktionen hinzuf\u00fcgen und langfristige Analysen erhalten. <\/p>\n

<\/p>\n

In diesem Bericht werde ich jedoch nicht alle diese Funktionen ausf\u00fchrlich behandeln, da das einen ganzen Tag in Anspruch nehmen k\u00f6nnte. Ich werde mich auf zwei bis vier Punkte konzentrieren und erkl\u00e4ren, wie sie dazu beitragen, das Monitoring zu verbessern.
\n\"Grundlagen
\nWenn wir \u00fcber das Monitoring der Datenbank sprechen, was sollte dann \u00fcberwacht werden? Zun\u00e4chst einmal sollte die Verf\u00fcgbarkeit \u00fcberwacht werden, denn die Datenbank ist ein Dienst, der den Kunden Zugang zu Daten bietet, und wir m\u00fcssen die Verf\u00fcgbarkeit im Hinblick auf bestimmte qualitative und quantitative Merkmale \u00fcberwachen. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Es ist auch wichtig, die Kunden zu \u00fcberwachen, die sich mit unserer Datenbank verbinden, da sie entweder regul\u00e4re Kunden oder sch\u00e4dliche Kunden sein k\u00f6nnen, die der Datenbank schaden k\u00f6nnten. Auch ihr Verhalten muss \u00fcberwacht und verfolgt werden.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wenn sich Kunden mit der Datenbank verbinden, ist es offensichtlich, dass sie mit unseren Daten arbeiten. Daher m\u00fcssen wir auch \u00fcberwachen, wie die Kunden mit den Daten arbeiten: mit welchen Tabellen, in geringerem Ma\u00dfe mit welchen Indizes. Das bedeutet, wir m\u00fcssen die Arbeitslast (workload) bewerten, die unsere Kunden erzeugen.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Die Arbeitslast besteht nat\u00fcrlich auch aus Anfragen. Anwendungen verbinden sich mit der Datenbank und greifen \u00fcber Anfragen auf Daten zu, daher ist es wichtig zu bewerten, welche Anfragen wir in der Datenbank haben, deren Angemessenheit zu verfolgen, sicherzustellen, dass sie nicht schlecht formuliert sind, dass einige Optionen \u00fcberarbeitet werden m\u00fcssen, um schneller und mit besserer Leistung zu arbeiten. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Da wir \u00fcber Datenbanken sprechen, ist es wichtig zu beachten, dass Datenbanken immer Hintergrundprozesse haben. Hintergrundprozesse helfen, die Leistung der Datenbank auf einem hohen Niveau zu halten, daher erfordern sie eine bestimmte Menge an Ressourcen. Gleichzeitig k\u00f6nnen sie mit den Ressourcen der Kundenanfragen in Konflikt geraten, weshalb eine ressourcenintensive Ausf\u00fchrung von Hintergrundprozessen die Leistung der Kundenanfragen direkt beeinflussen kann. Daher sollten auch diese \u00fcberwacht und darauf geachtet werden, dass es keine Ungleichgewichte bei den Hintergrundprozessen gibt. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Und all dies in Bezug auf die \u00dcberwachung der Datenbank bleibt in der systemischen Metrik. Aber wenn man bedenkt, dass der gr\u00f6\u00dfte Teil unserer Infrastruktur in die Clouds geht, geraten die systemischen Metriken eines einzelnen Hosts immer mehr in den Hintergrund. In Datenbanken sind sie jedoch nach wie vor relevant und die \u00dcberwachung von systemischen Metriken ist nat\u00fcrlich auch notwendig. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Mit den systemischen Metriken ist mehr oder weniger alles in Ordnung, alle modernen \u00dcberwachungssysteme unterst\u00fctzen bereits diese Metriken, aber insgesamt fehlen einige Komponenten und einige Dinge m\u00fcssen hinzugef\u00fcgt werden. Auch darauf werde ich eingehen, es wird ein paar Folien dazu geben. <\/p>\n

<\/p>\n

\"Grundlagen
\nDer erste Punkt des Plans ist die Verf\u00fcgbarkeit. Was ist Verf\u00fcgbarkeit? Verf\u00fcgbarkeit ist f\u00fcr mich die F\u00e4higkeit der Datenbank, Verbindungen zu bedienen, d. h. die Datenbank ist hochgefahren, sie akzeptiert als Dienst Verbindungen von Clients. Diese Verf\u00fcgbarkeit kann anhand bestimmter Merkmale bewertet werden. Diese Merkmale lassen sich sehr gut auf Dashboards darstellen. <\/p>\n

<\/p>\n

\"Grundlagen
\nAlle wissen, was Dashboards sind. Das ist, wenn du einen Blick auf den Bildschirm wirfst, auf dem die ben\u00f6tigten Informationen zusammengefasst sind. Und du kannst sofort erkennen \u2013 gibt es ein Problem mit der Datenbank oder nicht.
\nDaher muss die Verf\u00fcgbarkeit der Datenbank und andere Schl\u00fcsselmerkmale immer auf Dashboards angezeigt werden, damit diese Informationen zur Hand sind und immer in deiner N\u00e4he sind. Einige zus\u00e4tzliche Details, die bei der Untersuchung von Vorf\u00e4llen oder Notfallsituationen helfen, m\u00fcssen auf sekund\u00e4re Dashboards angezeigt oder in Drilldown-Links verborgen werden, die auf externe \u00dcberwachungssysteme f\u00fchren. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein Beispiel f\u00fcr ein bekanntes \u00dcberwachungssystem. Das ist ein sehr tolles \u00dcberwachungssystem. Es sammelt sehr viele Daten, aber aus meiner Sicht hat es ein seltsames Verst\u00e4ndnis von Dashboards. Dort gibt es einen Link \u201eDashboard erstellen\u201c. Aber wenn du ein Dashboard erstellst, erstellst du eine Art Liste, die aus zwei Spalten besteht, eine Art Liste von Diagrammen. Und wenn du etwas ansehen musst, beginnst du mit der Maus zu klicken, zu bl\u00e4ttern, zu suchen, welches Diagramm du brauchst. Und das kostet Zeit, d. h. tats\u00e4chliche Dashboards gibt es nicht. Es gibt nur Listen von Diagrammen.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Was sollte man zu diesen Dashboards hinzuf\u00fcgen? Man kann mit einem Merkmal wie der Antwortzeit beginnen. In PostgreSQL gibt es die Ansicht pg_stat_statements. Standardm\u00e4\u00dfig ist sie deaktiviert, aber es ist eine der wichtigen Systemansichten, die immer aktiviert und verwendet werden sollte. Sie enth\u00e4lt Informationen zu allen Abfragen, die in der Datenbank ausgef\u00fchrt wurden. <\/p>\n

<\/p>\n

Dementsprechend k\u00f6nnen wir davon ausgehen, dass wir die Gesamtdauer aller Abfragen nehmen und durch die Anzahl der Abfragen teilen, basierend auf den oben genannten Feldern. Aber das ist so eine Durchschnittstemperatur im Krankenhaus. Wir k\u00f6nnen auch von anderen Feldern ausgehen \u2013 der minimalen, maximalen und medianen Ausf\u00fchrungszeit der Abfragen. Und wir k\u00f6nnen sogar Perzentile berechnen; in PostgreSQL gibt es entsprechende Funktionen daf\u00fcr. Und wir k\u00f6nnen einige Zahlen erhalten, die die Reaktionszeit unserer Datenbank auf bereits ausgef\u00fchrte Abfragen charakterisieren, d. h. wir f\u00fchren keine fiktive Abfrage 'select 1' aus und beobachten die Reaktionszeit, sondern wir analysieren die Antwortzeiten der bereits ausgef\u00fchrten Abfragen und visualisieren sie entweder als einzelne Zahl oder erstellen ein Diagramm daf\u00fcr. <\/p>\n

<\/p>\n

Es ist auch wichtig, die Anzahl der Fehler zu verfolgen, die das System gerade generiert. Und daf\u00fcr kann man die Ansicht pg_stat_database verwenden. Wir orientieren uns an dem Feld xact_rollback. Dieses Feld zeigt nicht nur die Anzahl der Rollbacks an, die in der Datenbank stattfinden, sondern ber\u00fccksichtigt auch die Anzahl der Fehler. Anders gesagt, wir k\u00f6nnen diese Zahl auf unser Dashboard ausgeben und beobachten, wie viele Fehler wir gerade haben. Wenn es viele Fehler gibt, ist das ein guter Grund, in die Logs zu schauen und zu sehen, was f\u00fcr Fehler das sind und warum sie auftreten, und dann weiter zu recherchieren und diese zu beheben.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Man kann eine solche Sache wie einen Tacho hinzuf\u00fcgen. Das ist die Anzahl der Transaktionen pro Sekunde und die Anzahl der Abfragen pro Sekunde. Anders gesagt, Sie k\u00f6nnen diese Zahlen als die aktuelle Leistung Ihrer Datenbank verwenden und beobachten, ob es Spitzen bei den Abfragen oder Transaktionen gibt oder ob die Datenbank im Gegenteil unterlastet ist, weil ein Backend abgest\u00fcrzt ist. Diese Zahl ist wichtig und sollte immer im Blick behalten werden, und man sollte sich daran erinnern, dass eine solche Leistung f\u00fcr unser Projekt normal ist, w\u00e4hrend Werte dar\u00fcber und darunter problematisch oder unklar sind, was bedeutet, dass man schauen muss, 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 zur\u00fcckgreifen. Wir k\u00f6nnen die Anzahl der Commits und die Anzahl der Rollbacks addieren und so die Transaktionen pro Sekunde ermitteln. <\/p>\n

<\/p>\n

Jeder versteht, dass mehrere Anfragen in eine Transaktion 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, subtrahieren und die Differenz, also die Anzahl der Anfragen, erhalten.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Zus\u00e4tzlich k\u00f6nnen nach Belieben weitere Metriken hinzugef\u00fcgt werden, die ebenfalls helfen, die Verf\u00fcgbarkeit unserer Datenbank zu bewerten und zu \u00fcberwachen, ob es irgendwelche Ausfallzeiten gab. <\/p>\n

<\/p>\n

Eine dieser Metriken ist die Uptime. Aber die Uptime in PostgreSQL ist eine etwas knifflige Angelegenheit. Ich werde erkl\u00e4ren, warum. Wenn PostgreSQL gestartet wird, beginnt die Uptime zu z\u00e4hlen. Aber wenn zu einem bestimmten Zeitpunkt, zum Beispiel nachts, eine Aufgabe ausgef\u00fchrt wird, der OOM-Killer kommt und den Kindprozess von PostgreSQL zwangsschlie\u00dft, denn in diesem Fall beendet PostgreSQL die Verbindungen aller Clients, setzt den Bereich des shardierten Speichers zur\u00fcck und beginnt die Wiederherstellung von dem letzten Kontrollpunkt. Und solange die Wiederherstellung vom Kontrollpunkt dauert, nimmt die Datenbank keine Verbindungen an, d. h. diese Situation kann als Ausfallzeit bewertet werden. Aber der Uptime-Z\u00e4hler wird nicht zur\u00fcckgesetzt, da er die Zeit ab dem allerersten Moment z\u00e4hlt, als der Postmaster gestartet wurde. Daher k\u00f6nnen solche Situationen \u00fcbersehen werden.<\/p>\n

<\/p>\n

Es ist auch wichtig, die Anzahl der Vakuum-Worker zu \u00fcberwachen. Jeder wei\u00df, was autovacuum in PostgreSQL ist? Das ist ein interessantes Subsystem in PostgreSQL. Es gibt viele Artikel dar\u00fcber, zahlreiche Pr\u00e4sentationen wurden dazu gehalten. Viele Diskussionen \u00fcber das Vakuum und dar\u00fcber, wie es funktionieren sollte. Viele halten es f\u00fcr ein unvermeidliches \u00dcbel. Aber das ist es. Es ist eine Art von Garbage Collector, der veraltete Versionen von Zeilen bereinigt, die von keiner der Transaktionen ben\u00f6tigt werden, und Platz in Tabellen und Indizes f\u00fcr neue Zeilen freigibt. <\/p>\n

<\/p>\n

Warum sollte man es \u00fcberwachen? Weil das Vakuum manchmal sehr schmerzhaft sein kann. Es verbraucht eine gro\u00dfe Menge an Ressourcen, und die Kundenanfragen leiden darunter. <\/p>\n

<\/p>\n

Und man sollte ihn \u00fcber die Ansicht pg_stat_activity \u00fcberwachen, \u00fcber die ich im n\u00e4chsten Abschnitt sprechen werde. Diese Ansicht zeigt die aktuelle Aktivit\u00e4t in der Datenbank. Durch diese Aktivit\u00e4t k\u00f6nnen wir die Anzahl der Vakuums \u00fcberwachen, die gerade laufen. Wir k\u00f6nnen Vakuums nachverfolgen und feststellen, dass, wenn wir das Limit \u00fcberschreiten, dies ein Grund ist, die PostgreSQL-Einstellungen zu \u00fcberpr\u00fcfen und die Vakuumarbeit irgendwie zu optimieren. <\/p>\n

<\/p>\n

Ein weiteres Merkmal von PostgreSQL ist, dass PostgreSQL sehr stark unter langen Transaktionen leidet. Insbesondere unter Transaktionen, die lange h\u00e4ngen bleiben und nichts tun. Diese werden als stat idle-in-transaction bezeichnet. Solch eine Transaktion h\u00e4lt Sperren, die den Vakuumprozess behindern. Infolgedessen quellen die Tabellen auf, sie vergr\u00f6\u00dfern sich. Und Abfragen, die mit diesen Tabellen arbeiten, werden langsamer, da alle alten Versionen von Zeilen aus dem Speicher auf die Festplatte und zur\u00fcck abgearbeitet werden m\u00fcssen.<\/strong> Deshalb sollte auch die Zeit, die Dauer der l\u00e4ngsten Transaktionen und der l\u00e4ngsten Vakuumabfragen \u00fcberwacht werden. Und wenn wir Prozesse sehen, die schon sehr lange laufen, also l\u00e4nger als 10-20-30 Minuten bei OLTP-Lasten, dann sollten wir darauf achten und sie entweder zwangsweise beenden oder die Anwendung optimieren, damit sie nicht so lange ausgef\u00fchrt werden und h\u00e4ngen bleiben.<\/strong> F\u00fcr analytische Lasten sind 10-20-30 Minuten normal, manchmal gibt es sogar noch l\u00e4ngere Zeiten. <\/p>\n

<\/p>\n

\"Grundlagen
\nDann haben wir eine Option mit verbundenen Clients. Wenn wir bereits ein Dashboard erstellt haben, auf dem wir die wichtigsten Verf\u00fcgbarkeitskennzahlen angezeigt haben, k\u00f6nnen wir auch zus\u00e4tzliche Informationen \u00fcber die verbundenen Clients hinzuf\u00fcgen. <\/p>\n

<\/p>\n

Informationen \u00fcber verbundene Clients sind wichtig, denn aus der Sicht von PostgreSQL gibt es verschiedene Arten von Clients. Es gibt gute Clients und es gibt schlechte Clients. <\/p>\n

<\/p>\n

Ein einfaches Beispiel. Unter einem Client verstehe ich eine Anwendung. Die Anwendung hat eine Verbindung zur Datenbank hergestellt und beginnt sofort damit, ihre Abfragen dorthin zu senden. Die Datenbank verarbeitet sie und f\u00fchrt sie aus, die Ergebnisse werden an den Client zur\u00fcckgegeben. Das sind die guten und richtigen Clients. <\/p>\n

<\/p>\n

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

<\/p>\n

Es gibt jedoch auch schlechte Kunden. Zum Beispiel hat sich derselbe Kunde verbunden, eine Transaktion er\u00f6ffnet, etwas in der Datenbank gemacht und ist dann in den Code gegangen, um auf eine externe Quelle zuzugreifen oder um die erhaltenen Daten zu verarbeiten. Aber er hat dabei die Transaktion nicht geschlossen. Und die Transaktion bleibt in der Datenbank h\u00e4ngen und h\u00e4lt eine Sperre auf einer Zeile. Das ist ein schlechtes Zustand. Und wenn die Anwendung irgendwo intern aufgrund einer Exception abst\u00fcrzt, kann die Transaktion sehr lange offen bleiben. Und das wirkt sich direkt auf die Leistung von PostgreSQL aus. PostgreSQL wird langsamer arbeiten. Daher ist es wichtig, solche Kunden rechtzeitig zu \u00fcberwachen und ihre Arbeit gewaltsam zu beenden. Und man muss seine Anwendung optimieren, um solche Situationen zu vermeiden. <\/p>\n

<\/p>\n

Andere schlechte Kunden sind wartende Kunden. Aber sie werden aufgrund der Umst\u00e4nde zu schlechten Kunden. Zum Beispiel eine einfache h\u00e4ngende Transaktion: Sie kann eine Transaktion \u00f6ffnen, Sperren auf bestimmte Zeilen setzen, und wenn sie irgendwo im Code abst\u00fcrzt, bleibt eine h\u00e4ngende Transaktion bestehen. Ein anderer Kunde kommt, fragt dieselben Daten an, aber er st\u00f6\u00dft auf eine Sperre, weil die h\u00e4ngende Transaktion bereits Sperren auf einige ben\u00f6tigte Zeilen h\u00e4lt. Und die zweite Transaktion wird im Warten h\u00e4ngen bleiben, bis die erste Transaktion abgeschlossen ist oder ihr Administrator sie gewaltsam schlie\u00dft. Auf diese Weise k\u00f6nnen wartende Transaktionen sich ansammeln und das Verbindungslimit zur Datenbank \u00fcbersteigen. Und wenn das Limit \u00fcberschritten ist, kann die Anwendung nicht mehr mit der Datenbank arbeiten. Das ist eine Notlage f\u00fcr das Projekt. Daher m\u00fcssen schlechte Kunden \u00fcberwacht und rechtzeitig angesprochen werden. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein anderes Beispiel f\u00fcr Monitoring. Hier gibt es bereits ein anst\u00e4ndiges Dashboard. Es gibt Informationen zu den Verbindungen oben. DB-Verbindung \u2013 8 St\u00fcck. Und das war's. Wir haben keine Informationen dar\u00fcber, welche Kunden aktiv sind, welche Kunden einfach im Leerlauf sind und nichts tun. Es gibt keine Informationen \u00fcber h\u00e4ngende Transaktionen und wartende Verbindungen, d. h. es ist nur eine Zahl, die die Anzahl der Verbindungen anzeigt, und das war's. Und was weiter passiert, raten Sie selbst.
\n\"Grundlagen
\nDementsprechend m\u00fcssen Sie, um diese Informationen in die \u00dcberwachung einzuf\u00fcgen, die systemweite Ansicht pg_stat_activity konsultieren. Wenn Sie viel Zeit mit PostgreSQL verbringen, ist dies eine sehr n\u00fctzliche Ansicht, die Ihr Freund sein sollte, denn sie zeigt die aktuelle Aktivit\u00e4t in PostgreSQL, d.h. was dort passiert. F\u00fcr jeden Prozess gibt es eine eigene Zeile, die Informationen zu diesem Prozess zeigt: von welchem Host die Verbindung hergestellt wurde, unter welchem Benutzer, unter welchem Namen, wann die Transaktion gestartet wurde, welcher Befehl gerade ausgef\u00fchrt wird und welcher Befehl zuletzt ausgef\u00fchrt wurde. Und dementsprechend k\u00f6nnen wir den Zustand des Clients anhand des Feldes stat bewerten. Grob gesagt, k\u00f6nnen wir eine Gruppierung nach diesem Feld vornehmen und die aktuellen Stats in der Datenbank sowie die Anzahl der Verbindungen mit diesem Stat in der Datenbank abrufen. Die erhaltenen Zahlen k\u00f6nnen wir dann in unsere \u00dcberwachung senden und Diagramme basierend auf diesen erstellen.
\nEs ist auch wichtig, die Dauer der Transaktionen zu bewerten. Ich habe bereits erw\u00e4hnt, dass es wichtig ist, die Dauer der Vacuums zu bewerten, aber auch die Transaktionen werden genau so bewertet. Es gibt die Felder xact_start und query_start. Diese geben grob gesagt die Startzeit der Transaktion und die Startzeit der Abfrage an. Wir nehmen die Funktion now(), die den aktuellen Zeitstempel anzeigt, und subtrahieren den Zeitstempel der Transaktion und der Abfrage. So erhalten wir die Dauer der Transaktion und die Dauer der Abfrage. <\/p>\n

<\/p>\n

Wenn wir lange Transaktionen sehen, sollten wir diese bereits beenden. F\u00fcr OLTP-Lasten sind lange Transaktionen alles \u00fcber 1-2-3 Minuten.<\/strong>. F\u00fcr OLAP-Lasten sind lange Transaktionen normal, aber wenn sie l\u00e4nger als zwei Stunden dauern, ist das ebenfalls ein Anzeichen daf\u00fcr, dass irgendwo ein Ungleichgewicht besteht.<\/strong> <\/p>\n

<\/p>\n

\"Grundlagen
\nWenn sich Kunden mit der Datenbank verbinden, beginnen sie, mit unseren Daten zu arbeiten. Sie greifen auf Tabellen zu, sie greifen auf Indizes zu, um Daten aus der Tabelle zu erhalten. Und es ist wichtig zu bewerten, wie die Kunden mit diesen Daten arbeiten.<\/p>\n

<\/p>\n

Dies ist notwendig, um unsere Workloads zu bewerten und ungef\u00e4hr zu verstehen, welche Tabellen unsere \"hei\u00dfesten\" sind. Zum Beispiel ist dies in Situationen wichtig, in denen wir die \"hei\u00dfen\" Tabellen auf einen schnellen SSD-Speicher legen m\u00f6chten. Beispielsweise k\u00f6nnen alte Archivtabellen, die wir schon lange nicht mehr nutzen, auf ein \"kaltes\" Archiv, auf SATA-Festplatten verschoben werden, und sie sollen dort bleiben; der Zugriff darauf erfolgt nach Bedarf. <\/p>\n

<\/p>\n

Es ist auch n\u00fctzlich, Anomalien nach verschiedenen Releases und Deployments zu entdecken. Angenommen, ein Projekt hat ein neues Feature herausgebracht. Zum Beispiel wurde eine neue Funktionalit\u00e4t zur Datenbankbearbeitung hinzugef\u00fcgt. Wenn wir Diagramme zur Nutzung der Tabellen erstellen, k\u00f6nnen wir in diesen Diagrammen diese Anomalien leicht erkennen. Zum Beispiel Sch\u00fcbe bei Updates oder Sch\u00fcbe beim L\u00f6schen. Das wird sehr gut sichtbar sein.<\/p>\n

<\/p>\n

Zudem k\u00f6nnen Anomalien in der \"verf\u00e4lschten\" Statistik entdeckt werden. Was bedeutet das? PostgreSQL hat einen sehr starken und sehr guten Abfrageplaner. Die Entwickler verbringen viel Zeit mit seiner Weiterentwicklung. Wie funktioniert er? Um gute Pl\u00e4ne zu erstellen, sammelt PostgreSQL in bestimmten Zeitintervallen, in gewisser Regelm\u00e4\u00dfigkeit, Statistiken \u00fcber die Datenverteilung in Tabellen. Dabei handelt es sich um die h\u00e4ufigsten Werte: die Anzahl der einzigartigen Werte, Informationen \u00fcber NULL in der Tabelle, und sehr viele weitere Informationen. <\/p>\n

<\/p>\n

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

<\/p>\n

Es kommt vor, dass die Statistik \"verf\u00e4lscht\" wird. Die Qualit\u00e4t und Anzahl der Daten haben sich in einer Tabelle ver\u00e4ndert, aber die Statistik wurde nicht aktualisiert. Die erstellten Pl\u00e4ne k\u00f6nnen dann suboptimal sein. Und wenn unsere Pl\u00e4ne aufgrund des gemessenen Monitorings und der Tabellen suboptimal sind, k\u00f6nnen wir diese Anomalien erkennen. Zum Beispiel, wo sich die Daten qualitativ ver\u00e4ndert haben und anstelle des Index ein sequenzieller Durchgang durch die Tabelle verwendet wird. Das bedeutet, wenn die Abfrage nur 100 Zeilen zur\u00fcckgeben muss (es gibt eine Limitbeschr\u00e4nkung von 100), wird f\u00fcr diese Abfrage ein vollst\u00e4ndiger Scan durchgef\u00fchrt. Und das hat immer sehr negative Auswirkungen auf die Leistung. <\/p>\n

<\/p>\n

Und wir k\u00f6nnen dies im Monitoring sehen. Und bereits diese Anfrage pr\u00fcfen, den Explain-Befehl ausf\u00fchren, Statistiken sammeln, einen neuen zus\u00e4tzlichen Index erstellen. Und bereits auf dieses Problem reagieren. Deshalb ist das wichtig. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ein weiteres Beispiel f\u00fcr Monitoring. Ich denke, viele haben es erkannt, da es sehr beliebt ist. Wer nutzt es in seinen Projekten? 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 es gibt einen kleinen Nachteil. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Es gibt mehrere Grafiken. Und als Einheit sind Bytes angegeben, d.h. es gibt 5 Grafiken. Das sind Insert-Daten, Update-Daten, Delete-Daten, Fetch-Daten und Return-Daten. Als Ma\u00dfeinheit sind Bytes angegeben. Aber die Statistiken in PostgreSQL geben Daten im Tuple (Zeilen) zur\u00fcck. Und dementsprechend sind diese Grafiken ein sehr guter Weg, Ihre Workloads um ein Vielfaches zu senken, denn ein Tuple ist kein Byte, ein Tuple ist eine Zeile, es sind viele Bytes und sie hat immer variable L\u00e4nge. Das hei\u00dft, die Berechnung des Workloads in Bytes mit Hilfe von Tuples ist eine unm\u00f6gliche oder sehr komplizierte Aufgabe. Deshalb ist es wichtig, wenn Sie ein Dashboard oder integriertes Monitoring verwenden, immer sicherzustellen, dass es richtig funktioniert und Ihnen korrekt bewertete Daten zur\u00fcckgibt. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wie erh\u00e4lt man Statistiken zu diesen Tabellen? Daf\u00fcr gibt es in PostgreSQL eine bestimmte Familie von Views. Und die Hauptview ist pg_stat_user_tables<\/a><\/noindex>. User_tables bedeutet, dass die Tabellen im Namen des Benutzers erstellt wurden. Im Gegensatz dazu gibt es systemische Views, die von PostgreSQL selbst verwendet werden. Und es gibt eine Zusammenfassungstabelle Alltables, die sowohl systemische als auch Benutzer-Tabellen umfasst. Sie k\u00f6nnen von jeder von ihnen ausgehen, die Ihnen am besten gef\u00e4llt.<\/p>\n

<\/p>\n

Anhand der oben genannten Felder kann die Anzahl von Insert, Update und Delete gesch\u00e4tzt werden. Das Beispiel-Dashboard, das ich verwendet habe, nutzt diese Felder zur Bewertung der Workload-Charakteristika. Daher k\u00f6nnen wir auch von ihnen ausgehen. Aber es ist wichtig zu beachten, dass es Tuples sind und keine Bytes, 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, Top-10. Und es ist m\u00f6glich, die hei\u00dfen Tabellen zu verfolgen, die mehr genutzt werden als andere. Zum Beispiel die 5 \"hei\u00dfen\" Tabellen beim Einf\u00fcgen. Und anhand dieser TopN-Tabellen bewerten wir unsere Workloads und k\u00f6nnen die Peaks des Workloads nach verschiedenen Releases, Updates und Deployments einsch\u00e4tzen. <\/p>\n

<\/p>\n

Es ist auch wichtig, die Gr\u00f6\u00dfe der Tabellen zu bewerten, denn manchmal bringen Entwickler ein neues Feature heraus, und unsere Tabellen wachsen in ihrer Gr\u00f6\u00dfe, weil sie sich entscheiden, zus\u00e4tzliche Daten hinzuzuf\u00fcgen, ohne abzusch\u00e4tzen, wie sich dies auf die Gr\u00f6\u00dfe der Datenbank auswirkt. Solche F\u00e4lle sind f\u00fcr uns ebenfalls \u00dcberraschungen. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Und jetzt eine kleine Frage an Sie. Welche Frage stellt sich, wenn Sie eine Belastung auf dem Server mit der Datenbank bemerken? Welche Frage kommt Ihnen als n\u00e4chstes in den Sinn? <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Aber tats\u00e4chlich stellt sich die folgende Frage. Welche Abfragen verursachen die Belastung? Das hei\u00dft, es ist nicht interessant, die Prozesse zu betrachten, die die Belastung verursachen. Es ist klar, dass, wenn sich der Host mit der Datenbank befasst, die Datenbank dort l\u00e4uft und nur die Datenbank dort Ressourcen verwendet. Wenn wir Top \u00f6ffnen, sehen wir dort eine Liste von Prozessen in PostgreSQL, die etwas tun. Aus Top wird nicht klar, was sie tun. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Dar\u00fcber hinaus m\u00fcssen die Abfragen identifiziert werden, die die h\u00f6chste Last verursachen, denn das Tuning von Abfragen bringt in der Regel mehr Nutzen als das Tuning der PostgreSQL-Konfiguration oder des Betriebssystems oder sogar das Hardware-Tuning. Nach meiner Sch\u00e4tzung sind das etwa 80-85-90 %. Und das geht viel schneller. Es ist einfacher, eine Abfrage zu korrigieren, 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, irgendwo eine Abfrage neu zu schreiben oder einen Index hinzuzuf\u00fcgen, um bereits bessere Ergebnisse von dieser Abfrage zu erzielen. <\/p>\n

<\/p>\n

\"Grundlagen
\nDaher m\u00fcssen wir die Abfragen und ihre Angemessenheit \u00fcberwachen. Nehmen wir ein anderes Beispiel f\u00fcr das Monitoring. Auch hier scheint das Monitoring gro\u00dfartig zu sein. Es gibt Informationen zur Replikation, es gibt Informationen zur Bandbreite, zu Sperren und zur Ressourcennutzung. Alles ist perfekt, aber es fehlen Informationen zu den Abfragen. Es ist unklar, welche Abfragen in unserer Datenbank ausgef\u00fchrt werden, wie lange sie ausgef\u00fchrt werden und wie viele dieser Abfragen es gibt. Wir m\u00fcssen diese Informationen im Monitoring immer verf\u00fcgbar haben. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Um diese Informationen zu erhalten, k\u00f6nnen wir das Modul pg_stat_statements verwenden. Darauf basierend k\u00f6nnen die unterschiedlichsten Grafiken erstellt werden. Zum Beispiel kann man Informationen zu den h\u00e4ufigsten Abfragen erhalten, d.h. zu den Abfragen, die am h\u00e4ufigsten ausgef\u00fchrt werden. Ja, auch nach den Deployments ist es sehr n\u00fctzlich, einen Blick darauf zu werfen und zu verstehen, ob es einen Anstieg der Anfragen gibt. <\/p>\n

<\/p>\n

Man kann die l\u00e4ngsten Abfragen \u00fcberwachen, d.h. die Abfragen, die am l\u00e4ngsten dauern. Sie arbeiten auf der CPU und verbrauchen E\/A-Ressourcen. Auch dies 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 schwerwiegendsten Abfragen in Bezug auf den Ressourcenverbrauch bewerten und \u00fcberwachen, die von der Festplatte lesen, mit dem Speicher arbeiten oder umgekehrt eine Schreiblast erzeugen.<\/p>\n

<\/p>\n

Wir k\u00f6nnen die gro\u00dfz\u00fcgigsten Abfragen bewerten. Das sind die Abfragen, die eine gro\u00dfe Anzahl von Zeilen zur\u00fcckgeben. Zum Beispiel k\u00f6nnte es sich um eine Abfrage handeln, bei der das Limit vergessen wurde, und sie gibt einfach den gesamten Inhalt der Tabelle oder der angeforderten Tabellen zur\u00fcck.<\/p>\n

<\/p>\n

Und man kann auch Abfragen \u00fcberwachen, die tempor\u00e4re Dateien oder tempor\u00e4re Tabellen verwenden. <\/p>\n

<\/p>\n

\"Grundlagen
\nJetzt haben wir die Hintergrundprozesse. 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 das Monitoring. Es gibt links den Reiter Wartung, wir wechseln dorthin und hoffen, etwas N\u00fctzliches zu sehen. Aber hier gibt es nur die Betriebszeit des Vacuums und der Statistiksammlung, nichts weiter. Das sind sehr d\u00fcrftige Informationen, daher ist es immer notwendig, Informationen dar\u00fcber zu haben, wie die Hintergrundprozesse in unserer Datenbank arbeiten und ob es Probleme mit ihrer Funktionsweise gibt. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Wenn wir die Kontrollpunkte betrachten, sollte man daran denken, dass die Kontrollpunkte die \u201eschmutzigen\u201c Seiten aus dem shardierten Speicherbereich auf die Festplatte ablegen und dann einen Kontrollpunkt erstellen. Und dieser Kontrollpunkt kann sp\u00e4ter als ein Ort f\u00fcr die Wiederherstellung verwendet werden, falls PostgreSQL im Notfall beendet wird. <\/p>\n

<\/p>\n

Um alle \"schmutzigen\" Seiten auf die Festplatte zur\u00fcckzusetzen, ist ein gewisses Ma\u00df an Schreibvorg\u00e4ngen erforderlich. Und in der Regel ist dies bei Systemen mit gro\u00dfem Arbeitsspeicher sehr viel. Wenn in kurzen Zeitintervallen sehr h\u00e4ufig Checkpoints gesetzt werden, wird die Festplattengeschwindigkeit stark beeintr\u00e4chtigt. Die Clientanfragen werden unter Ressourcenmangel leiden. Sie werden um Ressourcen konkurrieren und es wird ihnen an Leistung fehlen. <\/p>\n

<\/p>\n

\u00dcber pg_stat_bgwriter k\u00f6nnen wir entsprechend den angegebenen Feldern die Anzahl der eintretenden Checkpoints \u00fcberwachen. Wenn wir in einem bestimmten Zeitraum (z. B. 10-15-20 Minuten oder eine halbe Stunde) sehr viele Checkpoints haben, beispielsweise 3-4-5, kann dies bereits ein Problem darstellen. Dann m\u00fcssen wir in der Datenbank nachsehen und in der Konfiguration \u00fcberpr\u00fcfen, was diese Vielzahl von Checkpoints verursacht. Vielleicht gibt es eine gro\u00dfe Schreiboperation. Anhand der Workload k\u00f6nnen wir bereits eine Einsch\u00e4tzung abgeben, da uns die Workload-Grafiken bereits vorliegen. Wir k\u00f6nnen dann die Parameter der Checkpoints anpassen, um sicherzustellen, dass sie die Leistung der Anfragen nicht stark beeintr\u00e4chtigen.<\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Ich komme erneut auf das Autovacuum zur\u00fcck, denn das ist eine Angelegenheit, die, wie ich bereits sagte, die Leistung sowohl der Festplatten als auch der Anfragen erheblich beeintr\u00e4chtigen kann. Daher ist es immer wichtig, die Anzahl der Autovacuum-Vorg\u00e4nge zu bewerten. <\/p>\n

<\/p>\n

Die Anzahl der Autovacuum-Worker in der Datenbank ist begrenzt. Standardm\u00e4\u00dfig sind es drei. Wenn also st\u00e4ndig drei Worker in der Datenbank aktiv sind, bedeutet das, dass unser Autovacuum nicht ausreichend konfiguriert ist. Wir m\u00fcssen die Limits erh\u00f6hen, die Autovacuum-Einstellungen \u00fcberpr\u00fcfen und in die Konfiguration eingreifen.
\nEs ist wichtig, die aktiven Vacuum-Worker zu bewerten. Entweder handelt es sich um einen von einem Benutzer gestarteten Prozess, wobei ein DBA manuell ein Vacuum gestartet hat, was zu einer erh\u00f6hten Last gef\u00fchrt hat. Oder es geht um die Anzahl der Vacuums, die den Transaktionsz\u00e4hler zur\u00fccksetzen. In einigen Versionen von PostgreSQL sind diese Vacuums sehr ressourcenintensiv. Sie k\u00f6nnen die Leistung stark beeintr\u00e4chtigen, da sie die gesamte Tabelle vollst\u00e4ndig durchsuchen und alle Bl\u00f6cke in dieser Tabelle scannen. <\/p>\n

<\/p>\n

Und nat\u00fcrlich die Dauer der Vakuums. Wenn wir lange Vakuums haben, die sehr lange arbeiten, dann bedeutet das, dass wir wieder einmal die Konfiguration des Vakuums \u00fcberdenken und m\u00f6glicherweise seine Einstellungen anpassen sollten. Denn es kann zu einer Situation kommen, in der das Vakuum lange an einer Tabelle arbeitet (3-4 Stunden), aber w\u00e4hrend der Arbeitszeit des Vakuums in der Tabelle erneut eine gro\u00dfe Menge toter Zeilen \u043d\u0430\u043a\u043e\u043f\u0438\u043b\u0430\u0441\u044c. Und sobald das Vakuum abgeschlossen ist, muss es diese Tabelle erneut vakuumieren. Und wir kommen zu der Situation \u2013 dem endlosen Vakuum. In einem solchen Fall bew\u00e4ltigt das Vakuum seine Aufgabe nicht, und die Tabellen beginnen allm\u00e4hlich an Gr\u00f6\u00dfe zuzunehmen, obwohl das Volumen n\u00fctzlicher Daten darin unver\u00e4ndert bleibt. Daher achten wir bei langen Vakuums immer auf die Konfiguration und versuchen, diese zu optimieren, aber gleichzeitig so, dass die Leistung der Kundenanfragen nicht leidet. <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Derzeit gibt es praktisch keine PostgreSQL-Installation, die keine Streaming-Replikation h\u00e4tte. Replikation ist der Prozess der \u00dcbertragung von Daten vom Master zur Replica.<\/p>\n

<\/p>\n

Die Replikation in PostgreSQL funktioniert \u00fcber das Transaktionsprotokoll. Der Master generiert ein Transaktionsprotokoll. Das Transaktionsprotokoll wird \u00fcber eine Netzwerkverbindung zur Replica \u00fcbertragen und dort reproduziert. Das ist ganz einfach. <\/p>\n

<\/p>\n

Zur \u00dcberwachung des Replikationslagers wird die Ansicht pg_stat_replication verwendet. Doch damit ist nicht alles einfach. In Version 10 hat die Ansicht einige \u00c4nderungen erfahren. Erstens wurden einige Felder umbenannt. Und einige Felder wurden hinzugef\u00fcgt. In der Version 10 gibt es Felder, die es erm\u00f6glichen, den Replikationslager in Sekunden zu bewerten. Das ist sehr praktisch. Vor Version 10 war es m\u00f6glich, den Replikationslager in Bytes zu beurteilen. Diese M\u00f6glichkeit besteht auch in Version 10, d.h. Sie k\u00f6nnen w\u00e4hlen, was Ihnen angenehmer ist \u2013 den Lager in Bytes oder in Sekunden zu bewerten. Viele machen beides.<\/p>\n

<\/p>\n

Um den Replikationslager zu bewerten, muss man jedoch die Position des Protokolls in der Transaktion kennen. Diese Positionen des Transaktionsprotokolls sind genau in der Ansicht pg_stat_replication zu finden. Vereinfacht gesagt, k\u00f6nnen wir mit der Funktion pg_xlog_location_diff() zwei Punkte im Transaktionsprotokoll abrufen. Den Unterschied zwischen ihnen berechnen und den Replikationslager in Bytes erhalten. Das ist sehr praktisch und einfach. <\/p>\n

<\/p>\n

In der 10. Version wurde diese Funktion in pg_wal_lsn_diff() umbenannt. Generell wurde in allen Funktionen, Sichten und Utilities, 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 Zeilen hinzugef\u00fcgt, die konkret den Lag anzeigen. Das sind write lag, flush lag, replay lag. Das hei\u00dft, diese Dinge sind wichtig zu \u00fcberwachen. Wenn wir sehen, dass wir einen Replikations-Lag haben, m\u00fcssen wir untersuchen, warum er entstanden 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. Wenn ein Monitoring-System entsteht, beginnt es mit den Systemmetriken. Das sind die Auslastung von Prozessoren, Speicher, Swap, Netzwerk und Festplatte. Dennoch fehlen viele Parameter standardm\u00e4\u00dfig. <\/p>\n

<\/p>\n

Wenn die Auslastung der Prozesse in Ordnung ist, gibt es Probleme mit der Auslastung der Festplatte. In der Regel f\u00fcgen die Entwickler von Monitorings Informationen zur Bandbreite hinzu. Diese kann in IOPS oder Bytes angegeben werden. Aber sie vergessen die Latenz und die Auslastung der Festplatten. Dies sind wichtigere Parameter, die es erm\u00f6glichen zu bewerten, wie ausgelastet unsere Festplatten sind und wie sehr sie verlangsamen. Wenn wir eine hohe Latenz haben, bedeutet das, dass es einige Probleme mit den Festplatten gibt. Wenn wir eine hohe Auslastung haben, bedeutet das, dass die Festplatten \u00fcberlastet sind.<\/strong> Dies sind qualitativ hochwertigere Eigenschaften als die Bandbreite.<\/p>\n

<\/p>\n

Dabei kann diese Statistik auch aus dem Dateisystem \/proc abgerufen werden, wie es f\u00fcr die Auslastung der Prozessoren erfolgt. Warum diese Informationen nicht in Monitorings aufgenommen werden, wei\u00df ich nicht. Dennoch ist es wichtig, dies in seinem Monitoring zu haben.<\/strong> <\/p>\n

<\/p>\n

Das Gleiche gilt f\u00fcr die Netzwerkinterfaces. Es gibt Informationen zur Bandbreite des Netzwerks in Paketen, in Bytes, aber es fehlen Informationen zur Latenz und zur Auslastung, obwohl dies ebenfalls n\u00fctzliche Informationen sind.<\/strong> <\/p>\n

<\/p>\n

\"Grundlagen<\/p>\n

<\/p>\n

Jedes Monitoring hat seine M\u00e4ngel. Und welches Monitoring Sie auch nehmen, es wird immer nicht den einen oder anderen Kriterien entsprechen. Dennoch entwickeln sie sich weiter, es werden neue Features und neue Dinge hinzugef\u00fcgt, also w\u00e4hlen Sie etwas aus und feilen Sie daran. <\/p>\n

<\/p>\n

Um zu feilen, muss man jedoch immer das Verst\u00e4ndnis haben, was die bereitgestellte Statistik bedeutet und wie man mit ihrer Hilfe Probleme l\u00f6sen kann. <\/p>\n

<\/p>\n

Und einige Schl\u00fcsselpunkte:<\/p>\n

<\/p>\n