Leistung von nichtflüchtigen Speichern und lokalen SSDs optimieren

Nichtflüchtige Speicher sind aufgrund ihres Preises, ihrer Leistung und ihrer Langlebigkeit die gängigste Speicheroption. Sie können auch lokale SSDs verwenden. Diese bieten sogar noch mehr Leistung und eine geringere Latenz, sind jedoch nicht redundant und bestehen nur für die Lebensdauer einer bestimmten Instanz. Gehen Sie so vor, um eine Speicheroption für Anwendungen zu konfigurieren, die auf Ihren Instanzen ausgeführt werden:

  • Ermitteln Sie, wie viel Speicherplatz Sie benötigen.
  • Ermitteln Sie die Leistungsanforderungen Ihrer Anwendungen.
  • Konfigurieren Sie Ihre Instanzen, um die Speicherleistung zu optimieren.

In den folgenden Abschnitten werden die verfügbaren Blockspeicheroptionen beschrieben, die Sie Ihren Compute Engine-Instanzen hinzufügen können. Eine vollständige Liste der Speicheroptionen auf der Google Cloud Platform finden Sie unter Cloud Storage-Produkte.

Blockspeicher im Leistungsvergleich

Berücksichtigen Sie beim Ermitteln des richtigen Laufwerkstyps und der passenden Größe für Ihre Instanzen Ihre Anforderungen an die Speichergröße und -leistung. Die Leistungsanforderungen für eine gegebene Anwendung lassen sich in der Regel zwei unterschiedlichen E/A-Schemata zuordnen:

  • Geringe Anzahl von Lese- und Schreibvorgängen
  • Große Anzahl von Lese- und Schreibvorgängen

Bei einer geringen Anzahl von Lese- und Schreibvorgängen ist der begrenzende Faktor die Zahl der zufälligen Ein-/Ausgaben pro Sekunde IOPS.

Bei einer großen Anzahl von Lese- und Schreibvorgängen ist der begrenzende Faktor der Durchsatz.

Die IOPS-Werte pro GB und die Durchsatzzahlen geben die aggregierte Gesamtleistung für Daten auf einem einzelnen Laufwerk wieder, unabhängig davon, ob es einer einzelnen Instanz zugeordnet ist oder ob sich mehrere Instanzen das Laufwerk teilen. Lesen mehrere Instanzen von demselben Laufwerk, teilen sich die Instanzen den aggregierten Durchsatz und die IOPS-Kapazität des Laufwerks. Zu Planungszwecken empfehlen wir die Verwendung der folgenden Durchsatzraten und IOPS-Werte pro GB:

Zonale
nichtflüchtige
Standardspeicher
Regionale
nichtflüchtige
Standardspeicher
Zonale
nichtflüchtige
SSD-Speicher
Regionale
nichtflüchtige
SSD-Speicher
Lokale SSD (SCSI) Lokale SSD (NVMe)
Maximale IOPS (kontinuierlich)
Lese-IOPS pro GB 0,75 0,75 30 30 266,7 453,3
Schreib-IOPS pro GB 1,5 1,5 30 30 186,7 240
Lese-IOPS pro Instanz 3.000* 3.000* 15.000–60.000* 15.000–60.000* 400.000 680.000
Schreibe-IOPS pro Instanz 15.000* 15.000* 15.000–30.000* 15.000–30.000* 280.000 360.000
Maximaler Durchsatz (kontinuierlich, MB/s)
Lesedurchsatz pro GB 0,12 0,12 0,48 0,48 1,04 1,77
Schreibdurchsatz pro GB 0,12 0,12 0,48 0,48 0,73 0,94
Lesedurchsatz pro Instanz 240* 240* 240–1.200* 240–1.200* 1.560 2.650
Schreibdurchsatz pro Instanz 76–240** 38–200** 76–400* 38–200* 1.090 1.400

* Die IOPS- und Durchsatzleistung nichtflüchtiger Speicher ist von der Anzahl der Instanz-vCPUs und der IO-Blockgröße abhängig. Ausführliche Informationen zu nichtflüchtigen SSD-Speichern finden Sie unter Leistungsgrenzen von nichtflüchtigem SSD-Speicher. Ausführliche Informationen zu nichtflüchtigen Standardspeichern erhalten Sie unter Leistungsgrenzen von nichtflüchtigem Standardspeicher.

** Mit nichtflüchtigen SSD- und Standardspeichern kann für Instanzen mit einer größeren Anzahl von vCPUs eine höhere Durchsatzleistung erzielt werden. Ausführliche Informationen dazu finden Sie im Abschnitt Obergrenzen für ausgehenden Netzwerktraffic bei Schreibvorgängen.

Vergleich von nichtflüchtigem Speicher mit physischen Festplatten

Wenn Sie die Größe Ihrer nichtflüchtigen Speicher angeben, bedenken Sie die Unterschiede dieser Laufwerke zu herkömmlichen physischen Festplatten. In der folgenden Tabelle werden nichtflüchtiger Standardspeicher und nichtflüchtiger SSD-Speicher mit der typischen Leistung verglichen, die Sie von einem 7200 RPM SATA-Laufwerk erwarten würden, das in der Regel 75 IOPS oder 120 MB/s erreicht.

E/A-Typ E/A-Schema Erforderliche Größe, um einem 7200 RPM SATA-Laufwerk zu entsprechen
Nichtflüchtiger Standardspeicher Nichtflüchtiger SSD-Speicher
Kleine, zufällige Lesevorgänge 75 kleine zufällige Lesevorgänge 100 GB 3 GB
Kleine, zufällige Schreibvorgänge 75 kleine zufällige Schreibvorgänge 50 GB 3 GB
Streaming, große Lesevorgänge 120 MB/s für Lesevorgänge (Streaming) 1.000 GB 250 GB
Streaming, große Schreibvorgänge 120 MB/s für Schreibvorgänge (Streaming) 1.000 GB 250 GB

Größe, Preis und Leistungsübersicht

Bei der Auswahl des Typs und der Größe eines Volumes für Ihre Anwendung sind mehrere Aspekte zu berücksichtigen. Ein Faktor, den Sie jedoch nicht beachten müssen, ist der Preis für die Verwendung des Volumes. Da bei nichtflüchtigem Speicher keine Kosten pro E/A anfallen, müssen Sie zum Berechnen des für Laufwerke erforderlichen Budgets nicht die monatlichen E/A-Kosten abschätzen. Für IOPS-orientierte Arbeitslasten ist es jedoch zu Vergleichszwecken möglich, die monatlichen Kosten aufzuschlüsseln, um den Preis pro IOPS zu ermitteln.

In den folgenden Preiskalkulationsbeispielen werden die Preise für nichtflüchtigen Speicher in den USA verwendet. In diesen Beispielen betrachten wir die relativen Kosten von nichtflüchtigem Standardspeicher im Vergleich zu nichtflüchtigem SSD-Speicher. Nichtflüchtiger Standardspeicher kostet 0,040 $ pro GB und nichtflüchtiger SSD-Speicher 0,170 $ pro GB. Wenn Sie die Größe eines Volumes erhöhen, erhöht sich auch automatisch die Leistungsgrenze – ohne zusätzliche Kosten.

Zum Ermitteln der Kosten pro IOPS bei nichtflüchtigem Speicher teilen Sie den Preis pro GB und Monat durch die Anzahl der IOPS pro GB. In der folgenden Tabelle wird der Preis pro zufälligen Lese-IOPS pro GB berechnet. Sie können mit derselben Formel auch den Preis pro Schreib-IOPS berechnen.

Laufwerkstyp Preis pro GB und Monat Lese-IOPS pro GB Preis pro IOPS pro GB
Nichtflüchtiger Standardspeicher 0,040 $ 0,75 0,040 $ / 0,75 = 0,0533 $
Nichtflüchtiger SSD-Speicher 0,170 $ 30 0,170 $ / 30 = 0,2267 $

Nichtflüchtiger SSD-Speicher erreicht seine Grenze von 60.000 zufälligen Lese-IOPS bei 2.000 GB und seine Grenze von 30.000 zufälligen Schreib-IOPS bei 1.000 GB. Im Gegensatz dazu erreicht nichtflüchtiger Standardspeicher seine Grenze von 3.000 zufälligen Lese-IOPS bei 4 TB und seine Grenze von 15.000 zufälligen Schreib-IOPS bei 10 TB.

Nichtflüchtiger SSD-Speicher ist für Latenzen im einstelligen Millisekundenbereich ausgelegt. Die beobachtete Latenz ist anwendungsspezifisch.

Nichtflüchtiger Standardspeicher

Die Leistung von nichtflüchtigem Standardspeicher erhöht sich linear bis zur Leistungsgrenze der VM. Mit vier oder mehr vCPUs für die Instanz wird die Leistung von nichtflüchtigem Standardspeicher nicht beschränkt.

Bei weniger als vier vCPUs für eine Instanz sind Schreibvorgänge für IOPS begrenzt, da die Beschränkungen für ausgehenden Netzwerktraffic proportional zur Anzahl der vCPUs sind. Das Schreiblimit hängt auch von der Größe der E/A-Vorgänge ab. E/A-Vorgänge mit 16 KB nutzen mehr Bandbreite als E/A-Vorgänge mit 8 KB auf derselben IOPS-Ebene.

Die IOPS-Werte und die Durchsatzleistung eines nichtflüchtigen Standardspeichers erhöhen sich linear zur Größe des Laufwerks bis zu den folgenden Limits pro Instanz:

  • Lesedurchsatz: bis zu 240 MB/s bei einer Laufwerkgröße von 2 TB.
  • Schreibdurchsatz: bis zu 240 MB/s bei einer Laufwerkgröße von 2 TB.
  • Lese-IOPS: bis zu 3.000 IOPS bei einer Laufwerkgröße von 4 TB.
  • Schreib-IOPS: bis zu 15.000 IOPS bei einer Laufwerkgröße von 10 TB.

Um diese Leistungsvorteile von nichtflüchtigem Speicher auf Ihren vorhandenen Instanzen zu erhalten, passen Sie die Größe des nichtflüchtigen Speichers an, um die IOPS und den Durchsatz pro nichtflüchtigem Speicher zu erhöhen.

Größe des Volumes (GB) Kontinuierliche zufällige IOPS Kontinuierlicher Durchsatz (MB/s)
Lesen
(<=16 KB/EA)
Schreiben
(<=8 KB/EA)
Schreiben
(16 KB/EA)
Lesen Schreiben
10 * * * * *
32 24 48 48 3 3
64 48 96 96 7 7
128 96 192 192 15 15
256 192 384 384 30 30
512 384 768 768 61 61
1.000 750 1.500 1.500 120 120
1.500 1.125 2.250 2.250 180 180
2.048 1.536 3.072 3.072 240 240
4.000 3.000 6.000 6.000 240 240
5.000 3.000 7.500 7.500 240 240
8.192 3.000 12.288 7.500 240 240
10.000 3.000 15.000 7.500 240 240
16.384 3.000 15.000 7.500 240 240
32.768 3.000 15.000 7.500 240 240
65.536 3.000 15.000 7.500 240 240

* Verwenden Sie diese Volume-Größe nur für Bootlaufwerke. Das E/A-Bursting bietet für Start-Volumes eine höhere Leistung als die hier beschriebene lineare Skalierung.

Nichtflüchtiger SSD-Speicher

Die IOPS-Leistung von nichtflüchtigem SSD-Speicher hängt neben der Laufwerkgröße auch von der Anzahl der vCPUs in der Instanz ab.

VMs mit weniger Kernen haben niedrigere Schreib-IOPS- und Durchsatzlimits aufgrund der Beschränkungen für den Schreibdurchsatz bei ausgehendem Netzwerktraffic. Weitere Informationen finden Sie unter Obergrenzen für ausgehenden Netzwerktraffic bei Schreibvorgängen.

Die Leistung eines nichtflüchtigen SSD-Speichers erhöht sich bis zum Volume-Limit oder bis zu den Beschränkungen der einzelnen Compute Engine-Instanz linear. Die SSD-Lesebandbreite und die IOPS-Konsistenz nahe den maximalen Limits hängen weitgehend vom eingehenden Netzwerktraffic ab. Dabei muss man von gewissen Schwankungen ausgehen, insbesondere bei E/A-Vorgängen mit 16 KB nahe den maximalen E/A-Limits.

Anzahl an Instanz-vCPUs Kontinuierliche zufällige IOPS Kontinuierlicher Durchsatz (MB/s)
Lesen
(<=16 KB/EA)
Schreiben
(<=8 KB/EA)
Schreiben
(16 KB/EA)
Lesen* Schreiben
1 vCPU 15.000 9.000 4.500 240 72
2 bis 3 vCPUs 15.000 15.000 4.500/vCPU 240 72/vCPU
4 bis 7 vCPUs 15.000 15.000 15.000 240 240
8 bis 15 vCPUs 15.000 15.000 15.000 800 400
16 bis 31 vCPUs 25.000 25.000 25.000 1.200 400
32 bis 63 vCPUs 60.000 30.000 25.000 1.200 400
64 oder mehr vCPUs** 60.000 30.000 25.000 1.200 400

* Maximaler Durchsatz auf der Grundlage von E/A-Blockgrößen von 256 KB oder höher.

** Die maximale Leistung ist möglicherweise bei voller CPU-Auslastung nicht erreichbar.

Wenn Sie die Leistung von nichtflüchtigem SSD-Speicher auf Ihren vorhandenen Instanzen verbessern möchten, ändern Sie den Maschinentyp der Instanz und erhöhen Sie die Limits pro VM. Außerdem sollten Sie die Größe des nichtflüchtigen Speichers anpassen und die IOPS-Werte und den Durchsatz pro nichtflüchtigem Speicher erhöhen.

Größe des Volumes (GB) Kontinuierliche zufällige IOPS Kontinuierlicher Durchsatz (MB/s)
Lesen
(<=16 KB/EA)
Schreiben
(<=8 KB/EA)
Schreiben
(16 KB/EA)
Lesen Schreiben
10 300 300 300 4,8 4,8
32 960 960 960 15 15
64 1.920 1.920 1.920 30 30
128 3.840 3.840 3.840 61 61
256 7.680 7.680 7.680 122 122
500 15.000 15.000 15.000 240 240
834 25.000 25.000 25.000 400 400
1.000 30.000 30.000 25.000 480 400
1.334 40.000 30.000 25.000 640 400
1.667 50.000 30.000 25.000 800 400
2.048 60.000 30.000 25.000 983 400
4.096 60.000 30.000 25.000 1.200 400
8.192 60.000 30.000 25.000 1.200 400
16.384 60.000 30.000 25.000 1.200 400
32.768 60.000 30.000 25.000 1.200 400
65.536 60.000 30.000 25.000 1.200 400

Beschränkungen für C2-Laufwerke

Für rechenoptimierte Maschinentypen gelten bestimmte Limits für nichtflüchtige Speicher pro vCPU. Diese unterscheiden sich von den Beschränkungen für andere Maschinentypen. Die Limits sind in der folgenden Tabelle aufgeführt.

Beachten Sie, dass die Leistung pro Volume auch hier so hoch wie in den Abschnitten Leistung von nichtflüchtigem Standardspeicher und Leistung von nichtflüchtigem SSD-Speicher ist.

Nichtflüchtiger Standardspeicher
Anzahl an Instanz-vCPUs Kontinuierliche zufällige IOPS Kontinuierlicher Durchsatz (MB/s)
Lesen
(<=16 KB/EA)
Schreiben
(<=8 KB/EA)
Schreiben
(16 KB/EA)
Lesen* Schreiben
4 vCPUs 3.000 4.000 4.000 240 240
8 vCPUs 3.000 4.000 4.000 240 240
16 vCPUs 3.000 4.000 4.000 240 240
30 vCPUs 3.000 8.000 8.000 240 240
60 vCPUs 3.000 15.000 15.000 240 240
Nichtflüchtiger SSD-Speicher
Anzahl an Instanz-vCPUs Kontinuierliche zufällige IOPS Kontinuierlicher Durchsatz (MB/s)
Lesen
(<=16 KB/EA)
Schreiben
(<=8 KB/EA)
Schreiben
(16 KB/EA)
Lesen* Schreiben
4 vCPUs 4.000 4.000 4.000 240 240
8 vCPUs 4.000 4.000 4.000 240 240
16 vCPUs 8.000 4.000 4.000 320 240
30 vCPUs 15.000 8.000 8.000 600 240
60 vCPUs 30.000 15.000 15.000 1.200 400

Gleichzeitige Lese- und Schreibvorgänge

Bei nichtflüchtigem Standardspeicher werden für gleichzeitige Lese- und Schreibvorgänge dieselben Ressourcen verwendet. Während die Instanz mehr Lesedurchsatz oder IOPS verwendet, kann sie weniger Schreibvorgänge ausführen. Umgekehrt können Instanzen mit einem höheren Schreibdurchsatz weniger Lesevorgänge ausführen.

Nichtflüchtiger SSD-Speicher ist in der Lage, gleichzeitig maximale Durchsatzlimits für Lese- und Schreibvorgänge zu erreichen. Dies gilt jedoch nicht für IOPS. Nichtflüchtiger SSD-Speicher kann somit seine maximalen Limits für Lese- und Schreibvorgänge nicht gleichzeitig erreichen. Wenn Sie bei gleichzeitigen Lese- und Schreibvorgängen die maximalen Durchsatzlimits erreichen möchten, optimieren Sie die E/A-Größe so, dass das Volume seine Durchsatzlimits erreichen kann, ohne dass es zu einem IOPS-Engpass kommt.

Instanz-IOPS-Limits für gleichzeitiges Lesen und Schreiben:

Die IOPS-Werte in der folgenden Tabelle basieren auf einer E/A-Größe von 8 KB. Andere E/A-Größen wie 16 KB können bei gleicher Verteilung der Lese- und Schreibvorgänge andere IOPS-Werte haben.

Nichtflüchtiger Standardspeicher Nichtflüchtiger SSD-Speicher (8 vCPUs) Persistentes SSD-Laufwerk (über 32 vCPUs)
Lesen Schreiben Lesen Schreiben Lesen Schreiben
3.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 60.000 IOPS 0 IOPS
2.250 IOPS 3.750 IOPS 11.250 IOPS 3.750 IOPS 45.000 ­IOPS 7.500 IOPS
1.500 ­IOPS 7.500 IOPS 7.500 IOPS 7.500 IOPS 30.000 IOPS 15.000 IOPS
750 IOPS 11.250 IOPS 3.750 IOPS 11.250 IOPS 15.000 IOPS 22.500 IOPS
0 IOPS 15.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 30.000 IOPS

Instanz-Durchsatzgrenzwerte für das gleichzeitige Lesen und Schreiben:

Nichtflüchtiger Standardspeicher Nichtflüchtiger SSD-Speicher (8 vCPUs) Nichtflüchtiger SSD-Speicher (über 16 vCPUs)
Lesen Schreiben Lesen Schreiben Lesen Schreiben
240 MB/s 0 MB/s 800 MB/s* 400 MB/s* 1.200 MB/s* 400 MB/s*
180 MB/s 60 MB/s
120 MB/s 120 MB/s
60 MB/s 180 MB/s
0 MB/s 240 MB/s

* Bei nichtflüchtigen SSD-Speichern sind der maximale Lesedurchsatz und der maximale Schreibdurchsatz nicht voneinander abhängig. Daher sind diese Limits konstant. Hinweis: Aufgrund fortlaufender Verbesserungen kann es sein, dass der tatsächliche Durchsatz von nichtflüchtigem SSD-Speicher höher als die veröffentlichten Limits ist.

Obergrenzen für ausgehenden Netzwerktraffic bei Schreibvorgängen

Die Schreibvorgänge im nichtflüchtigen Speicher zählen zur kumulativen Obergrenze für ausgehenden Netzwerktraffic der jeweiligen VM-Instanz.

Für die Berechnung des maximalen Schreibtraffics im nichtflüchtigen Speicher, den eine VM-Instanz ausgeben kann, subtrahieren Sie den sonstigen ausgehenden Netzwerktraffic der Instanz von ihrer Netzwerkobergrenze von 2 Gbit/s pro vCPU. Der verbleibende Durchsatz stellt den Durchsatz dar, der Ihnen für den Schreibtraffic im nichtflüchtigen Speicher zur Verfügung steht.

Nichtflüchtiger Compute Engine-Speicher bieten integrierte Redundanz. Instanzen schreiben Daten parallel dreimal in den nichtflüchtigen Speicher, um diese Redundanz zu erreichen. Zusätzlich führt jede Schreibanfrage zu einem gewissen Overhead, der Bandbreite für ausgehenden Traffic beansprucht.

Jede Instanz hat ein Schreiblimit für nichtflüchtigen Speicher, das auf der Obergrenze für den ausgehenden Netzwerktraffic der VM basiert. Wenn der nichtflüchtige Speicher hinsichtlich der Bandbreite für ausgehenden Netzwerktraffic mit dem IP-Traffic konkurriert, werden dem Traffic des nichtflüchtigen Speichers 60 % und dem IP-Traffic 40 % der Kapazität zugewiesen. In der folgenden Tabelle ist die erwartete Schreibbandbreite für nichtflüchtige Speicher mit und ohne zusätzlichen IP-Traffic aufgeführt:

Nichtflüchtiger Standardspeicher Nichtflüchtiger SSD-Speicher
Anzahl der vCPUs Schreiblimit für nichtflüchtigen Standardspeicher (MB/s) Schreibzuordnung für nichtflüchtigen Standardspeicher (MB/s) Benötigte Standard-Volume-Größe zum Erreichen des Limits (GB) Schreiblimit für nichtflüchtigen SSD-Speicher (MB/s) Schreibzuordnung für nichtflüchtigen SSD-Speicher (MB/s) Benötigte Größe für nichtflüchtigen SSD-Speicher zum Erreichen des Limits (GB)
1 72 43 600 72 43 150
2 144 86 1.200 144 86 300
4 240 173 2.000 240 173 500
8+ 240 240 2.000 400 346 834

Zum Verständnis, wie die Werte in dieser Tabelle berechnet wurden, nehmen wir als Beispiel eine vCPU und nichtflüchtigen Standardspeicher. In diesem Beispiel wird davon ausgegangen, dass der Multiplikator für die Bandbreite für jede Schreibanforderung 3,3 beträgt. Das heißt, die Daten werden dreimal ausgegeben und haben einen Overhead von 10 %. Zur Berechnung der Obergrenze für ausgehenden Traffic teilen Sie die Obergrenze für den ausgehenden Netzwerktraffic (2 Gbit/s, das entspricht 238 MB/s) durch 3,3:

Maximale Schreibbandbreite für eine vCPU = 238 / 3,3 = ~72 MB/s für den nichtflüchtigen Standardspeicher

Mithilfe des Schreibdurchsatzes pro GB des nichtflüchtigen Standardspeichers aus der obigen Leistungstabelle können Sie nun die erforderliche Speicherkapazität berechnen:

Erforderliche Speicherkapazität zum Erreichen der maximalen Schreibbandbreite für eine einzelne vCPU = 72/0,12 = ~ 600 GB

Wie bei zonalem nichtflüchtigen Speicher wird der Schreibtraffic von regionalem nichtflüchtigen Speicher für die kumulierte Obergrenze des ausgehenden Netzwerktraffics einer VM-Instanz berücksichtigt. Berechnen Sie die für regionalen nichtflüchtigen Speicher verfügbare Kapazität für ausgehenden Netzwerktraffic mit dem Faktor 6,6.

Maximale Schreibbandbreite für eine vCPU = 238 / 6,6 = ~36 MB/s für den replizierten nichtflüchtigen Standardspeicher

Leistung von nichtflüchtigen Speichern und lokalen SSDs optimieren

Sie können nichtflüchtige Speicher und lokale SSDs so optimieren, dass sie Ihre Daten effizienter verarbeiten.

Nichtflüchtigen 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.

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 2012 R2-Instanzen aktivieren DISCARD standardmäßig, wenn Sie einen nichtflüchtigen Speicher bereitstellen. Windows 2008 R2 unterstützt DISCARD nicht.

Das Aktivieren von DISCARD kann die allgemeine Laufzeitleistung steigern und außerdem die Leistung Ihres Laufwerks bei der anfänglichen Bereitstellung beschleunigen. 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 eine schnelle 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 für Instanzen mit CentOS 6-Images 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. Sie können aber auch gelegentlich fstrim zusätzlich zu oder anstelle der Option discard ausführen. Wenn Sie die Option discard nicht verwenden, führen Sie fstrim aus, bevor Sie einen Snapshot Ihres Speichers 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. Bei einem höheren Readahead erhöht sich der Durchsatz auf Kosten des Arbeitsspeichers und der IOPS. Bei einem geringeren Readahead erhöhen sich die IOPS 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 sind die <desired_readahead_bytes> (gewünschten Readahead-Bytes) dividiert durch 512 Bytes.

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 Arbeitslasten

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-Dokumenten 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ü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, werden die erzielten IOPS deutlich unter dem in der Tabelle angegebenen Limit liegen. 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 das Gerät eine andere Größe hat, passen Sie den Wert des Arguments --filesize an. 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 realisieren 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 Schreib-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.

    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=64 --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
    

Lokale SSDs optimieren

In der nach Speichertyp sortierten Leistungstabelle ist die maximal erreichbare Leistung lokaler SSD-Geräte aufgeführt. Damit Ihre Anwendungen und VM-Instanzen diese Geschwindigkeiten erreichen, verwenden Sie die folgenden Best Practices:

Gastumgebung für lokale SSD optimieren

Standardmäßig führen die meisten in Compute Engine bereitgestellten Linux-Images automatisch ein Optimierungsskript aus, das die Instanz für eine maximale Leistung der lokalen SSD konfiguriert. Das Skript aktiviert bestimmte Einstellungen für sysfs-Warteschlangendateien zur Verbesserung der Gesamtleistung der Maschine. Außerdem maskiert es Interrupt-Anfragen (Interrupt Requests, IRQs) an bestimmte virtuelle CPUs (vCPUs). Dieses Skript optimiert nur die Leistung für lokale Compute Engine-SSD-Geräte.

Ubuntu-, SLES- und andere ältere Images können möglicherweise nicht für diese Leistungsoptimierung konfiguriert werden. Wenn Sie eines dieser Images oder ein älteres Image als v20141218 verwenden, können Sie stattdessen die Gastumgebung installieren, um diese Optimierungen zu aktivieren.

Optimales Image für NVMe- oder SCSI-Schnittstellen auswählen

Lokale SSDs können entweder eine NVMe- oder eine SCSI-Schnittstelle bereitstellen. Die optimale Auswahl richtet sich nach dem verwendeten Betriebssystem. Wählen Sie eine Schnittstelle für Ihre lokalen SSD-Geräte aus, die am besten mit dem Image Ihres Bootlaufwerks arbeitet. Wenn die Instanzen über SCSI-Schnittstellen eine Verbindung zu lokalen SSDs herstellen, können Sie auf dem Gastbetriebssystem das Multi-Queue-SCSI aktivieren, um die Leistung über die SCSI-Schnittstelle zu optimieren.

Multi-Queue-SCSI auf Instanzen mit benutzerdefinierten Images und lokalen SSDs aktivieren

Einige öffentliche Images unterstützen Multi-Queue-SCSI. Wenn Sie die Multi-Queue-SCSI-Kompatibilität auf benutzerdefinierten Images, die Sie in Ihr Projekt importieren, benötigen, müssen Sie diese selbst aktivieren. Ihre importierten Linux-Images können nur Multi-Queue-SCSI verwenden, wenn die Images über eine Kernel-Version ab 3.19 verfügen.

Wenn Sie Multi-Queue-SCSI für ein benutzerdefiniertes Image aktivieren möchten, importieren Sie das Image mit aktivierter Gastbetriebssystemfunktion VIRTIO_SCSI_MULTIQUEUE. Fügen Sie dabei der GRUB-Konfiguration einen Eintrag hinzu:

CentOS

Nur für CentOS 7:

  1. Importieren Sie das benutzerdefinierte Image mit der API. Beziehen Sie dabei das Element guestOsFeatures mit dem type-Wert VIRTIO_SCSI_MULTIQUEUE ein.

  2. Erstellen Sie eine Instanz mit Ihrem benutzerdefinierten Image und hängen Sie eine oder mehrere lokale SSDs an.

  3. Stellen Sie über SSH eine Verbindung zu Ihrer Instanz her.

  4. Überprüfen Sie den Wert der Datei /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Wenn der Wert dieser Datei Y ist, ist das Multi-Queue-SCSI bereits auf Ihrem importierten Image aktiviert. Wenn der Wert der Datei N ist, fügen Sie scsi_mod.use_blk_mq=Y in den Eintrag GRUB_CMDLINE_LINUX in Ihrer GRUB-Konfigurationsdatei ein und starten dann das System neu.

    1. Öffnen Sie die GRUB-Konfigurationsdatei /etc/default/grub in einem Texteditor.

      $ sudo vi /etc/default/grub
      
    2. Fügen Sie scsi_mod.use_blk_mq=Y dem Eintrag GRUB_CMDLINE_LINUX hinzu.

      GRUB_CMDLINE_LINUX=" vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16 scsi_mod.use_blk_mq=Y"
      
    3. Speichern Sie die Konfigurationsdatei.

    4. Führen Sie den Befehl grub2-mkconfig aus, um die GRUB-Datei zu regenerieren und die Konfiguration abzuschließen.

      $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
      
    5. Starten Sie die Instanz neu.

      $ sudo reboot
      

Ubuntu

  1. Importieren Sie das benutzerdefinierte Image mit der API. Beziehen Sie dabei das Element guestOsFeatures mit dem type-Wert VIRTIO_SCSI_MULTIQUEUE ein.

  2. Erstellen Sie eine Instanz mit Ihrem benutzerdefinierten Image und verwenden Sie die SCSI-Schnittstelle, um eine oder mehrere lokale SSDs anzuhängen.

  3. Stellen Sie über SSH eine Verbindung zu Ihrer Instanz her.

  4. Überprüfen Sie den Wert der Datei /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Wenn der Wert dieser Datei Y ist, ist das Multi-Queue-SCSI bereits auf Ihrem importierten Image aktiviert. Wenn der Wert der Datei N ist, fügen Sie scsi_mod.use_blk_mq=Y in den Eintrag GRUB_CMDLINE_LINUX in Ihrer GRUB-Konfigurationsdatei ein und starten dann das System neu.

    1. Öffnen Sie die GRUB-Konfigurationsdatei sudo nano /etc/default/grub in einem Texteditor.

      $ sudo nano /etc/default/grub
      
    2. Fügen Sie scsi_mod.use_blk_mq=Y dem Eintrag GRUB_CMDLINE_LINUX hinzu.

      GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=Y"
      
    3. Speichern Sie die Konfigurationsdatei.

    4. Führen Sie den Befehl update-grub aus, um die GRUB-Datei zu regenerieren und die Konfiguration abzuschließen.

      $ sudo update-grub
      
    5. Starten Sie die Instanz neu.

      $ sudo reboot
      

Leerung des Schreibcache deaktivieren

Dateisysteme, Datenbanken und andere Anwendungen leeren den Cache, um dafür zu sorgen, dass Daten an verschiedenen Checkpoints durch einen Commit langfristig gespeichert werden. Bei den meisten Speichergeräten ist dieses Standardverhalten sinnvoll. Allerdings sind Schreibcache-Leerungen auf lokalen SSDs ziemlich langsam. Sie können die Schreibleistung einiger Anwendungen erhöhen. Deaktivieren Sie hierzu automatische Leerungsbefehle in diesen Anwendungen bzw. Leerungsoptionen auf der Dateisystemebene.

Lokale SSDs leeren im Cache gespeicherte Schreibvorgänge immer innerhalb von zwei Sekunden ungeachtet der Leerungsbefehle, die Sie für Dateisysteme und Anwendungen festgelegt haben. So können bei temporären Hardwarefehlern nur maximal zwei Sekunden an zwischengespeicherten Schreibvorgängen verloren gehen. Allerdings können dauerhafte Hardwarefehler immer noch zu einem kompletten Datenverlust auf dem Gerät führen, unabhängig davon, ob der Cache geleert wurde. Sichern Sie wichtige Daten daher trotzdem in nichtflüchtigem Speicher oder in Cloud Storage-Buckets.

Wenn Sie das Leeren des Schreib-Caches auf Dateisystemen vom Typ ext4 deaktivieren möchten, beziehen Sie die Einstellung nobarrier in die Bereitstellungsoptionen oder in Einträge in /etc/fstab ein. Beispiel:

$ sudo mount -o discard,defaults,nobarrier /dev/[LOCAL_SSD_ID] /mnt/disks/[MNT_DIR]

Dabei ist [LOCAL_SSD_ID] die Geräte-ID der lokalen SSD, die Sie bereitstellen möchten, und [MNT_DIR] das Verzeichnis für die Bereitstellung.

Benchmarking der lokalen SSD-Leistung

Die im Abschnitt zur Leistung angegebenen Leistungszahlen der lokalen SSD wurden mit spezifischen Einstellungen auf der lokalen SSD-Instanz erreicht. Wenn Ihre Instanz Schwierigkeiten hat, diese Leistungsgrenzen zu erreichen, und Sie bereits die Instanz unter Verwendung der empfohlenen Einstellungen für die lokale SSD konfiguriert haben, können Sie Ihre Leistungsgrenzen mit den veröffentlichten Grenzen vergleichen, indem Sie die Einstellungen replizieren, die das Compute Engine-Team verwendet hat.

  1. Erstellen Sie je nach Arbeitslast eine lokale SSD-Instanz mit 4 oder 8 vCPUs pro Gerät. Wenn Sie beispielsweise 4 lokale SSD-Geräte an eine Instanz anfügen möchten, verwenden Sie einen Maschinentyp mit 16 oder 32 vCPUs.

    Der folgende Befehl erstellt eine virtuelle Maschine mit 8 vCPUs und einer einzelnen lokalen SSD:

    gcloud compute instances create ssd-test-instance \
    --machine-type "n1-standard-8" \
    --local-ssd interface="SCSI"
    
  2. Führen Sie das folgende Skript auf der VM aus. Damit werden die Einstellungen repliziert, mit denen Sie die im Abschnitt zur Leistung angegebenen Leistungszahlen für die SSD erzielen. Der Parameter --bs definiert die Blockgröße. Diese wirkt sich auf die Ergebnisse der verschiedenen Arten von Lese- und Schreibvorgängen aus.

    # install dependencies
    sudo apt-get update -y
    sudo apt-get install -y build-essential git libtool gettext autoconf \
    libgconf2-dev libncurses5-dev python-dev fio bison autopoint
    
    # blkdiscard
    git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
    cd util-linux/
    ./autogen.sh
    ./configure --disable-libblkid
    make
    sudo mv blkdiscard /usr/bin/
    sudo blkdiscard /dev/disk/by-id/google-local-ssd-0
    
    # full write pass - measures write bandwidth with 1M blocksize
    sudo fio --name=writefile --size=100G --filesize=100G \
    --filename=/dev/disk/by-id/google-local-ssd-0 --bs=1M --nrfiles=1 \
    --direct=1 --sync=0 --randrepeat=0 --rw=write --refill_buffers --end_fsync=1 \
    --iodepth=200 --ioengine=libaio
    
    # rand read - measures max read IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randread --blocksize=4k --group_reporting
    
    # rand write - measures max write IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randwrite --blocksize=4k --group_reporting
    

Weitere Informationen

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

Feedback geben zu...

Compute Engine-Dokumentation