Automatische Arbeitsspeicherverwaltung

Sie können das obere Limit des gemeinsam genutzten Puffers beim Starten von AlloyDB Omni festlegen. Wenn Sie das obere Limit nicht festlegen, wird die Größe des Sicherungsspeichers für den freigegebenen Puffer in AlloyDB Omni automatisch auf 80% des Systemspeichers festgelegt. Die anfängliche Sicherungsgröße des gemeinsamen Puffers kann sich von der Obergrenze unterscheiden.

AlloyDB Omni besteht aus einem intelligenten Memory-Worker, der den Arbeitsspeicherstatus ständig überwacht und die Größe des Backups des freigegebenen Puffers für eine optimale Leistung beim Caching von Daten anpasst.

Standardmäßig ist der Parameter shared_buffers auf 0 festgelegt. Das ist ein spezieller Wert, mit dem die Obergrenze für die Größe des shared buffers-Cache auf 80% des Systemspeichers festgelegt wird. AlloyDB Omni beginnt bei 10% des oberen Grenzwerts für shared_buffers. Wenn shared_buffers durch einen benutzerdefinierten Wert überschrieben wird, berücksichtigt AlloyDB Omni den Wert als Obergrenze für die shared_buffers-Größe und beginnt mit der angegebenen benutzerdefinierten Größe.

Wenn Sie eine benutzerdefinierte Größe angeben möchten, bearbeiten Sie die Konfigurationsdatei postgresql.conf. Sie können shared_buffers beispielsweise mit einer der folgenden Methoden auf 1GB festlegen:

• docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image

• docker run --name CONTAINER_NAME $image -c shared_buffers=1GB

  Ersetzen Sie CONTAINER_NAME durch den Namen, den Sie dem AlloyDB Omni-Container bei der Installation zugewiesen haben.

Abfrageleistung optimieren

Der Standardwert des Parameters shared_buffers ist für die meisten Szenarien geeignet.

Sie können den Wert jedoch für eine optimale Leistung anpassen. Wenn Sie den Standardwert von shared_buffers verwenden, um die Obergrenze für den freigegebenen Puffer abzuleiten, verwenden Sie den cgroup-Wert memory.max, um die Berechnung zu beeinflussen.

Arbeitsspeicher der spaltenbasierten Engine

Der dynamische shared_buffers ist unabhängig vom Arbeitsspeicher der spaltenbasierten Engine. Wenn die Spalten-Engine aktiviert ist, kann die dynamische shared_buffers-Größe abgeleitet werden, indem die von der Spalten-Engine verwendete Speichermenge von 80% des Gesamtspeichers subtrahiert wird, der für das System oder die Cgroup verfügbar ist.

Große Seiten

Huge Pages verbessern die Datenbankleistung. AlloyDB Omni verwaltet Huge Pages explizit, sofern möglich. Andernfalls wird die THP-Funktion (Transparent Huge Pages) des Betriebssystems verwendet. Wenn keiner der beiden Huge-Page-Typen unterstützt wird, greift AlloyDB Omni auf die 4-KB-Seite zurück und gibt eine Warnung in den Docker-Containerlogs docker logs $container_name mit einer spezifischen Anleitung zum Einrichten von Huge Pages aus. Eine Anleitung zum Starten eines Containers finden Sie hier.

Die Warnung sieht in etwa so aus:

HINT:  Please either execute the all-in-one setup script:
          docker run --rm --privileged $image setup-host
        OR manually execute:
          echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
          sudo sysctl -w vm.nr_overcommit_hugepages=1048576

Automatische Speicherverwaltung zur Laufzeit

AlloyDB Omni überwacht ständig die Systemlast und passt den Speicherverbrauch an, um die Leistung zu verbessern. Konkret kann Folgendes auftreten:

Dynamische shared_buffers Größenänderung

AlloyDB Omni erhöht die dynamische shared_buffers-Größe, wenn der Systemspeicherverbrauch niedrig ist, und verringert die Größe, wenn der Systemspeicherverbrauch hoch ist. So überwachen Sie die dynamische Größe von shared_buffers:

CREATE EXTENSION IF NOT EXISTS g_memory;
SELECT g_dynamic_shared_size();

Beenden einer PostgreSQL-Verbindung, wenn das System nur noch sehr wenig Arbeitsspeicher hat

Wenn AlloyDB Omni erkennt, dass das System nur noch sehr wenig Arbeitsspeicher hat, werden die PostgreSQL-Verbindungen mit dem höchsten Arbeitsspeicherverbrauch gelöscht, bis die Last wieder ein angemessenes Niveau erreicht. Wenn ein solches Ereignis eintritt, protokolliert AlloyDB Omni Folgendes in den Docker-Containerlogs:

WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)