Automatische Arbeitsspeicherverwaltung

AlloyDB Omni verwendet adaptive Algorithmen für die Arbeitsspeicherverwaltung.

Sie können die Obergrenze des gemeinsamen Buffers beim Starten von AlloyDB Omni festlegen. Wenn Sie kein Oberlimit festlegen, wird in AlloyDB Omni automatisch eine Größe von 80% des Systemspeichers für die Sicherung des gemeinsamen Buffers festgelegt. Die anfängliche Größe der Sicherung des freigegebenen Buffers kann von der Obergrenze abweichen.

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

Automatischer Arbeitsspeicher

Standardmäßig ist der Parameter shared_buffers auf 0 festgelegt. Dies ist ein spezieller Wert, der die Obergrenze der Größe des shared buffers-Cache auf 80% des Systemspeichers festlegt. AlloyDB Omni beginnt bei 10% des oberen Grenzwerts von shared_buffers. Wenn shared_buffers durch einen benutzerdefinierten Wert überschrieben wird, wird dieser Wert in AlloyDB Omni als Obergrenze für die Größe von shared_buffers verwendet und die Berechnung beginnt mit dieser benutzerdefinierten Größe.

Wenn Sie eine benutzerdefinierte Größe angeben möchten, bearbeiten Sie die Konfigurationsdatei postgresql.conf. Sie können shared_buffers beispielsweise 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 funktioniert für gängige Szenarien.

Sie können den Wert jedoch für eine optimale Leistung anpassen. Wenn Sie sich für den Standardwert von shared_buffers entscheiden, um das obere Grenzwert des freigegebenen Buffers 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 spaltenorientierte Engine aktiviert ist, kann die dynamische shared_buffers-Größe ermittelt werden, indem der von der spaltenorientierten Engine verwendete Speicher von 80% des für das System oder die Cgroup verfügbaren Gesamtspeichers abgezogen wird.

Huge Pages

Huge Pages verbessern die Datenbankleistung. AlloyDB Omni verwaltet HugePages 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, wechselt AlloyDB Omni zu 4K-Seiten und druckt in den Docker-Container-Logs docker logs $container_name eine Warnung mit einer spezifischen Anleitung zum Einrichten von Huge Pages aus. Eine Anleitung zum Starten eines Containers finden Sie unter AlloyDB Omni starten.

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 die Systemlast kontinuierlich und passt den Speicherverbrauch an, um die Leistung zu verbessern. Insbesondere können folgende Probleme auftreten:

Dynamische shared_buffers-Größenänderung
AlloyDB Omni erhöht die Größe des dynamischen shared_buffers, wenn der Systemarbeitsspeicherverbrauch niedrig ist, und verringert die Größe, wenn der Systemarbeitsspeicherverbrauch hoch ist. So überwachen Sie die dynamische shared_buffers-Größe: 
CREATE EXTENSION IF NOT EXISTS g_memory;
SELECT g_dynamic_shared_size();
Beenden einer PostgreSQL-Verbindung, wenn der Arbeitsspeicher des Systems extrem knapp ist
Wenn AlloyDB Omni erkennt, dass dem System nur noch sehr wenig Arbeitsspeicher zur Verfügung steht, versucht es, die PostgreSQL-Verbindungen mit dem höchsten Arbeitsspeicherverbrauch zu löschen, bis die Auslastung wieder auf ein angemessenes Niveau sinkt. In diesem Fall protokolliert AlloyDB Omni Folgendes in den Docker-Container-Logs: 
WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)