Leistung von nichtflüchtigen Speichern optimieren

Nichtflüchtige Speicher optimieren

Nichtflüchtiger Speicher liefert die in der Tabelle mit den Speichertypen angegebene Leistung, wenn die VM ausreichend genutzt wird, um die Leistungsobergrenzen zu erreichen. Nachdem Sie die Größe der nichtflüchtigen Speicher-Volumes an Ihre Leistungsanforderungen angepasst haben, müssen Sie unter Umständen noch die Anwendung und das Betriebssystem feinabstimmen.

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

Hohe E/A-Lasten auf einen Span von 50 TB begrenzen

Hinweis: Bei E/A-Lasten wird eine maximale Leistung erzielt, wenn sie auf einen Span von 50 TB begrenzt sind. Spans auf separaten nichtflüchtigen Speichern, die zusammen maximal 50 TB ergeben, können zu Leistungszwecken als ein Span von 50 TB betrachtet werden. Ein Span bezeichnet einen zusammenhängenden Bereich logischer Blockadressen auf einem einzelnen physischen Laufwerk.

Verzögerte Initialisierung deaktivieren und DISCARD-Befehle aktivieren

Nichtflüchtige Speicher unterstützen DISCARD- oder TRIM-Befehle, mit denen Betriebssysteme die Laufwerke über nicht mehr verwendete Blöcke informieren können. Mithilfe von DISCARD können Laufwerkblöcke vom Betriebssystem als nicht mehr benötigt markiert werden, ohne dass Kosten für die Nullsetzung der Blöcke anfallen.

Bei den meisten Linux-Betriebssystemen aktivieren Sie DISCARD, wenn Sie einen nichtflüchtigen Speicher auf Ihrer Instanz bereitstellen. Windows Server 2012 R2-Instanzen aktivieren DISCARD standardmäßig, wenn ein nichtflüchtiger Speicher bereitgestellt wird. Von Windows Server 2008 R2 wird DISCARD nicht unterstützt.

Durch Aktivieren von DISCARD kann die allgemeine Laufzeitleistung gesteigert und außerdem die Leistung Ihres Laufwerks bei der anfänglichen Bereitstellung beschleunigt werden. Das Formatieren eines ganzen Laufwerk-Volumes kann zeitaufwendig sein, weshalb "lazy formatting" gängig ist. Der Nachteil ist, dass die Kosten für ein "lazy formatting" oftmals dann bezahlt werden, wenn das Datenvolumen das erste Mal bereitgestellt wird. Durch die Deaktivierung von "lazy initialization" und die Aktivierung von DISCARD-Befehlen erhalten Sie eine schnelle Formatierung und Bereitstellung.

  • Übergeben Sie bei der Formatierung folgende Parameter an mkfs.ext4, um "lazy initialization" zu deaktivieren und DISCARD zu aktivieren:

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    Der Parameter lazy_journal_init=0 funktioniert nicht auf Instanzen mit CentOS 6- oder RHEL 6-Images. Formatieren Sie für diese Instanzen nichtflüchtige Speicher ohne diesen Parameter.

    -E lazy_itable_init=0,discard
    
  • Aktivieren Sie DISCARD-Befehle bei der Bereitstellung. Übergeben Sie hierfür das folgende Flag an den Bereitstellungsbefehl:

    -o discard
    

Nichtflüchtige Speicher funktionieren gut, wenn die Option discard aktiviert ist. Optional können Sie doch auch fstrim in regelmäßigen Abständen zusätzlich zur Option oder anstelle der Option discard ausführen. Wenn Sie die Option discard nicht verwenden, führen Sie fstrim aus, bevor Sie einen Snapshot Ihres Laufwerks erstellen. Durch das Trimmen des Dateisystems können Sie kleinere Snapshot-Images erstellen und dadurch die Kosten für deren Speicherung reduzieren.

E/A-Warteschlangentiefe

Die Einstellungen vieler Anwendungen wirken sich auf ihre E/A-Warteschlangentiefe aus. Bei größeren Warteschlangentiefen erhöht sich neben dem IOPS-Wert unter Umständen auch die Latenz. Niedrigere Warteschlangentiefen verringern die E/A-Latenz, können jedoch zu niedrigeren maximalen IOPS-Werten führen.

Readahead-Cache

Zur Verbesserung der E/A-Leistung nutzen Betriebssysteme Techniken wie Readahead. Dabei werden von einer Datei mehr Daten als angefordert in den Arbeitsspeicher gelesen. Es wird davon ausgegangen, dass diese Daten bei nachfolgenden Lesevorgängen benötigen werden. Ein höherer Readahead-Wert erhöht den Durchsatz, allerdings auf Kosten des Arbeitsspeichers und der IOPS-Werte. Ein niedrigerer Readahead-Wert erhöht die IOPS-Werte, jedoch zulasten des Durchsatzes.

Auf Linux-Systemen können Sie den Readahead-Wert mit dem Befehl "blockdev" abrufen und festlegen:

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

Der Readahead-Wert ist <desired_readahead_bytes> / 512 Byte.

Beispiel: Bei einem 8-MB-Readahead sind 8 MB = 8.388.608 Byte (8 * 1024 * 1024).

8388608 bytes / 512 bytes = 16384

Legen Sie für "blockdev" 16384 fest:

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

Freie CPUs

Für das Lesen und Schreiben in nichtflüchtigen Speicher sind CPU-Zyklen auf der VM erforderlich. Wenn Sie sehr hohe, konsistente IOPS-Level erreichen möchten, benötigen Sie freie CPUs für die E/A-Verarbeitung.

IOPS-orientierte Workloads

Datenbanken, ob SQL oder NoSQL, haben Nutzungsmuster mit zufälligem Zugriff auf Daten. Google empfiehlt für IOPS-orientierte Arbeitslasten die folgenden Werte:

  • Den Wert 1 für E/A-Warteschlangentiefen pro 400–800 IOPS, bis zu maximal 64 auf großen Volumes

  • Eine freie CPU pro 2.000 zufälliger Lese-IOPS und eine freie CPU pro 2.500 zufälliger Schreib-IOPS

In den Best Practices für MongoDB, Apache Cassandra und andere Datenbankanwendungen werden meist niedrigere Readahead-Werte empfohlen.

Durchsatzorientierte Arbeitslasten

Streamingvorgänge, wie zum Beispiel ein Hadoop-Job, profitieren vom schnellen sequenziellen Lesen. Durch höhere E/A-Größen kann sich außerdem die Streamingleistung verbessern. Für durchsatzorientierte Arbeitslasten werden E/A-Größen von 256 KB und höher empfohlen.

Leistung von nichtflüchtigen Standardspeichern optimieren

Mit den folgenden Best Practices erzielen Sie dauerhaft maximale Durchsatzraten für nichtflüchtige Standardspeicher:

  • Nach Möglichkeit parallele sequenzielle E/A-Streams verwenden

    Das System ist so ausgelegt, dass die E/A-Leistung für den sequenziellen Laufwerkszugriff optimiert wird, ähnlich wie bei einer echten Festplatte. Verwenden Sie daher sequenzielle E/A-Vorgänge auf nichtflüchtigen Standardspeichern.

    Durch die Verteilung von E/A-Vorgängen auf mehrere sequenzielle Streams wird die Leistung erheblich verbessert. Zum Erzielen einer möglichst hohen Konsistenz sollten Sie mindestens acht sequenzielle Streams verwenden.

  • Umfangreiche E/A-Vorgänge verwenden

    Nichtflüchtige Standardspeicher bieten einen sehr hohen Durchsatz am Limit. Verwenden Sie eine E/A-Größe von mindestens 256 KB, damit die Anwendungsleistung nicht durch IOPS-Limits und Latenz beeinträchtigt wird.

    Verwenden Sie große Datenstreifen für verteilte Dateisystemanwendungen. Eine zufällige E/A-Arbeitslast mit großen Datenstreifen (mindestens 4 MB) erzielt eine hervorragende Leistung auf nichtflüchtigen Standardspeichern, da die Arbeitslast mehrere sequenzielle Streamzugriffe simuliert.

  • Voraussetzungen für ausreichende gleichzeitige E/A-Vorgänge schaffen

    Verwenden Sie eine möglichst hohe Warteschlangentiefe, um die Parallelverarbeitung des Betriebssystems zu nutzen. Die Verwendung einer ausreichend hohen Warteschlangentiefe ist für nichtflüchtige Standardspeicher besonders wichtig, um einen Durchsatz am Limit zu erreichen, ohne Engpässe bei der Anwendung durch E/A-Latenz zu bewirken.

Leistung von nichtflüchtigem SSD-Speicher optimieren

In der nach Speichertyp sortierten Leistungstabelle sind die erwarteten, erreichbaren Leistungslimits von nichtflüchtigem SSD-Speicher aufgeführt. Damit Ihre Anwendungen und VM-Instanzen diese Geschwindigkeiten erreichen, verwenden Sie die folgenden Best Practices:

  • Voraussetzungen für die Generierung ausreichender E/A-Vorgänge durch die Anwendung schaffen

    Wenn die Anwendung weniger IOPS als in der vorangegangenen Tabelle generiert, erreichen Sie das IOPS-Level nicht. Auf einem 500-GB-Laufwerk liegt das erwartete IOPS-Limit beispielsweise bei 15.000 IOPS. Werden allerdings weniger IOPS generiert oder sind die E/A-Vorgänge größer als 8 KB, werden Sie keine 15.000 IOPS erzielen.

  • Voraussetzungen für ausreichende gleichzeitige E/A-Vorgänge schaffen

    Verwenden Sie eine ausreichend hohe Warteschlangentiefe, um die Parallelverarbeitung des Betriebssystems zu nutzen. Wenn Sie 1.000 IOPS synchron mit einer Warteschlangentiefe von 1 bereitstellen, liegen die erzielten IOPS deutlich unter dem in der Tabelle angegebenen Limit. Die Anwendung sollte pro 400–800 IOPS mindestens eine Warteschlangentiefe von 1 haben.

  • Ausreichend verfügbare CPU-Kapazität auf der Instanz bereitstellen, auf der die E/A-Vorgänge generiert werden

    Wenn die VM-Instanz nicht genügend CPU-Kapazität hat, kann die Anwendung die oben angegebenen IOPS nicht verarbeiten. Wir empfehlen eine verfügbare CPU pro 2.000–2.500 IOPS des erwarteten Traffics.

  • Anwendung auf großen Laufwerken für einen angemessenen, temporären Datenspeicherort optimieren

    Wenn die Anwendung auf Daten zugreift, die für einen kurzen Zeitraum auf verschiedene Bereiche eines Laufwerks verteilt sind (mehrere hundert GB pro vCPU), wird kein optimaler IOPS-Wert erreicht. Für maximale Leistung müssen Sie den temporären Datenspeicherort optimieren. Berücksichtigen Sie dabei Faktoren wie die Laufwerkfragmentierung und die Zufälligkeit des Zugriffs auf Bereiche des Laufwerks.

  • E/A-Planer im Betriebssystem entsprechend Ihren Anforderungen konfigurieren

    Auf Linux-basierten Systemen können Sie den E/A-Planer auf noop festlegen, um die höchste Anzahl von IOPS auf SSD-unterstützten Geräten zu erzielen.

Benchmarking der Leistung von nichtflüchtigen SSD-Speichern

Bei den folgenden Befehlen wird von einem PD-SSD-Gerät mit 2.500 GB ausgegangen. Wenn Ihr Gerät eine andere Kapazität hat, ändern Sie den Wert des Arguments --filesize. Diese Laufwerkgröße ist erforderlich, um die aktuellen Durchsatzlimits für eine VM mit 32 vCPUs zu erreichen.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Füllen Sie den Speicher mit Daten ungleich null. Lesevorgänge aus leeren Blöcken von nichtflüchtigem Speicher haben ein anderes Latenzprofil als aus Blöcken, die Daten enthalten. Wir empfehlen daher, die Festplatte zu füllen, bevor Lese-Latenz-Benchmarks ausgeführt werden.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Testen Sie die Schreibbandbreite mithilfe sequenzieller Schreibvorgänge mit mehreren parallelen Streams (mindestens acht) mit einer E/A-Größe von 1 MB und einer E/A-Tiefe von mindestens 64.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=write --numjobs=8 --offset_increment=100G
    
  3. Testen Sie die Schreib-IOPS. Damit das IOPS-Limit des nichtflüchtigen Speichers erreicht werden kann, muss die E/A-Warteschlange eine entsprechende Tiefe haben. Wenn beispielsweise die Schreiblatenz 1 Millisekunde beträgt, können für die VM höchstens 1.000 IOPS für jeden aktiven E/A-Vorgang erreicht werden. Für 15.000 IOPS muss die VM mindestens 15 E/A-Vorgänge gleichzeitig ausführen. Damit Speicher und VM 30.000 IOPS erreichen können, sind mindestens 30 aktive E/A-Vorgänge erforderlich. Wenn die E/A-Größe 4 KB übersteigt, kann das Bandbreitenlimit für die VM vor dem IOPS-Limit erreicht werden.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Testen Sie die Schreiblatenz. Beim Test der E/A-Latenz darf die VM nicht das Bandbreiten- oder IOPS-Limit erreichen. Andernfalls spiegelt die Latenz nicht die tatsächliche E/A-Latenz des nichtflüchtigen Speichers wider. Wenn beispielsweise das IOPS-Limit bei einer E/A-Tiefe von 30 erreicht wird und der Befehl fio doppelt so groß ist, ändern sich die IOPS-Gesamtwerte nicht, während sich die gemeldete E/A-Latenz verdoppelt.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Testen Sie die Lesebandbreite mithilfe sequenzieller Lesevorgänge mit mehreren parallelen Streams (mindestens acht) mit einer E/A-Größe von 1 MB und einer E/A-Tiefe von mindestens 64.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=read --numjobs=8 --offset_increment=100G
    
  6. Testen Sie die Lese-IOPS. Damit das IOPS-Limit des nichtflüchtigen Speichers erreicht werden kann, muss die E/A-Warteschlange eine entsprechende Tiefe haben. Wenn die E/A-Größe beispielsweise 4 KB übersteigt, kann das Bandbreitenlimit für die VM vor dem IOPS-Limit erreicht werden. Geben Sie --iodepth=256 für diesen Test ein, um das Maximum von 100.000 Lese-IOPS zu erreichen.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=256 --rw=randread
    
  7. Testen Sie die Leselatenz. Es ist wichtig, den Speicher mit Daten zu füllen, um eine realistische Latenzmessung zu erhalten. Die VM darf während dieses Tests nicht das IOPS- oder Durchsatzlimit erreichen. Ist dies der Fall, werden eingehende E/A-Vorgänge verzögert, was zu einer künstlichen Erhöhung der E/A-Latenz führt.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Testen Sie die sequenzielle Lesebandbreite.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=read
    
  9. Testen Sie die sequenzielle Schreibbandbreite.

    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=write
    

Nächste Schritte

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation