Best Practices für die Verwaltung der Arbeitsspeichernutzung

Auf dieser Seite wird beschrieben, wie Sie die Speichernutzung für eine Cloud SQL-Instanz konfigurieren.

Einführung

Beim Erstellen einer Cloud SQL-Instanz wählen Sie eine Speichermenge für die Instanz aus. Mit zunehmender Arbeitslast einer PostgreSQL-Datenbank erhöht sich die Speichernutzung der Instanz. Instanzen, die viel Arbeitsspeicher belegen, können zu einem Leistungsengpass führen, der manchmal zu Problemen mit unzureichendem Arbeitsspeicher führt.

Wenn eine Cloud SQL-Instanz aufgrund einer höheren Nachfrage nicht mehr über genügend Arbeitsspeicher verfügt, kann dies zu Ausfallzeiten der Datenbank führen. Daher ist es wichtig, den Instanzspeicher und die speicherbezogenen Datenbank-Flags ordnungsgemäß zu konfigurieren und die Speichernutzung zu überwachen, damit die Instanz in einem fehlerfreien Zustand funktioniert.

PostgreSQL-Speicherkomponenten sind in zwei Abschnitte unterteilt:

  • Globaler Speicher, der von allen Prozessen gemeinsam verwendet wird, um Abfragen auszuführen Beispiel: shared_buffers und max_connections.
  • Lokaler Speicher, d. h. dedizierter Speicher, der jeder Verbindung zugewiesen ist; z. B. work_mem, maintenance_work_mem und temp_buffers.

Weitere Konfigurationsaspekte finden Sie unter Allgemeine Best Practices und Betriebsrichtlinien.

Speichernutzung und Flags

Bei einer hohen Speichernutzung durch Cloud SQL-Instanzen können sich folgende Fragen stellen:

  • Welche Abfrage oder welcher Prozess verwendet einen hohen Arbeitsspeicher?
  • Sind die Speichereinstellungen für die Datenbankaktivität geeignet?
  • Wie können die Speichereinstellungen geändert werden?

Wenn eine PostgreSQL-Datenbank ausgeführt wird, erfolgt die meiste Speichernutzung in einigen Bereichen:

  • Freigegebener Zwischenspeicher: Dies ist der freigegebene Speicher, der PostgreSQL zum Speichern von Tabellendaten für read- und write-Vorgänge zuweist. Für den Vorgang read werden alle vom Laufwerk angeforderten Daten zuerst in den RAM abgerufen und dann an den Client gesendet. In ähnlicher Weise werden die Daten in PostgreSQL, wenn sie angefordert werden (z. B. SELECT * from emp), zuerst vom Laufwerk in die shared_buffers zum Zwischenspeichern geholt und dann an den Client übergeben. Das Gleiche passiert mit dem Vorgang write.

    Der freigegebene Zwischenspeicher ist auch der freigegebene Speicherbereich für alle Prozesse und Verbindungen für Datenbankaktivitäten wie Daten-Caching, Verbindungs-Caching und DML-Vorgänge (Data Manipulation Language). Der maximale Wert, der in diesem Bereich zugewiesen werden kann, wird durch das Flag shared_buffers angegeben. Der Standardwert ist 33 % des Arbeitsspeichers der Instanz. Wenn der Wert von shared_buffers hoch ist, ist auch die Größe der im Speicher gespeicherten Daten hoch.

  • Arbeitsspeicher abfragen: Während der Ausführung einer Abfrage weist PostgreSQL jedem Vorgang lokalen Speicher wie das Sortieren und Hashing zu. Das Maximum, das es jedem Vorgang einer Abfrage zuweisen kann, bevor in temporäre Laufwerksdateien geschrieben wird, wird durch das Flag work_mem konfiguriert. Der Standardwert ist 4 MB. Wenn der Wert von work_mem hoch ist, ist auch die Datenmenge, die im Speicher sortiert werden kann, hoch.
  • Arbeitsspeicher für die Wartung: Einige Wartungsvorgänge wie VACUUM, CREATE INDEX, ALTER TABLE und ADD FOREIGN KEY erfordern einen separaten lokalen Speicher, der von PostgreSQL zugewiesen wird. Der maximale Betrag für den Backend-Prozess, der von diesen Vorgängen verwendet wird, kann mit dem Flag maintenance_work_mem konfiguriert werden. Der Standardwert ist 64 MB. Beachten Sie, dass autovacuum-Worker auch Arbeitsspeicher für die Wartung verwenden. Das Maximum kann mit dem Flag autovacuum_work_mem überschrieben werden. Wenn der Wert von maintenance_work_mem hoch ist, ist die Leistungsgeschwindigkeit des VACUUM-Vorgangs hoch.
  • Temporäre Zwischenspeicher: Wenn eine temporäre Tabelle in einer Datenbanksitzung verwendet wird, weist PostgreSQL temporäre Zwischenspeicher zu, um die sitzungslokale lokale Tabelle zu speichern. Der Höchstwert kann mit dem Flag temp_buffers angegeben werden und der Standardwert ist 8 MB.
  • Datenbankverbindung: Wenn ein Client eine Verbindung zur Datenbank herstellt, erstellt PostgreSQL einen Backend-Prozess für die Clientsitzung. Neben dem Arbeitsspeicher zum Ausführen der Abfrage weist PostgreSQL zusätzlichen Speicher zu, um Informationen wie den Systemkatalog-Cache und vorbereitete Abfragepläne zu verwalten. Die maximale Anzahl gleichzeitiger Verbindungen zum Datenbankserver kann mit dem Flag max_connections konfiguriert werden. Jede inaktive Verbindung benötigt etwa 2 MB bis 3 MB gemeinsamen Speicher. Wenn der Wert von max_connections hoch ist, kann die Instanz mehr Verbindungen herstellen, allerdings auf Kosten des Arbeitsspeichers.

Eine vollständige Liste der Speicherkomponenten in PostgreSQL finden Sie in der PostgreSQL-Dokumentation. Informationen zum Ändern oder Bearbeiten der in diesem Abschnitt aufgeführten Flags finden Sie unter Datenbank-Flags konfigurieren.

Speichernutzung überwachen

Beobachten Sie den Speicher der Instanz regelmäßig in Cloud Monitoring und halten Sie ihn unter dem Arbeitsspeicherlimit. Als Best Practice wird empfohlen, in Cloud Monitoring eine Benachrichtigung einzurichten, die gesendet wird, wenn die Nutzung 6 Stunden lang 90 % des Limits überschreitet. Diese Benachrichtigung kann Sie warnen, wenn Ihre Speichernutzung ständig das Limit erreicht.

Achten Sie außerdem auf Vorfälle aufgrund fehlenden Speichers. Richten Sie dazu einen logbasierten Messwert für die Nachricht server process .* was terminated by signal 9: Killed in Cloud Monitoring ein, um die Ereignisse für fehlenden Speicher zu erfassen und jedes Mal eine Benachrichtigung zu senden, wenn solch ein Ereignis stattfindet.

Wenn Ihre Instanz ständig über das Limit von 90 % des Arbeitsspeichers geht oder ein Ereignis aufgrund fehlenden Speichers auftritt, können Sie den Arbeitsspeicher der Instanz erhöhen. Alternativ können Sie die Arbeitsspeichernutzung reduzieren, indem Sie die Anzahl der Datenbankverbindungen begrenzen oder Datenbank-Flags wie shared_buffers, work_mem oder max_connections verringern. Durch das Senken dieser Flags kann die Leistung der Instanz beeinträchtigt werden.

Nicht genügend Arbeitsspeicher

Wenn nicht genügend Arbeitsspeicher zur Verarbeitung der Datenbankarbeitslast vorhanden ist, verwendet das zugrunde liegende Linux-Betriebssystem das out-of-memory (OOM) killer, um einen Prozess zur Freigabe des Arbeitsspeichers zu beenden. Cloud SQL ist so konfiguriert, dass OOM killer nur auf die PostgreSQL-Worker-Prozesse abzielt. Der postmaster-Prozess wird in dieser Situation beibehalten, sodass er nur alle vorhandenen Datenbankverbindungen beenden und eine Wiederherstellung ausführen muss, um die Integrität der Datenbank zu schützen. In diesem Fall kommt es in der Datenbank zu Dienstunterbrechungen und Ausfallzeiten. Im PostgreSQL-Datenbanklog werden Nachrichten wie die folgenden angezeigt:

2021-10-24 23:34:22.265 UTC [7]: [663-1] db=,user= LOG: server process (PID 1255039) was terminated by signal 9: Killed
2021-10-24 23:34:22.265 UTC [7]: [664-1] db=,user= DETAIL: Failed process was running: SELECT * FROM tab ORDER BY col
2021-10-24 23:34:22.277 UTC [7]: [665-1] db=,user= LOG: terminating any other active server processes
2021-10-24 23:34:22.278 UTC [1255458]: [1-1] db=postgres,user=postgres WARNING: terminating connection because of crash of another server process
2021-10-24 23:34:22.278 UTC [1255458]: [2-1] db=postgres,user=postgres DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-10-24 23:34:22.278 UTC [1255458]: [3-1] db=postgres,user=postgres HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-10-24 23:34:22.278 UTC [1255458]: [4-1] db=postgres,user=postgres CONTEXT: while updating tuple (27,18) in relation "tab"
...
2021-10-24 23:34:22.558 UTC [1255477]: [1-1] db=postgres,user=postgres FATAL: the database system is in recovery mode
...
2021-10-24 23:34:25.579 UTC [7]: [666-1] db=,user= LOG: all server processes terminated; reinitializing
...
2021-10-24 23:34:25.691 UTC [1255482]: [1-1] db=,user= LOG: database system was interrupted; last known up at 2021-10-24 23:31:53 UTC
2021-10-24 23:34:25.776 UTC [1255482]: [2-1] db=,user= LOG: database system was not properly shut down; automatic recovery in progress
2021-10-24 23:34:25.789 UTC [1255482]: [3-1] db=,user= LOG: redo starts at 227/AB359400
2021-10-24 23:34:38.957 UTC [1255482]: [4-1] db=,user= LOG: redo done at 229/4621F508
2021-10-24 23:34:38.959 UTC [1255482]: [5-1] db=,user= LOG: last completed transaction was at log time 2021-10-24 23:34:18.5535+00
2021-10-24 23:34:39.290 UTC [7]: [667-1] db=,user= LOG: database system is ready to accept connections

Nächste Schritte