Leistung von AlloyDB Omni mit E/A-Beschleunigung verbessern

Wählen Sie eine Dokumentationsversion aus: Aktuell (17.5.0)

• Aktuell (17.5.0)
• 17.5.0
• 16.9.0
• 16.8.0
• 16.3.0

Vorschau – AlloyDB Omni

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Sie können personenbezogene Daten für diese Funktion gemäß dem Zusatz zur Verarbeitung von Cloud-Daten verarbeiten, vorbehaltlich der Verpflichtungen und Einschränkungen der Vereinbarung, die für den Zugriff auf Google Cloud gilt. Pre-GA-Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Auf dieser Seite wird beschrieben, wie Sie eine Reihe von E/A-Beschleunigungsfunktionen in AlloyDB Omni aktivieren, mit denen Sie die Nutzung von Compute- und E/A-Ressourcen optimieren und so die Leistung von Arbeitslasten und Abfragen steigern können.

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

Die folgenden Funktionen sind enthalten:

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

Um diese Funktionen zur E/A-Beschleunigung zu aktivieren, aktivieren Sie die alloydb_omni_atomicGrand 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 E/A-Beschleunigung beschrieben, die die 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 Images vollständiger Seiten für das Logging 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-Laufwerks-Cache. Weitere Informationen finden Sie unter Datenbankleistung mit Laufwerks-Cache beschleunigen.

O_DIRECT bietet außerdem folgende Vorteile:

• Mit O_DIRECT lässt sich das Problem des doppelten Zwischenspeicherns in PostgreSQL vermeiden. PostgreSQL verwaltet seinen eigenen Zwischenspeichercache und kann den Zwischenspeichercache des Betriebssystem-Kernels umgehen.
• O_DIRECT reduziert den CPU- und Arbeitsspeicheraufwand des Betriebssystems, der für die Verwaltung des Kernel-Zwischenspeichercaches 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 zwischengespeicherter E/A wie Readahead 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, die die Leistung von sequenziellen Scans, ANALYZE und pg_prewarm verbessern, indem vektorisierte E/A verwendet wird, um mehrere Blöcke in den Zwischenspeicher-Cache zu lesen. Vektorisierte E/A ist eine Methode, bei der mit einem einzigen Prozeduraufruf Daten aus mehreren Zwischenspeichern 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-Laufwerks-Cache mit AIO, um die Leseleistung zu steigern. Dieser Ansatz ermöglicht ein effektives Readahead von Zwischenspeichern in den gemeinsamen Arbeitsspeicher-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.

Hinweis

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, auf eine Kernelversion zu aktualisieren, die RWF_ATOMIC unterstützt.

2. Wenn Sie die AlloyDB Omni-Funktionen zur E/A-Beschleunigung verwenden möchten, um Leistungssteigerungen mit unvollständigem Schreibschutz 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 unterstützendes Dateisystem, die atomare E/A bieten 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 Option force_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, bei der die Aktualisierung auf die Verwendung des geeigneten Kernels oder des geeigneten Dateisystems unmöglich ist.

   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 beim Start	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 RWF_ATOMIC fehlschlägt.	Legt Konfigurationen für den atomaren Modus fest.
   force_unsafe	Führt keine Kompatibilitätsprüfung beim Start durch. Gibt eine Warnung zurück, wird aber fortgesetzt, wenn der Schreibvorgang RWF_ATOMIC 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 on/on_unsafe-Konfiguration überschreiben.

AlloyDB Omni-Funktionen zur E/A-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 8 K-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-Laufwerks-Cache ein.

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

   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 Entität, 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 Eingabe/-Ausgabevorgänge pro Sekunde (IOPS) bietet, empfehlen wir, den AlloyDB Omni-Laufwerks-Cache einzurichten. Weitere Informationen finden Sie unter Datenbankleistung mit Laufwerks-Cache beschleunigen.

   Hinweis: Der Laufwerks-Cache muss keine atomaren Schreibvorgänge unterstützen, da die Daten im Cache sitzungsspezifisch sind. Die E/A-Beschleunigungsfunktionen von 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 Laufwerks-Caches finden Sie unter Datenbankleistung mit Laufwerks-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:17
      

      Ersetzen Sie die folgenden Werte:

      • CONTAINER_NAME: der Name des AlloyDB Omni-Containers in der Container Registry 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 Verzeichnispfad zum Laufwerks-Cache im Container
      • HOST_PORT: der TCP-Port auf dem Hostcomputer, auf dem der Container seinen eigenen Port 5432 veröffentlichen soll

4. Konfigurieren Sie AlloyDB Omni für die Verwendung von atomarer E/A.

   Legen Sie für die alloydb_omni_atomic-GUC 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 Container Registry Ihres Hostcomputers

Beschränkungen

• PostgreSQL 17 enthält Pfade, die Einzelblock-E/A ausführen, was O_DIRECT verlangsamt. Während der Datenbankwiederherstellung (Wiederholungspfad), bei VACUUM-Scans und beim Vorwärmen des Omni-Laufwerks-Caches kann es zu langsameren Lesevorgängen kommen.
• Die E/A-Beschleunigungsfunktionen von AlloyDB Omni 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 Probleme mit der Ressourcenverfügbarkeit. Bei io_uring können Probleme mit der Arbeitsspeicherzuweisung auftreten, wenn der verfügbare Systemspeicher knapp wird.