Wir führen einen Belastungstest für eine Anwendung durch, die auf eine Postgres-Datenbank zugreift.
Während des Tests steigt die Fehlerrate plötzlich an. Nach der Analyse des Plattform- und Anwendungsverhaltens stellen wir Folgendes fest:
- Die CPU von Postgres RDS beträgt 100 %
- Freizugebender Speicher wird auf demselben Server gelöscht
Und in den Postgres-Protokollen sehen wir:
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: Serverprozess (PID XXXX) wurde durch Signal 9 beendet: Beendet
Nach der Untersuchung und dem Lesen der Dokumentation scheint es möglich, dass der laufende Linux-Oomkiller den Prozess beendet hat.
Da wir jedoch RDS verwenden, können wir zur Bestätigung nicht auf die Systemprotokolle/var/log-Nachrichten zugreifen.
Das kann auch jemand:
- Bestätigen Sie, dass Oom Killer wirklich auf AWS RDS für Postgres läuft
- geben Sie uns eine Möglichkeit, dies zu überprüfen?
- Geben Sie uns eine Möglichkeit, den von Postgres basierend auf der Anzahl der Verbindungen genutzten maximalen Speicher zu berechnen?
Hier habe ich keine Antwort gefunden:
Antwort1
Auch wenn der OOM-Killer nicht aktiv wurde (was wahrscheinlich ist), wirken sich dauerhaft 100 % CPU-Auslastung und sehr wenig freier Speicher negativ auf die Leistung aus.
Verwenden Sie eine größere Instanz und prüfen Sie, ob das Problem behoben ist. Testen Sie eine kleinere Größe auf einem von Ihnen kontrollierten Nicht-RDS-Postgres und prüfen Sie, ob der OOM-Killer wütend wird.
Die Anzahl der Verbindungen ist nicht unbedingt der dominierende Faktor beim Speicherverbrauch: Der gemeinsam genutzte Speicher wird für andere Dinge verwendet, und nicht jede Abfrage verbraucht einen großen Teil des Speichers. Siehe auch diese Unterhaltung:PostgreSql weist jeder Verbindung Speicher zu.
Zusätzliche Beratung vonBewährte Methoden für Amazon RDS
RAM-Empfehlungen für DB-Instances
Eine bewährte Methode zur Leistungssteigerung von Amazon RDS besteht darin, genügend RAM zuzuweisen, sodass Ihr Arbeitssatz fast vollständig im Speicher liegt. Um festzustellen, ob Ihr Arbeitssatz fast vollständig im Speicher liegt, überprüfen Sie die ReadIOPS-Metrik (mit Amazon CloudWatch), während die DB-Instance unter Last steht. Der Wert von ReadIOPS sollte klein und stabil sein. Wenn das Hochskalieren der DB-Instance-Klasse – auf eine Klasse mit mehr RAM – zu einem drastischen Rückgang von ReadIOPS führt, war Ihr Arbeitssatz nicht fast vollständig im Speicher. Fahren Sie mit dem Hochskalieren fort, bis ReadIOPS nach einem Skalierungsvorgang nicht mehr drastisch abfällt oder ReadIOPS auf einen sehr kleinen Wert reduziert ist.
Leistungsmetriken auswerten
Freier Speicher – Wie viel RAM ist auf der DB-Instanz verfügbar, in Megabyte. Die rote Linie in den Metriken der Registerkarte „Überwachung“ ist bei 75 % für CPU-, Speicher- und Speichermetriken markiert. Wenn der Speicherverbrauch der Instanz diese Linie häufig überschreitet, bedeutet dies, dass Sie Ihre Arbeitslast überprüfen oder Ihre Instanz aktualisieren sollten.
Antwort2
Ich habe nicht viel Erfahrung mit Postgres, aber in derselben Situation habe ich festgestellt, dass eine RDS MySql-Instanz dazu neigt, vollständig neu gestartet zu werden. Auch wenn Sie keinen Zugriff auf die zugrunde liegenden Systeme haben, sollten Sie in der Lage sein, Postgres-Protokolle über die Webkonsole abzurufen. Achten Sie auf einen Neustart. Der Daemon sollte anzeigen, dass er geschlossen und gestartet wird.
Wenn Sie in einer Gefahrenzone arbeiten, können Sie nicht viel tun. Sie sollten zu einer Instanz mit mehr verfügbarem RAM/CPU wechseln.