Leistung von AlloyDB Omni mithilfe der E/A-Beschleunigung verbessern

Wählen Sie eine Dokumentationsversion aus: 16.3.0

• Aktuell (16.8.0)
• 16.8.0
• 16.3.0

Vorschau – AlloyDB Omni

Diese Funktion unterliegt den Pre-GA-Angebotsbedingungen im Abschnitt mit den allgemeinen Dienstbedingungen der dienstspezifischen Nutzungsbedingungen. YouSie können personenbezogene Daten für diese Funktion gemäß dem Zusatz zur Verarbeitung von Cloud-Daten verarbeiten, vorbehaltlich der in der Vereinbarung beschriebenen Verpflichtungen und Einschränkungen, in denen Sie auf Google Cloud zugreifen. Pre-GA‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Markteinführungsphase.

Auf dieser Seite wird beschrieben, wie Sie eine Reihe von I/O-Beschleunigungsfunktionen in AlloyDB Omni aktivieren, mit denen Sie die Nutzung von Rechen- und I/O-Ressourcen optimieren können, um Arbeitslasten und die Abfrageleistung zu beschleunigen.

Hinweis :Die AlloyDB Omni-Funktionen zur Beschleunigung von Ein-/Ausgabe werden nur für Sandbox- und Entwicklungszwecke empfohlen.

Folgende Funktionen sind enthalten:

• Beschädigter Schreibschutz
• O_DIRECT-Support
• Asynchrone E/A (AIO)
• Streaming-Lesevorgänge

Um diese Funktionen zur I/O-Beschleunigung zu aktivieren, aktivieren Sie die alloydb_omni_atomic Grand Unified Configuration (GUC) und richten Sie AlloyDB Omni so ein, dass die GUC verwendet werden kann.

Funktionen zur E/A-Beschleunigung

In den folgenden Abschnitten werden die Funktionen zur I/O-Beschleunigung beschrieben, die das alloydb_omni_atomic GUC ermöglicht.

Beschädigter Schreibschutz

Wenn Sie die alloydb_omni_atomic-Konfiguration aktivieren, deaktivieren Sie vollständige Seitenschreibvorgänge, um den Leistungsaufwand zu vermeiden, der durch das Generieren von Bildern der gesamten Seite für die Protokollierung entsteht.

O_DIRECT-Unterstützung

Die Unterstützung von O_DIRECT ist eine Voraussetzung für atomare Schreibvorgänge. O_DIRECT gilt für das PostgreSQL-Datenverzeichnis und den AlloyDB Omni-Festplatten-Cache. Weitere Informationen finden Sie unter Datenbankleistung mit Festplattencache beschleunigen.

O_DIRECT bietet außerdem folgende Vorteile:

• Mit O_DIRECT lässt sich das Double-Buffering-Problem in PostgreSQL vermeiden. PostgreSQL verwaltet seinen eigenen Zwischenspeichercache und kann den Zwischenspeichercache des Betriebssystemkerns umgehen.
• O_DIRECT reduziert den CPU- und Arbeitsspeicheraufwand für den Betrieb des Systems, der für die Verwaltung des Kernel-Puffercaches erforderlich ist.

Asynchrone E/A

Die alloydb_omni_atomic-Konfiguration bietet asynchrone E/A-Funktionen (AIO) mit den Bibliotheken io_uring und libaio. Wir empfehlen, io_uring zu verwenden, um die Einschränkungen der älteren libaio-Bibliothek zu vermeiden. AlloyDB Omni greift auf libaio zurück, wenn keine Unterstützung für io_uring erkannt wird. Dieser Ansatz gleicht den Verlust der Vorteile von gepufferter E/A wie Read-Ahead und Write-Combining aus und sorgt dafür, dass die verfügbare E/A-Bandbreite des zugrunde liegenden angebotenen Speichers maximiert wird.

Streaming-Lesevorgänge

AlloyDB Omni verwendet Streaming-Lesevorgänge, ähnlich wie die PostgreSQL 17-Funktion, die die Leistung von sequenziellen Scans, ANALYZE und pg_prewarm verbessert, indem vektorisierte E/A verwendet wird, um mehrere Blöcke in den Puffer-Cache zu lesen. Vektorisierte E/A ist eine Methode, bei der mit einem einzigen Prozeduraufruf Daten aus mehreren Puffern vorab abgerufen werden können. Dadurch wird die Effizienz verbessert, da Kontextwechsel und Systemaufrufe reduziert werden.

AlloyDB Omni unterstützt jetzt Streaming-Lesevorgänge für Lesevorgänge aus dem AlloyDB Omni-Festplatten-Cache mit AIO, um die Leseleistung zu steigern. Dieser Ansatz ermöglicht ein effektives Vorauslesen von Puffern in den Shared-Memory-Pool aus dem Speicher für Abfragen, anstatt diese Blöcke jedes Mal aus dem Speicher lesen zu müssen, wenn sie benötigt werden.

Hinweise

1. Prüfen Sie, ob Ihr Betriebssystem und Ihr Dateisystem unterstützt werden.

   1. Prüfen Sie die Kernel-Version, um sicherzustellen, dass der Kernel RWF_ATOMIC unterstützt. Im folgenden Beispiel verwenden Sie einen Computer mit Ubuntu 24.10, auf dem der Linux-Kernel 6.14 ausgeführt wird, der atomare Schreibvorgänge unterstützt.

      > sudo hostnamectl
       ...
       Operating System: Ubuntu 24.10
            Kernel: Linux 6.14.0-061400rc5-generic
      ...
      

   2. Wenn Ihr Kernel RWF_ATOMIC nicht unterstützt, empfehlen wir, dass Sie auf eine Kernelversion aktualisieren, die RWF_ATOMIC unterstützt.

2. Wenn Sie die AlloyDB Omni-Funktionen zur E/A-Beschleunigung verwenden möchten, um Leistungssteigerungen mit dem Schutz vor unvollständigen Schreibvorgängen zu testen, aktivieren Sie die alloydb_omni_atomic Grand Unification Configuration (GUC). Damit Sie diese GUC verwenden können, benötigen Sie einen unterstützenden Kernel und ein Dateisystem, die atomare E/A ermöglichen und vor unvollständigen Schreibvorgängen schützen.

   Das Flag RWF_ATOMIC wird für die Unterstützung von atomaren Schreibvorgängen verwendet. Standardmäßig wird die Kompatibilität für RWF_ATOMIC beim Start geprüft. PostgreSQL kann nicht gestartet werden, wenn atomare Schreibvorgänge mit dem Flag RWF_ATOMIC nicht bestätigt werden können.

   Sie können dieses Standardverhalten überschreiben. Wir empfehlen jedoch, eine unterstützte Plattform und die Option force zu verwenden, um zu vermeiden, dass optimale Konfigurationseinstellungen versehentlich überschrieben werden.

   Sie können die RWF_ATOMIC-Kompatibilitätsprüfung mit der Optionforce_unsafe überschreiben. Die Datensicherheit ist bei dieser Überschreibung jedoch nicht garantiert. Wir empfehlen, diese Option nur zu verwenden, wenn Sie AlloyDB Omni in einer Umgebung testen, die nicht aktualisiert werden kann, um den entsprechenden Kernel und das entsprechende Dateisystem zu verwenden.

   In der folgenden Tabelle sind die alloydb_omni_atomic-Konfigurationseinstellungen und die entsprechenden Kompatibilitätsprüfungen aufgeführt.

   alloydb_omni_atomic Wert	Kompatibilitätsprüfung für Start-ups	Beschreibung
   off	–	Mit diesem Wert wird der atomare Modus deaktiviert. Die Funktion ist inaktiv.
   force	Führt eine Kompatibilitätsprüfung beim Start durch. Startet nicht, wenn der Schreibvorgang für RWF_ATOMIC fehlschlägt.	Legt Konfigurationen für den atomaren Modus fest.
   force_unsafe	Es wird keine Kompatibilitätsprüfung beim Start durchgeführt. Gibt eine Warnung zurück, wird aber fortgesetzt, wenn RWF_ATOMIC-Schreiben fehlschlägt.	Legt Konfigurationen für den atomaren Modus fest.

   In der force/force_unsafe-Konfiguration werden die Konfigurationen full_page_writes, io_combine_limit und debug_io_direct automatisch festgelegt. Sie können diese Konfigurationen mit der optionalen Konfiguration on/on_unsafe überschreiben.

AlloyDB Omni-Funktionen zur I/O-Beschleunigung einrichten

1. Richten Sie das XFS-Dateisystem für das Datenverzeichnis ein. XFS wird verwendet, weil es eine Dateisystemblockgröße unterstützt, die größer als die Seitengröße ist. AlloyDB Omni kann XFS verwenden, um 8-KiB-Blöcke atomar mit vollständiger RWF_ATOMIC-Unterstützung zu schreiben.

   1. Erstellen Sie ein XFS-Dateisystem mit einer Blockgröße von 8 KiB und stellen Sie es am gewünschten Speicherort des Datenverzeichnisses (DATA_DIR) bereit.

      sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
      sudo mount /dev/$DEVICE DATA_DIR
      

      Ersetzen Sie Folgendes:

      • DATA_DIR: Der Speicherort des Datenverzeichnisses.

   2. Prüfen Sie die Kernel-Logs, um sicherzustellen, dass 8k-Blöcke verwendet werden:

      > sudo journalctl -f
      ...
      kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
      kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
      ...
      

2. Optional: Richten Sie den AlloyDB Omni-Festplatten-Cache ein.

   Verwenden Sie das folgende Beispiel, um ein Dateisystem mit ext4, zu erstellen und dann das Dateisystem zu mounten.

   sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
   sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
   

   Ersetzen Sie Folgendes:

   • DEVICE: Die Einheit, mit der die Anwendung interagiert, um E/A-Vorgänge (Lesen oder Schreiben von Daten) auszuführen.

   Damit die E/A-Beschleunigungsfunktionen von AlloyDB Omni optimal funktionieren, wenn der primäre Speicher keine höheren Input/Output Operations Per Second (IOPS) bietet, empfehlen wir, den AlloyDB Omni-Festplatten-Cache einzurichten. Weitere Informationen finden Sie unter Datenbankleistung mit Festplattencache beschleunigen.

   Hinweis :Der Festplatten-Cache muss keine atomaren Schreibvorgänge unterstützen, da die Daten im Cache kurzlebig sind. Die Funktionen zur Beschleunigung von E/A-Vorgängen in AlloyDB Omni verwenden jedoch weiterhin O_DIRECT für den Zugriff auf den Cache.

3. Laden Sie AlloyDB Omni herunter und führen Sie es aus.

   1. Laden Sie den neuesten AlloyDB Omni-Docker-Container herunter. Weitere Informationen finden Sie unter AlloyDB Omni auf einer VM installieren.
   2. Eine Anleitung zur Verwendung des Festplatten-Cache finden Sie unter Datenbankleistung mit Festplatten-Cache steigern.

   3. Um io_uring zuzulassen, fügen Sie ein zusätzliches Argument hinzu: --security-opts="seccomp:unconfined".

      docker run -d --name CONTAINER_NAME \
         -e POSTGRES_PASSWORD=NEW_PASSWORD \
         -v DATA_DIR:/var/lib/postgresql/data \
         -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
         -p HOST_PORT:5432 \
         --security-opts="seccomp:unconfined" \
         --restart=always \
         google/alloydbomni:16
      

      Ersetzen Sie die folgenden Werte:

      • CONTAINER_NAME: Der Name des AlloyDB Omni-Containers in der Containerregistrierung Ihres Hostcomputers.
      • NEW_PASSWORD: Das Passwort, das dem PostgreSQL-Nutzer des Containers zugewiesen ist.
      • DATA_DIR: Der Speicherort des Datenverzeichnisses.
      • CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: der Pfad zum Festplatten-Cache-Verzeichnis im Container.
      • HOST_PORT: Der TCP-Port auf dem Hostcomputer, an den der Container seinen eigenen Port 5432 veröffentlichen soll.

4. AlloyDB Omni für die Verwendung von atomaren E/A konfigurieren

   Legen Sie für die GUC alloydb_omni_atomic einen geeigneten Wert fest und starten Sie den Container neu.

   alter system set alloydb_omni_atomic='force';
   sudo docker restart CONTAINER_NAME;
   

   Ersetzen Sie die folgenden Werte:

   • CONTAINER_NAME: Der Name des AlloyDB Omni-Containers in der Containerregistrierung Ihres Hostcomputers.

Beschränkungen

• PostgreSQL 16 enthält Pfade, die Single-Block-I/O ausführen, was O_DIRECT verlangsamt. Während der Datenbankwiederherstellung (Redo-Pfad), bei VACUUM-Scans und beim Vorwärmen des Omni-Festplatten-Cache kann es zu langsameren Lesevorgängen kommen.
• Die AlloyDB Omni-I/O-Beschleunigungsfunktionen in Lesereplikaten werden in der Vorschau nicht unterstützt.
• Bei hoher Arbeitslast kann die Leistung von ARM-basierten Systemen aufgrund von Architekturunterschieden geringer sein.
• Aufgrund der Einschränkungen bei erhöhten Arbeitslasten ist libaio anfällig für Ressourcenverfügbarkeitsprobleme. Bei io_uring können Probleme bei der Speicherzuweisung auftreten, wenn der verfügbare Systemspeicher knapp wird.