Hyperdisk-Leistung optimieren

Nachdem Sie Ihre Google Cloud Hyperdisk-Volumes bereitgestellt haben, erfordern Ihre Anwendung und Ihr Betriebssystem möglicherweise eine Leistungsoptimierung, um Ihre Leistungsanforderungen zu erfüllen.

In den folgenden Abschnitten werden einige wichtige Elemente beschrieben, die sich zur Leistungsoptimierung anpassen lassen. Außerdem wird erläutert, wie Sie einige dieser Elemente auf bestimmte Arten von Arbeitslasten anwenden können.

Eine Übersicht über die Leistung von Google Cloud Hyperdisk finden Sie unter Informationen zur Hyperdisk-Leistung.

Hohe E/A-Warteschlangentiefe verwenden

Hyperdisk-Volumes haben eine höhere Latenz als lokal angehängte Laufwerke wie lokale SSDs, da sie mit dem Netzwerk verbunden sind. Sie können einen sehr hohen IOPS-Wert und Durchsatz bieten, aber Sie müssen dafür sorgen, dass E/A-Anfragen parallel ausgeführt werden. Die Anzahl der parallel ausgeführten E/A-Anfragen wird als E/A-Warteschlangentiefe bezeichnet.

In den folgenden Tabellen finden Sie die empfohlene E/A-Warteschlangentiefe, um ein bestimmtes Leistungsniveau zu erreichen. Die Tabellen verwenden eine geringfügige Überschätzung der typischen Latenz, um konservative Empfehlungen anzuzeigen. Im Beispiel wird davon ausgegangen, dass Sie eine E/A-Größe von 16 KB verwenden.

Gewünschte IOPS Größe der Warteschlange
500 1
1.000 2
2.000 4
4.000 8
8.000 16
16.000 32
32.000 64
64.000 128
100.000 200
200.000 400
320.000 640
Gewünschter Durchsatz (MB/s) Größe der Warteschlange
8 1
16 2
32 4
64 8
128 16
256 32
512 64
1.000 128
1.200 153

Kostenlose CPUs sicherstellen

Für das Lesen und Schreiben in Hyperdisk-Volumes sind CPU-Zyklen auf der VM erforderlich. Wenn die VM-Instanz nicht genügend CPU-Kapazität hat, kann die Anwendung die oben angegebenen IOPS nicht verarbeiten. Sie benötigen CPUs kostenlos für die Verarbeitung von E/A-Vorgängen, um sehr hohe, konsistente IOPS-Level zu erreichen.

Schutz vor unvollständigen Schreibvorgängen auf Datenbankebene deaktivieren, um Schreibvorgänge zu optimieren

Da Google Cloud Hyperdisk einen integrierten Schutz vor unvollständigen Schreibvorgängen bietet, können Sie Schutzfunktionen auf Datenbankebene deaktivieren, um den I/O-Overhead zu reduzieren und den Schreibdurchsatz der Datenbank um bis zu 25 % zu steigern. Weitere Informationen zu diesem Feature finden Sie auf der Übersichtsseite zu Hyperdisk unter Torn-Write-Schutz.

Anforderungen an die Umgebungskonfiguration

Damit der Schutz vor unvollständigen Schreibvorgängen von Hyperdisk wirksam ist, dürfen Datenbankschreibvorgänge nicht fragmentiert werden, bevor sie die Speicherebene erreichen. Je nach Datenbank können Sie dies mit einer der folgenden Konfigurationsoptionen erreichen:

Option 1: Ebenen an 16 KiB-Blockgrenzen ausrichten (empfohlen für MySQL und PostgreSQL)

Konfigurieren Sie Ihr Betriebssystem, Ihr Dateisystem und die Zwischensoftwareschichten so, dass die 16 KiB-Grenze eingehalten wird. Wenn Sie diese Option verwenden, müssen Sie diese spezielle Konfiguration beibehalten:

  • Dateisystem: Verwenden Sie ein ext4-Dateisystem. Sie müssen das Dateisystem mit der Option bigalloc erstellen und die Clustergröße des Dateisystems auf 16 KiB (16.384 Byte) oder ein größeres Zweierpotenz-Vielfaches von 16 KiB festlegen:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>

    Ersetzen Sie DEVICE_NAME durch den Namen des Speichermediums.

  • Nicht unterstützte Konfigurationen: Vermeiden Sie Konfigurationen, die zu unvollständigen Schreibvorgängen über der Blockspeicher-Ebene führen können, z. B.:

    • Ausführen von containerisierten Datenbanken in Google Kubernetes Engine oder selbst gehosteten Kubernetes-Clustern.
    • Datenbankdateien werden in einem xfs-Dateisystem gespeichert, das in den meisten Linux-Distributionen in der Regel keine ausreichenden Blockgrößen unterstützt.
    • Verwendung von RAID-Konfigurationen (Redundant Array of Independent Disks) oder Logical Volume Managern (LVM), die E/A-Vorgänge aufteilen.
    • Hyperdisk mit lokalen SSD-Caches verwenden, einschließlich lvmcache, dm-cache oder bcache.
    • Verschachtelte Virtualisierung für die Datenbank-VM verwenden.

Option 2: Atomare Block-E/A von Linux verwenden (empfohlen für MariaDB)

Wenn Ihre Datenbank oder Anwendung atomare Block-E/A unter Linux unterstützt und auf Dateien über Direct I/O (O_DIRECT) zugreift, können Sie die in Option 1 aufgeführten Konfigurationsregeln umgehen, sofern Sie die folgenden Bedingungen erfüllen:

  • RWF_ATOMIC-Flag: Die Anwendung muss den Systemaufruf pwritev2() mit dem Flag RWF_ATOMIC verwenden. Wenn Sie dieses Flag verwenden, sorgt der Linux-Kernel dafür, dass ein Schreibvorgang vom zugrunde liegenden Hyperdisk-Gerät als einzelner zusammenhängender Block verarbeitet wird. Wenn der Kernel die Atomizität nicht garantieren kann, schlägt der Schreibaufruf sofort fehl, um Datenbeschädigungen zu verhindern.
  • Betriebssystem: Linux-Kernel-Version 6.11 oder höher
  • Dateisystem: Muss ext4 oder xfs unter Linux-Kernel-Version 6.13 oder höher sein.
  • Dateizugriff: Die Anwendung muss Datenbankdateien über direkte E/A (O_DIRECT) öffnen.
  • Unterstützte Datenbanken: Wir empfehlen diese Option nur für MariaDB-Version 11.x oder höher (für die generische Linux-Unterstützung von RWF_ATOMIC). MySQL und PostgreSQL unterstützen diese Funktion nicht.

Eine detaillierte datenbankspezifische Optimierungsanleitung finden Sie unter MySQL in Compute Engine konfigurieren.

Hyperdisk-Leistungsmesswerte prüfen

Sie können Leistungsmesswerte für das Laufwerk in Cloud Monitoring, der integrierten Monitoring-Lösung vonGoogle Cloud, prüfen. Mithilfe dieser Messwerte können Sie die Leistung Ihrer Laufwerke und anderer VM-Ressourcen unter verschiedenen Anwendungsarbeitslasten beobachten.

Weitere Informationen finden Sie unter Leistungsmesswerte für Laufwerk prüfen.

Sie können auch die Seite Beobachtbarkeit in der Console verwenden, um die Leistungsmesswerte des Laufwerks aufzurufen.

Nächste Schritte