Ich lade Sie ein, die Abschrift des Berichts von Alexej Lesowski von Data Egret "Grundlagen des PostgreSQL-Monitorings" zu lesen.
In diesem Bericht wird Alexej Lesowski über die Schlüsselpunkte der PostgreSQL-Statistik sprechen, was sie bedeuten und warum sie im Monitoring vorhanden sein müssen; welche Grafiken im Monitoring enthalten sein sollten, wie man sie hinzufügt und wie man sie interpretiert. Der Vortrag wird für Datenbankadministratoren, Systemadministratoren und Entwickler, die an der Fehlersuche von Postgres interessiert sind, nützlich sein.
Mein Name ist Alexej Lesowski, ich vertrete die Firma Data Egret.
Ein paar Worte über mich. Ich habe vor langer Zeit als Systemadministrator angefangen.
Ich habe verschiedene Linux-Systeme verwaltet, mich mit unterschiedlichen Linux-bezogenen Themen beschäftigt, d.h. Virtualisierung, Monitoring, Proxy-Arbeit usw. Aber irgendwann begann ich, mich mehr mit Datenbanken und insbesondere PostgreSQL zu beschäftigen. Es hat mir sehr gefallen. Und nach einer gewissen Zeit widmete ich den Großteil meiner Arbeitszeit PostgreSQL. So wurde ich nach und nach PostgreSQL DBA.
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, . It was quite popular at the time, allowing for the monitoring of various important things, not just Linux, but also different components.
Jetzt beschäftige ich mich mit PostgreSQL und entwickle ein neues Tool, das die Arbeit mit PostgreSQL-Statistiken ermöglicht. Es heißt (Artikel auf Habr — ).
Eine kurze Einführung. Welche Situationen gibt es bei unseren Auftragsgebern, bei unseren Kunden? Irgendetwas geschieht, das mit der Datenbank zusammenhängt. Und wenn die Datenbank schließlich wiederhergestellt ist, kommt der Abteilungsleiter oder der Entwicklungsleiter und sagt: „Freunde, wir sollten die Datenbank überwachen, denn es ist etwas Schlechtes passiert und wir müssen sicherstellen, dass so etwas in Zukunft nicht mehr passiert.“ Und hier beginnt der interessante Prozess der Auswahl eines Überwachungssystems oder der Anpassung eines bestehenden Überwachungssystems, um die eigene Datenbank zu überwachen – PostgreSQL, MySQL oder andere. Und die Kollegen beginnen zu sagen: „Ich habe gehört, dass es eine solche Datenbank gibt. Lass sie uns verwenden.“ Die Kollegen beginnen miteinander zu streiten. Und am Ende wählen wir eine Datenbank aus, aber die PostgreSQL-Überwachung 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äuft es auf eine Art Handarbeit hinaus.
Deshalb werde ich in diesem Vortrag versuchen, Ihnen einige Kenntnisse darüber zu vermitteln, wie man die Überwachung nicht nur für PostgreSQL, sondern auch für Datenbanken auswählt. Und Ihnen das Wissen zu geben, das es Ihnen ermöglicht, Ihre Überwachung zu verbessern, um von ihr einen Nutzen zu ziehen, um Ihre Datenbank sinnvoll zu überwachen, damit Sie rechtzeitig auf bevorstehende Notfallsituationen reagieren können, die auftreten können.
Die Ideen, die in diesem Vortrag präsentiert werden, können 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ür Abfragen, Beispiele für Entitäten geben, die es in PostgreSQL für die Überwachung gibt. Und wenn Ihre SQL-Datenbank ähnliche Funktionen hat, die in die Überwachung integriert werden können, können Sie diese ebenfalls anpassen und hinzufügen, das wird gut sein.
In dem Vortrag werde ich nicht
darüber sprechen, wie man Metriken erfasst und speichert. Ich werde nichts über die Nachbearbeitung von Daten und deren Bereitstellung für den Benutzer sagen. Und ich werde nichts über das Alerting sagen.
Im Verlauf der Erzählung werde ich verschiedene Screenshots existierender Überwachungen zeigen und diese kritisieren. Dennoch werde ich versuchen, keine Markennamen zu nennen, um keine Werbung oder Antiwerbung für diese Produkte zu machen. Daher sind alle Übereinstimmungen zufällig und bleiben Ihrer Fantasie überlassen.
Lassen Sie uns zunächst klären, was Monitoring ist. Monitoring ist eine sehr wichtige Sache, die man haben sollte. Das versteht jeder. Gleichzeitig gehört 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ümmern 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ück.
Aus unserer Erfahrung, wenn wir zu unseren Kunden kommen, ist das Monitoring oft unzureichend und enthält keine interessanten Aspekte, die uns helfen könnten, besser mit der Datenbank zu arbeiten. Daher muss das Monitoring immer weiter verfeinert werden.
Datenbanken sind komplexe Systeme, die ebenfalls überwacht werden müssen, denn Datenbanken sind Informationsspeicher. Informationen sind für das Unternehmen sehr wichtig und dürfen auf keinen Fall verloren gehen. Gleichzeitig sind Datenbanken jedoch sehr komplexe Stücke Software. Sie bestehen aus einer Vielzahl von Komponenten. Viele dieser Komponenten müssen überwacht werden.
Wenn wir speziell über PostgreSQL sprechen, kann man es sich als ein Schema vorstellen, das aus einer großen Anzahl von Komponenten besteht. Diese Komponenten interagieren miteinander. Gleichzeitig gibt es in PostgreSQL die sogenannte Stats Collector-Subsystem, die es ermöglicht, Statistiken über die Arbeit dieser Subsysteme zu sammeln und eine Schnittstelle für Administratoren oder Benutzer bereitzustellen, um diese Statistiken einsehen zu können.
Diese Statistiken werden in Form eines bestimmten Satzes von Funktionen und Views (Ansichten) dargestellt. Man kann sie auch Tabellen nennen. Das heißt, mit einem normalen psql-Client können Sie sich mit der Datenbank verbinden, ein Select auf diese Funktionen und Views ausführen und bereits konkrete Zahlen zur Arbeitsweise der PostgreSQL-Subsysteme erhalten.
Sie können diese Zahlen in Ihr bevorzugtes Monitoring-System hinzufügen, Grafiken zeichnen, Funktionen hinzufügen und langfristige Analysen erhalten.
In diesem Bericht werde ich jedoch nicht alle diese Funktionen ausführlich behandeln, da das einen ganzen Tag in Anspruch nehmen könnte. Ich werde mich auf zwei bis vier Punkte konzentrieren und erklären, wie sie dazu beitragen, das Monitoring zu verbessern.
Wenn wir über das Monitoring der Datenbank sprechen, was sollte dann überwacht werden? Zunächst einmal sollte die Verfügbarkeit überwacht werden, denn die Datenbank ist ein Dienst, der den Kunden Zugang zu Daten bietet, und wir müssen die Verfügbarkeit im Hinblick auf bestimmte qualitative und quantitative Merkmale überwachen.
Es ist auch wichtig, die Kunden zu überwachen, die sich mit unserer Datenbank verbinden, da sie entweder reguläre Kunden oder schädliche Kunden sein können, die der Datenbank schaden könnten. Auch ihr Verhalten muss überwacht und verfolgt werden.
Wenn sich Kunden mit der Datenbank verbinden, ist es offensichtlich, dass sie mit unseren Daten arbeiten. Daher müssen wir auch überwachen, wie die Kunden mit den Daten arbeiten: mit welchen Tabellen, in geringerem Maße mit welchen Indizes. Das bedeutet, wir müssen die Arbeitslast (workload) bewerten, die unsere Kunden erzeugen.
Die Arbeitslast besteht natürlich auch aus Anfragen. Anwendungen verbinden sich mit der Datenbank und greifen über 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 überarbeitet werden müssen, um schneller und mit besserer Leistung zu arbeiten.
Da wir über 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önnen sie mit den Ressourcen der Kundenanfragen in Konflikt geraten, weshalb eine ressourcenintensive Ausführung von Hintergrundprozessen die Leistung der Kundenanfragen direkt beeinflussen kann. Daher sollten auch diese überwacht und darauf geachtet werden, dass es keine Ungleichgewichte bei den Hintergrundprozessen gibt.
Und all dies in Bezug auf die Überwachung der Datenbank bleibt in der systemischen Metrik. Aber wenn man bedenkt, dass der größte 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 Überwachung von systemischen Metriken ist natürlich auch notwendig.
Mit den systemischen Metriken ist mehr oder weniger alles in Ordnung, alle modernen Überwachungssysteme unterstützen bereits diese Metriken, aber insgesamt fehlen einige Komponenten und einige Dinge müssen hinzugefügt werden. Auch darauf werde ich eingehen, es wird ein paar Folien dazu geben.
Der erste Punkt des Plans ist die Verfügbarkeit. Was ist Verfügbarkeit? Verfügbarkeit ist für mich die Fähigkeit der Datenbank, Verbindungen zu bedienen, d. h. die Datenbank ist hochgefahren, sie akzeptiert als Dienst Verbindungen von Clients. Diese Verfügbarkeit kann anhand bestimmter Merkmale bewertet werden. Diese Merkmale lassen sich sehr gut auf Dashboards darstellen.
Alle wissen, was Dashboards sind. Das ist, wenn du einen Blick auf den Bildschirm wirfst, auf dem die benötigten Informationen zusammengefasst sind. Und du kannst sofort erkennen – gibt es ein Problem mit der Datenbank oder nicht.
Daher muss die Verfügbarkeit der Datenbank und andere Schlüsselmerkmale immer auf Dashboards angezeigt werden, damit diese Informationen zur Hand sind und immer in deiner Nähe sind. Einige zusätzliche Details, die bei der Untersuchung von Vorfällen oder Notfallsituationen helfen, müssen auf sekundäre Dashboards angezeigt oder in Drilldown-Links verborgen werden, die auf externe Überwachungssysteme führen.
Ein Beispiel für ein bekanntes Überwachungssystem. Das ist ein sehr tolles Überwachungssystem. Es sammelt sehr viele Daten, aber aus meiner Sicht hat es ein seltsames Verständnis von Dashboards. Dort gibt es einen Link „Dashboard erstellen“. 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ättern, zu suchen, welches Diagramm du brauchst. Und das kostet Zeit, d. h. tatsächliche Dashboards gibt es nicht. Es gibt nur Listen von Diagrammen.
Was sollte man zu diesen Dashboards hinzufügen? Man kann mit einem Merkmal wie der Antwortzeit beginnen. In PostgreSQL gibt es die Ansicht pg_stat_statements. Standardmäßig ist sie deaktiviert, aber es ist eine der wichtigen Systemansichten, die immer aktiviert und verwendet werden sollte. Sie enthält Informationen zu allen Abfragen, die in der Datenbank ausgeführt wurden.
Entsprechend können wir davon ausgehen, dass man die gesamte Ausführungszeit aller Abfragen nehmen und durch die Anzahl der Abfragen mithilfe der oben genannten Felder teilen kann. Aber das ist eine durchschnittliche Temperatur im Krankenhaus. Wir können uns auch auf andere Felder stützen – die minimale Ausführungszeit, die maximale und die Median. Und wir können sogar Perzentile bilden; in PostgreSQL gibt es entsprechende Funktionen dafür. Und wir können einige Zahlen erhalten, die die Antwortzeit unserer Datenbank für bereits durchgeführte Abfragen charakterisieren, d.h. wir führen keine gefälschte Abfrage 'select 1' aus und schauen auf die Antwortzeit, sondern analysieren die Antwortzeiten zu bereits ausgeführten Abfragen und zeigen entweder eine einzelne Zahl an oder erstellen ein Diagramm davon.
Es ist auch wichtig, die Anzahl der Fehler zu verfolgen, die das System gerade generiert. Und dafür 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ücksichtigt auch die Anzahl der Fehler. Anders gesagt, wir können 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ür Fehler das sind und warum sie auftreten, und dann weiter zu recherchieren und diese zu beheben.
Man kann eine solche Sache wie einen Tacho hinzufügen. Das ist die Anzahl der Transaktionen pro Sekunde und die Anzahl der Abfragen pro Sekunde. Anders gesagt, Sie können 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ürzt ist. Diese Zahl ist wichtig und sollte immer im Blick behalten werden, und man sollte sich daran erinnern, dass eine solche Leistung für unser Projekt normal ist, während Werte darüber und darunter problematisch oder unklar sind, was bedeutet, dass man schauen muss, warum solche Zahlen auftreten.
Um die Anzahl der Transaktionen zu bewerten, können wir erneut auf die Ansicht pg_stat_database zurückgreifen. Wir können die Anzahl der Commits und die Anzahl der Rollbacks addieren und so die Transaktionen pro Sekunde ermitteln.
Jeder versteht, dass mehrere Anfragen in eine Transaktion passen können? Daher sind TPS und QPS etwas unterschiedlich.
Die Anzahl der Anfragen pro Sekunde kann über pg_stat_statements ermittelt werden, indem man einfach die Summe aller ausgeführten Anfragen berechnet. Es ist klar, dass wir den aktuellen Wert mit dem vorherigen vergleichen, subtrahieren und die Differenz, also die Anzahl der Anfragen, erhalten.
Zusätzlich können nach Belieben weitere Metriken hinzugefügt werden, die ebenfalls helfen, die Verfügbarkeit unserer Datenbank zu bewerten und zu überwachen, ob es irgendwelche Ausfallzeiten gab.
Eine dieser Metriken ist die Uptime. Aber die Uptime in PostgreSQL ist eine etwas knifflige Angelegenheit. Ich werde erklären, warum. Wenn PostgreSQL gestartet wird, beginnt die Uptime zu zählen. Aber wenn zu einem bestimmten Zeitpunkt, zum Beispiel nachts, eine Aufgabe ausgeführt wird, der OOM-Killer kommt und den Kindprozess von PostgreSQL zwangsschließt, denn in diesem Fall beendet PostgreSQL die Verbindungen aller Clients, setzt den Bereich des shardierten Speichers zurück 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ähler wird nicht zurückgesetzt, da er die Zeit ab dem allerersten Moment zählt, als der Postmaster gestartet wurde. Daher können solche Situationen übersehen werden.
Es ist auch wichtig, die Anzahl der Vakuum-Worker zu überwachen. Jeder weiß, was autovacuum in PostgreSQL ist? Das ist ein interessantes Subsystem in PostgreSQL. Es gibt viele Artikel darüber, zahlreiche Präsentationen wurden dazu gehalten. Viele Diskussionen über das Vakuum und darüber, wie es funktionieren sollte. Viele halten es für ein unvermeidliches Übel. Aber das ist es. Es ist eine Art von Garbage Collector, der veraltete Versionen von Zeilen bereinigt, die von keiner der Transaktionen benötigt werden, und Platz in Tabellen und Indizes für neue Zeilen freigibt.
Warum sollte man es überwachen? Weil das Vakuum manchmal sehr schmerzhaft sein kann. Es verbraucht eine große Menge an Ressourcen, und die Kundenanfragen leiden darunter.
Und man sollte ihn über die Ansicht pg_stat_activity überwachen, über die ich im nächsten Abschnitt sprechen werde. Diese Ansicht zeigt die aktuelle Aktivität in der Datenbank. Durch diese Aktivität können wir die Anzahl der Vakuums überwachen, die gerade laufen. Wir können Vakuums nachverfolgen und feststellen, dass, wenn wir das Limit überschreiten, dies ein Grund ist, die PostgreSQL-Einstellungen zu überprüfen und die Vakuumarbeit irgendwie zu optimieren.
Ein weiteres Merkmal von PostgreSQL ist, dass PostgreSQL sehr stark unter langen Transaktionen leidet. Insbesondere unter Transaktionen, die lange hängen bleiben und nichts tun. Diese werden als stat idle-in-transaction bezeichnet. Solch eine Transaktion hält Sperren, die den Vakuumprozess behindern. Infolgedessen quellen die Tabellen auf, sie vergrößern sich. Und Abfragen, die mit diesen Tabellen arbeiten, werden langsamer, da alle alten Versionen von Zeilen aus dem Speicher auf die Festplatte und zurück abgearbeitet werden müssen. Deshalb sollte auch die Zeit, die Dauer der längsten Transaktionen und der längsten Vakuumabfragen überwacht werden. Und wenn wir Prozesse sehen, die schon sehr lange laufen, also länger 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ührt werden und hängen bleiben. Für analytische Lasten sind 10-20-30 Minuten normal, manchmal gibt es sogar noch längere Zeiten.
Dann haben wir eine Option mit verbundenen Clients. Wenn wir bereits ein Dashboard erstellt haben, auf dem wir die wichtigsten Verfügbarkeitskennzahlen angezeigt haben, können wir auch zusätzliche Informationen über die verbundenen Clients hinzufügen.
Informationen über 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.
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ührt sie aus, die Ergebnisse werden an den Client zurückgegeben. Das sind die guten und richtigen Clients.
Es gibt Situationen, in denen sich ein Client verbindet, die Verbindung hält, aber dabei nichts tut. Er befindet sich im Zustand idle.
Es gibt jedoch auch schlechte Kunden. Zum Beispiel hat sich derselbe Kunde verbunden, eine Transaktion eröffnet, 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ängen und hält eine Sperre auf einer Zeile. Das ist ein schlechtes Zustand. Und wenn die Anwendung irgendwo intern aufgrund einer Exception abstürzt, 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 überwachen und ihre Arbeit gewaltsam zu beenden. Und man muss seine Anwendung optimieren, um solche Situationen zu vermeiden.
Andere schlechte Kunden sind wartende Kunden. Aber sie werden aufgrund der Umstände zu schlechten Kunden. Zum Beispiel eine einfache hängende Transaktion: Sie kann eine Transaktion öffnen, Sperren auf bestimmte Zeilen setzen, und wenn sie irgendwo im Code abstürzt, bleibt eine hängende Transaktion bestehen. Ein anderer Kunde kommt, fragt dieselben Daten an, aber er stößt auf eine Sperre, weil die hängende Transaktion bereits Sperren auf einige benötigte Zeilen hält. Und die zweite Transaktion wird im Warten hängen bleiben, bis die erste Transaktion abgeschlossen ist oder ihr Administrator sie gewaltsam schließt. Auf diese Weise können wartende Transaktionen sich ansammeln und das Verbindungslimit zur Datenbank übersteigen. Und wenn das Limit überschritten ist, kann die Anwendung nicht mehr mit der Datenbank arbeiten. Das ist eine Notlage für das Projekt. Daher müssen schlechte Kunden überwacht und rechtzeitig angesprochen werden.
Ein anderes Beispiel für Monitoring. Hier gibt es bereits ein anständiges Dashboard. Es gibt Informationen zu den Verbindungen oben. DB-Verbindung – 8 Stück. Und das war's. Wir haben keine Informationen darüber, welche Kunden aktiv sind, welche Kunden einfach im Leerlauf sind und nichts tun. Es gibt keine Informationen über hängende 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.
Dementsprechend müssen Sie, um diese Informationen in die Überwachung einzufügen, die systemweite Ansicht pg_stat_activity konsultieren. Wenn Sie viel Zeit mit PostgreSQL verbringen, ist dies eine sehr nützliche Ansicht, die Ihr Freund sein sollte, denn sie zeigt die aktuelle Aktivität in PostgreSQL, d.h. was dort passiert. Für 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ührt wird und welcher Befehl zuletzt ausgeführt wurde. Und dementsprechend können wir den Zustand des Clients anhand des Feldes stat bewerten. Grob gesagt, können 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önnen wir dann in unsere Überwachung senden und Diagramme basierend auf diesen erstellen.
Es ist auch wichtig, die Dauer der Transaktionen zu bewerten. Ich habe bereits erwähnt, 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.
Wenn wir lange Transaktionen sehen, sollten wir diese bereits beenden. Für OLTP-Lasten sind lange Transaktionen alles über 1-2-3 Minuten.. Für OLAP-Lasten sind lange Transaktionen normal, aber wenn sie länger als zwei Stunden dauern, ist das ebenfalls ein Anzeichen dafür, dass irgendwo ein Ungleichgewicht besteht.
Wenn 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.
Dies ist notwendig, um unsere Workloads zu bewerten und ungefähr zu verstehen, welche Tabellen unsere "heißesten" sind. Zum Beispiel ist dies in Situationen wichtig, in denen wir die "heißen" Tabellen auf einen schnellen SSD-Speicher legen möchten. Beispielsweise können 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.
Es ist auch nützlich, Anomalien nach verschiedenen Releases und Deployments zu entdecken. Angenommen, ein Projekt hat ein neues Feature herausgebracht. Zum Beispiel wurde eine neue Funktionalität zur Datenbankbearbeitung hinzugefügt. Wenn wir Diagramme zur Nutzung der Tabellen erstellen, können wir in diesen Diagrammen diese Anomalien leicht erkennen. Zum Beispiel Schübe bei Updates oder Schübe beim Löschen. Das wird sehr gut sichtbar sein.
Zudem können Anomalien in der "verfälschten" 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äne zu erstellen, sammelt PostgreSQL in bestimmten Zeitintervallen, in gewisser Regelmäßigkeit, Statistiken über die Datenverteilung in Tabellen. Dabei handelt es sich um die häufigsten Werte: die Anzahl der einzigartigen Werte, Informationen über NULL in der Tabelle, und sehr viele weitere Informationen.
Auf der Grundlage dieser Statistiken erstellt der Planer mehrere Abfragen, wählt die optimalste aus und verwendet diesen Abfrageplan zur Ausführung der eigentlichen Abfrage und zur Rückgabe der Daten.
Es kommt vor, dass die Statistik "verfälscht" wird. Die Qualität und Anzahl der Daten haben sich in einer Tabelle verändert, aber die Statistik wurde nicht aktualisiert. Die erstellten Pläne können dann suboptimal sein. Und wenn unsere Pläne aufgrund des gemessenen Monitorings und der Tabellen suboptimal sind, können wir diese Anomalien erkennen. Zum Beispiel, wo sich die Daten qualitativ verändert haben und anstelle des Index ein sequenzieller Durchgang durch die Tabelle verwendet wird. Das bedeutet, wenn die Abfrage nur 100 Zeilen zurückgeben muss (es gibt eine Limitbeschränkung von 100), wird für diese Abfrage ein vollständiger Scan durchgeführt. Und das hat immer sehr negative Auswirkungen auf die Leistung.
Und wir können dies im Monitoring sehen. Und bereits diese Anfrage prüfen, den Explain-Befehl ausführen, Statistiken sammeln, einen neuen zusätzlichen Index erstellen. Und bereits auf dieses Problem reagieren. Deshalb ist das wichtig.
Ein weiteres Beispiel für Monitoring. Ich denke, viele haben es erkannt, da es sehr beliebt ist. Wer nutzt es in seinen Projekten? ? А кто использует этот продукт совместно с Prometheus? Дело в том, что в стандартном репозитории этого мониторинга есть дашборд для работы с PostgreSQL – Prometheus. Aber es gibt einen kleinen Nachteil.
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ßeinheit sind Bytes angegeben. Aber die Statistiken in PostgreSQL geben Daten im Tuple (Zeilen) zurück. 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änge. Das heißt, die Berechnung des Workloads in Bytes mit Hilfe von Tuples ist eine unmögliche 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ückgibt.
Wie erhält man Statistiken zu diesen Tabellen? Dafür gibt es in PostgreSQL eine bestimmte Familie von Views. Und die Hauptview ist . 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önnen von jeder von ihnen ausgehen, die Ihnen am besten gefällt.
Anhand der oben genannten Felder kann die Anzahl von Insert, Update und Delete geschätzt werden. Das Beispiel-Dashboard, das ich verwendet habe, nutzt diese Felder zur Bewertung der Workload-Charakteristika. Daher können 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önnen.
Auf Grundlage dieser Daten können wir sogenannte TopN-Tabellen erstellen. Zum Beispiel Top-5, Top-10. Und es ist möglich, die heißen Tabellen zu verfolgen, die mehr genutzt werden als andere. Zum Beispiel die 5 "heißen" Tabellen beim Einfügen. Und anhand dieser TopN-Tabellen bewerten wir unsere Workloads und können die Peaks des Workloads nach verschiedenen Releases, Updates und Deployments einschätzen.
Es ist auch wichtig, die Größe der Tabellen zu bewerten, denn manchmal bringen Entwickler ein neues Feature heraus, und unsere Tabellen wachsen in ihrer Größe, weil sie sich entscheiden, zusätzliche Daten hinzuzufügen, ohne abzuschätzen, wie sich dies auf die Größe der Datenbank auswirkt. Solche Fälle sind für uns ebenfalls Überraschungen.
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ächstes in den Sinn?
Aber tatsächlich stellt sich die folgende Frage. Welche Abfragen verursachen die Belastung? Das heißt, 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äuft und nur die Datenbank dort Ressourcen verwendet. Wenn wir Top öffnen, sehen wir dort eine Liste von Prozessen in PostgreSQL, die etwas tun. Aus Top wird nicht klar, was sie tun.
Darüber hinaus müssen die Abfragen identifiziert werden, die die höchste 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ätzung sind das etwa 80-85-90 %. Und das geht viel schneller. Es ist einfacher, eine Abfrage zu korrigieren, als die Konfiguration zu ändern, einen Neustart zu planen, insbesondere wenn die Datenbank nicht neu gestartet werden kann, oder zusätzliche Hardware hinzuzufügen. Es ist einfacher, irgendwo eine Abfrage neu zu schreiben oder einen Index hinzuzufügen, um bereits bessere Ergebnisse von dieser Abfrage zu erzielen.
Daher müssen wir die Abfragen und ihre Angemessenheit überwachen. Nehmen wir ein anderes Beispiel für das Monitoring. Auch hier scheint das Monitoring großartig 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ührt werden, wie lange sie ausgeführt werden und wie viele dieser Abfragen es gibt. Wir müssen diese Informationen im Monitoring immer verfügbar haben.
Um diese Informationen zu erhalten, können wir das Modul pg_stat_statements verwenden. Darauf basierend können die unterschiedlichsten Grafiken erstellt werden. Zum Beispiel kann man Informationen zu den häufigsten Abfragen erhalten, d.h. zu den Abfragen, die am häufigsten ausgeführt werden. Ja, auch nach den Deployments ist es sehr nützlich, einen Blick darauf zu werfen und zu verstehen, ob es einen Anstieg der Anfragen gibt.
Man kann die längsten Abfragen überwachen, d.h. die Abfragen, die am längsten dauern. Sie arbeiten auf der CPU und verbrauchen E/A-Ressourcen. Auch dies können wir anhand der Felder total_time, mean_time, blk_write_time und blk_read_time bewerten.
Wir können die schwerwiegendsten Abfragen in Bezug auf den Ressourcenverbrauch bewerten und überwachen, die von der Festplatte lesen, mit dem Speicher arbeiten oder umgekehrt eine Schreiblast erzeugen.
Wir können die großzügigsten Abfragen bewerten. Das sind die Abfragen, die eine große Anzahl von Zeilen zurückgeben. Zum Beispiel könnte 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ück.
Und man kann auch Abfragen überwachen, die temporäre Dateien oder temporäre Tabellen verwenden.
Jetzt haben wir die Hintergrundprozesse. Hintergrundprozesse sind in erster Linie Checkpoints, auch Kontrollpunkte genannt, sowie autovacuum und Replikation.
Ein weiteres Beispiel für das Monitoring. Es gibt links den Reiter Wartung, wir wechseln dorthin und hoffen, etwas Nützliches zu sehen. Aber hier gibt es nur die Betriebszeit des Vacuums und der Statistiksammlung, nichts weiter. Das sind sehr dürftige Informationen, daher ist es immer notwendig, Informationen darüber zu haben, wie die Hintergrundprozesse in unserer Datenbank arbeiten und ob es Probleme mit ihrer Funktionsweise gibt.
Wenn wir die Kontrollpunkte betrachten, sollte man daran denken, dass die Kontrollpunkte die „schmutzigen“ Seiten aus dem shardierten Speicherbereich auf die Festplatte ablegen und dann einen Kontrollpunkt erstellen. Und dieser Kontrollpunkt kann später als ein Ort für die Wiederherstellung verwendet werden, falls PostgreSQL im Notfall beendet wird.
Um alle "schmutzigen" Seiten auf die Festplatte zurückzusetzen, ist ein gewisses Maß an Schreibvorgängen erforderlich. Und in der Regel ist dies bei Systemen mit großem Arbeitsspeicher sehr viel. Wenn in kurzen Zeitintervallen sehr häufig Checkpoints gesetzt werden, wird die Festplattengeschwindigkeit stark beeinträchtigt. Die Clientanfragen werden unter Ressourcenmangel leiden. Sie werden um Ressourcen konkurrieren und es wird ihnen an Leistung fehlen.
Über pg_stat_bgwriter können wir entsprechend den angegebenen Feldern die Anzahl der eintretenden Checkpoints überwachen. 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üssen wir in der Datenbank nachsehen und in der Konfiguration überprüfen, was diese Vielzahl von Checkpoints verursacht. Vielleicht gibt es eine große Schreiboperation. Anhand der Workload können wir bereits eine Einschätzung abgeben, da uns die Workload-Grafiken bereits vorliegen. Wir können dann die Parameter der Checkpoints anpassen, um sicherzustellen, dass sie die Leistung der Anfragen nicht stark beeinträchtigen.
Ich komme erneut auf das Autovacuum zurück, denn das ist eine Angelegenheit, die, wie ich bereits sagte, die Leistung sowohl der Festplatten als auch der Anfragen erheblich beeinträchtigen kann. Daher ist es immer wichtig, die Anzahl der Autovacuum-Vorgänge zu bewerten.
Die Anzahl der Autovacuum-Worker in der Datenbank ist begrenzt. Standardmäßig sind es drei. Wenn also ständig drei Worker in der Datenbank aktiv sind, bedeutet das, dass unser Autovacuum nicht ausreichend konfiguriert ist. Wir müssen die Limits erhöhen, die Autovacuum-Einstellungen überprüfen und in die Konfiguration eingreifen.
Es 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öhten Last geführt hat. Oder es geht um die Anzahl der Vacuums, die den Transaktionszähler zurücksetzen. In einigen Versionen von PostgreSQL sind diese Vacuums sehr ressourcenintensiv. Sie können die Leistung stark beeinträchtigen, da sie die gesamte Tabelle vollständig durchsuchen und alle Blöcke in dieser Tabelle scannen.
Und natürlich die Dauer der Vakuums. Wenn wir lange Vakuums haben, die sehr lange arbeiten, dann bedeutet das, dass wir wieder einmal die Konfiguration des Vakuums überdenken und möglicherweise 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ährend der Arbeitszeit des Vakuums in der Tabelle erneut eine große Menge toter Zeilen накопилась. Und sobald das Vakuum abgeschlossen ist, muss es diese Tabelle erneut vakuumieren. Und wir kommen zu der Situation – dem endlosen Vakuum. In einem solchen Fall bewältigt das Vakuum seine Aufgabe nicht, und die Tabellen beginnen allmählich an Größe zuzunehmen, obwohl das Volumen nützlicher Daten darin unverändert 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.
Derzeit gibt es praktisch keine PostgreSQL-Installation, die keine Streaming-Replikation hätte. Replikation ist der Prozess der Übertragung von Daten vom Master zur Replica.
Die Replikation in PostgreSQL funktioniert über das Transaktionsprotokoll. Der Master generiert ein Transaktionsprotokoll. Das Transaktionsprotokoll wird über eine Netzwerkverbindung zur Replica übertragen und dort reproduziert. Das ist ganz einfach.
Zur Überwachung des Replikationslagers wird die Ansicht pg_stat_replication verwendet. Doch damit ist nicht alles einfach. In Version 10 hat die Ansicht einige Änderungen erfahren. Erstens wurden einige Felder umbenannt. Und einige Felder wurden hinzugefügt. In der Version 10 gibt es Felder, die es ermöglichen, den Replikationslager in Sekunden zu bewerten. Das ist sehr praktisch. Vor Version 10 war es möglich, den Replikationslager in Bytes zu beurteilen. Diese Möglichkeit besteht auch in Version 10, d.h. Sie können wählen, was Ihnen angenehmer ist – den Lager in Bytes oder in Sekunden zu bewerten. Viele machen beides.
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önnen 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.
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 „xlog“ vorkam, es durch „wal“ ersetzt. Dies gilt sowohl für Sichten als auch für Funktionen. Das ist eine solche Neuerung.
Außerdem wurden in der 10. Version Zeilen hinzugefügt, die konkret den Lag anzeigen. Das sind write lag, flush lag, replay lag. Das heißt, diese Dinge sind wichtig zu überwachen. Wenn wir sehen, dass wir einen Replikations-Lag haben, müssen wir untersuchen, warum er entstanden ist, woher er kommt und das Problem beheben.
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äßig.
Wenn die Auslastung der Prozesse in Ordnung ist, gibt es Probleme mit der Auslastung der Festplatte. In der Regel fügen 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öglichen 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 überlastet sind. Dies sind qualitativ hochwertigere Eigenschaften als die Bandbreite.
Dabei kann diese Statistik auch aus dem Dateisystem /proc abgerufen werden, wie es für die Auslastung der Prozessoren erfolgt. Warum diese Informationen nicht in Monitorings aufgenommen werden, weiß ich nicht. Dennoch ist es wichtig, dies in seinem Monitoring zu haben.
Das Gleiche gilt für 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ützliche Informationen sind.
Jedes Monitoring hat seine Mängel. 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ügt, also wählen Sie etwas aus und feilen Sie daran.
Um zu feilen, muss man jedoch immer das Verständnis haben, was die bereitgestellte Statistik bedeutet und wie man mit ihrer Hilfe Probleme lösen kann.
Und einige Schlüsselpunkte:
- Es ist immer wichtig, die Verfügbarkeit zu überwachen und Dashboards zu haben, damit Sie schnell bewerten können, ob mit der Datenbank alles in Ordnung ist.
- Es ist immer wichtig, ein Verständnis dafür zu haben, welche Kunden mit Ihrer Datenbank arbeiten, um schlechte Kunden auszusortieren und sie zu eliminieren.
- Es ist wichtig zu bewerten, wie diese Kunden mit den Daten arbeiten. Sie sollten sich Ihres Workloads bewusst sein.
- Es ist wichtig zu bewerten, wie dieser Workload zustande kommt und welche Anfragen verwendet werden. Sie können die Anfragen bewerten, sie optimieren, refaktorisieren und Indizes dafür erstellen. Das ist sehr wichtig.
- Hintergrundprozesse können die Kundenanfragen negativ beeinflussen, daher ist es wichtig, zu überwachen, dass sie nicht zu viele Ressourcen verbrauchen.
- Systemmetriken ermöglichen es Ihnen, Pläne für die Skalierung und die Erhöhung der Kapazität Ihrer Server zu erstellen, daher ist es auch wichtig, sie zu überwachen und zu bewerten.
Wenn Sie an diesem Thema interessiert sind, können Sie diesen Links folgen.
— das ist die offizielle Dokumentation des Statistik-Sammlers. Dort gibt es eine Beschreibung aller statistischen Sichten und aller Felder. Sie können sie lesen, verstehen und analysieren. Und darauf basierend Ihre eigenen Grafiken erstellen und in Ihre Überwachungen einfügen.
Beispiele für Anfragen:
Das ist unser Unternehmensrepository und mein eigenes. Dort gibt es Beispiele für Anfragen. Dort befinden sich keine Anfragen wie select* from irgendetwas. Es sind bereits fertige Anfragen mit Joins, die interessante Funktionen verwenden, die es ermöglichen, aus Rohdaten lesbare, nützliche Werte zu erstellen, d. h. Bytes, Zeiten. Sie können sie analysieren, anschauen, hinzufügen und auf deren Basis Ihre eigenen Überwachungen erstellen.
Fragen
Frage: Sie haben gesagt, dass Sie keine Marken bewerben werden, aber ich bin trotzdem neugierig – welche Dashboards verwenden Sie in Ihren Projekten?
Antwort: Ganz unterschiedlich. Manchmal kommen wir zu einem Kunden, und er hat bereits ein eigenes Monitoring. Wir beraten den Kunden, was er in sein Monitoring hinzufügen sollte. Am schwierigsten ist es mit Zabbiх, weil es keine Möglichkeit gibt, TopN-Diagramme zu erstellen. Wir verwenden selbst , weil wir diese Jungs bei der Überwachung beraten haben. Sie haben das Monitoring für PostgreSQL auf Grundlage unseres Lastenhefts erstellt. Ich schreibe mein eigenes Pet-Projekt, das Daten über Prometheus sammelt und sie darstellt. . Ich habe die Aufgabe, meinen eigenen Exporter in Prometheus zu erstellen und anschließend alles in Grafana darzustellen.
Frage: Gibt es ähnliche Berichte zu AWR oder … Aggregationen? Wissen Sie von etwas Ähnlichem?
Antwort: Ja, ich weiß, was AWR ist, das ist eine tolle Sache. Derzeit gibt es verschiedene Lösungen, die eine ähnliche Modellierung umsetzen. In bestimmten Zeitabständen werden Baselines in dasselbe PostgreSQL oder in ein separates Speicherwerk geschrieben. Man kann sie im Internet finden, die existieren. Einer der Entwickler eines solchen Tools ist im Forum sql.ru in dem Thread über PostgreSQL aktiv. Man kann ihn dort erreichen. Ja, solche Lösungen gibt es, sie sind nutzbar. Außerdem schreibe ich auch etwas, das dasselbe ermöglicht. Ich schreibe auch an etwas Ähnlichem.
P.S.1 Wenn Sie den postgres_exporter verwenden, welchen Dashboard nutzen Sie? Es gibt mehrere davon. Die sind schon veraltet. Vielleicht könnte die Community eine aktualisierte Vorlage erstellen?
P.S.2 Ich habe pganalyze entfernt, da es sich um ein proprietäres SaaS-Angebot handelt, das sich auf Leistungsüberwachung und automatisierte Optimierungsvorschläge konzentriert.
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Welches Self-Hosted-Monitoring für PostgreSQL (mit Dashboard) halten Sie für das beste?
30,0%Zabbix + Erweiterungen von Alexey Lesovski oder Zabbix 4.4 oder libzbxpgsql + zabbix libzbxpgsql + zabbix3
0,0%https://github.com/lesovsky/pgcenter0
0,0%https://github.com/pg-monz/pg_monz0
20,0%https://github.com/cybertec-postgresql/pgwatch22
20,0%https://github.com/postgrespro/mamonsu2
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
10,0%pganalyze ist ein proprietäres SaaS – ich kann es nicht entfernen.
10,0%https://github.com/powa-team/powa1
0,0%https://github.com/darold/pgbadger0
0,0%https://github.com/darold/pgcluu0
0,0%https://github.com/zalando/PGObserver0
10,0%https://github.com/spotify/postgresql-metrics1
10 Benutzer haben abgestimmt. 26 Benutzer haben sich enthalten.
Quelle: habr.com
