Automatische Speicherverwaltung

Wählen Sie eine Dokumentationsversion aus:

AlloyDB Omni verwendet adaptive Algorithmen für die Arbeitsspeicherverwaltung.

Sie können das obere Limit des gemeinsam genutzten Puffers beim Starten von AlloyDB Omni festlegen. Wenn Sie das obere Limit nicht festlegen, legt AlloyDB Omni die Größe des gemeinsam genutzten Puffers automatisch auf 80% des Systemspeichers fest. Die anfängliche Größe des gemeinsam genutzten Puffers kann sich vom oberen Limit unterscheiden.

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

Automatischer Arbeitsspeicher

Standardmäßig ist der Parameter shared_buffers auf 0 gesetzt. Dieser spezielle Wert legt das obere Limit für die Größe des shared buffers-Cache auf 80% des Systemspeichers fest. AlloyDB Omni beginnt bei 10% des oberen Limits von shared_buffers. Wenn shared_buffers durch einen benutzerdefinierten Wert überschrieben wird, verwendet AlloyDB Omni diesen Wert als oberes Limit für die Größe von shared_buffers und beginnt mit der angegebenen benutzerdefinierten Größe.

Wenn Sie eine benutzerdefinierte Größe angeben möchten, können Sie shared_buffers auf 1GB setzen. Die Methode hängt von Ihrem Bereitstellungstyp ab:

Verwenden Sie für Docker-Container-Bereitstellungen einen der folgenden Befehle:

  • 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 gängige Szenarien geeignet.

Sie können den Wert jedoch für eine optimale Leistung anpassen. Wenn Sie den Standardwert von shared_buffers verwenden möchten, um das obere Limit des gemeinsam genutzten Puffers abzuleiten, verwenden Sie den Wert memory.max der Cgroup, um die Berechnung zu beeinflussen.

Arbeitsspeicher der spaltenbasierten Engine

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

Huge Pages

Huge Pages verbessern die Datenbankleistung. AlloyDB Omni verwaltet Huge Pages nach Möglichkeit explizit. Andernfalls wird die Funktion „Transparent Huge Pages“ (THP) des Betriebssystems verwendet. Wenn keiner der beiden Huge Page-Typen unterstützt wird, greift AlloyDB Omni auf 4-KB-Seiten zurück und gibt in den Docker-Containerlogs docker logs $container_name eine Warnung mit spezifischen Anweisungen zum Einrichten von Huge Pages aus. Unter AlloyDB Omni starten finden Sie eine Anleitung zum Starten eines Containers.

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 Arbeitsspeicherverwaltung zur Laufzeit

AlloyDB Omni überwacht ständig die Systemlast und passt die Arbeitsspeichernutzung an, um die Leistung zu verbessern. Insbesondere können Sie Folgendes beobachten:

Dynamische Änderung der Größe shared_buffers
AlloyDB Omni erhöht die dynamische Größe von shared_buffers, wenn die Arbeitsspeichernutzung des Systems niedrig ist, und verringert sie, wenn die Arbeitsspeichernutzung des Systems hoch ist. Die Erweiterung `g_memory` ist in der AlloyDB Omni-Distribution enthalten. Führen Sie die folgenden Befehle aus, um sie zu aktivieren und die dynamische Größe von `shared_buffers` zu überwachen: 
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 feststellt, dass das System nur noch sehr wenig Arbeitsspeicher hat, versucht es, die PostgreSQL-Verbindungen zu löschen, die am meisten Arbeitsspeicher verbrauchen, bis die Last wieder auf ein angemessenes Niveau sinkt. In diesem Fall protokolliert AlloyDB Omni einen Eintrag ähnlich dem folgenden Beispiel in den Docker-Containerlogs: 
WARNING: Sending SIGTERM to pid=12345 NSpid=67890 (VA size = 1024MB) (RSS size = 512MB)