Verwenden von DISKSPD zum Testen einer Workloadspeicherleistung

Gilt für: Azure Stack HCI, Versionen 22H2 und 21H2; Windows Server 2022, Windows Server 2019

Von Bedeutung

Azure Stack HCI ist jetzt Teil von Azure Local. Ältere Versionen von Azure Stack HCI, z. B. 22H2, verweisen jedoch weiterhin auf Azure Stack HCI und spiegeln die Namensänderung nicht wider. Erfahren Sie mehr.

Dieses Thema enthält Anleitungen zur Verwendung von DISKSPD zum Testen der Workloadspeicherleistung. Sie haben einen Azure Stack HCI-Cluster eingerichtet, der einsatzbereit ist. Super, aber woher wissen Sie, ob Sie die versprochenen Leistungsmetriken erreichen, etwa bei Wartezeit, Durchsatz oder IOPS? Dies ist der Punkt, an dem Sie das Tool DISKSPD verwenden möchten. Nach dem Lesen dieses Themas wissen Sie, wie Sie DISKSPD ausführen, eine Teilmenge von Parametern verstehen, die Ausgabe interpretieren und ein allgemeines Verständnis der Variablen erhalten, die sich auf die Arbeitsauslastungsspeicherleistung auswirken.

Was ist DISKSPD?

DISKSPD ist ein E/A-Generierungstool, Befehlszeilentool für Mikro-Benchmarking. Großartig, also was bedeuten all diese Begriffe? Jeder, der einen Azure Stack HCI-Cluster oder physischen Server einrichte, hat einen Grund. Es könnte darum gehen, eine Webhosting-Umgebung einzurichten oder virtuelle Desktops für Mitarbeiter bereitzustellen. Ganz gleich, was der praktische Anwendungsfall sein kann, Sie möchten wahrscheinlich einen Test simulieren, bevor Sie Ihre eigentliche Anwendung bereitstellen. Das Testen Ihrer Anwendung unter realen Bedingungen ist jedoch häufig schwierig – hier kommt DISKSPD ins Spiel.

DISKSPD ist ein Tool, das Sie anpassen können, um ihre eigenen synthetischen Workloads zu erstellen und Ihre Anwendung vor der Bereitstellung zu testen. Das coole Element des Tools besteht darin, dass es Ihnen die Freiheit gibt, die Parameter zu konfigurieren und zu optimieren, um ein bestimmtes Szenario zu erstellen, das Ihrer echten Arbeitsauslastung ähnelt. DISKSPD kann Ihnen einen Einblick in die Möglichkeiten Ihres Systems vor der Bereitstellung geben. Im Wesentlichen führt DISKSPD einfach zahlreiche Lese- und Schreibvorgänge aus.

Jetzt wissen Sie, was DISKSPD ist, aber wann sollten Sie es verwenden? DISKSPD hat eine schwierige Zeit beim Emulieren komplexer Workloads. DISKSPD ist jedoch hervorragend geeignet, wenn sich Ihre Arbeitslast nicht gut durch einen Dateikopiervorgang mit nur einem Thread annähern lässt und Sie ein einfaches Tool benötigen, das brauchbare Basiswerte liefert.

Schnellstart: Installieren und Ausführen von DISKSPD

Um DISKSPD zu installieren und auszuführen, öffnen Sie PowerShell als Administrator auf Ihrem Verwaltungs-PC, und führen Sie dann die folgenden Schritte aus:

Führen Sie die folgenden Befehle aus, um die ZIP-Datei für das DISKSPD-Tool herunterzuladen und zu erweitern:

# Define the ZIP URL and the full path to save the file, including the filename
$zipName = "DiskSpd.zip"
$zipPath = "C:\DISKSPD"
$zipFullName = Join-Path $zipPath $zipName
$zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName

# Ensure the target directory exists, if not then create
if (-Not (Test-Path $zipPath)) {
New-Item -Path $zipPath -ItemType Directory | Out-Null
}
# Download and expand the ZIP file
Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName
Expand-Archive -Path $zipFullName -DestinationPath $zipPath

Führen Sie den folgenden Befehl aus, um das DISKSPD-Verzeichnis zu Ihrer Umgebungsvariable $PATH hinzuzufügen:

$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

Führen Sie DISKSPD mit dem folgenden PowerShell-Befehl aus. Ersetzen Sie eckige Klammern durch Ihre entsprechenden Einstellungen.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Hier ist ein Beispielbefehl, den Sie ausführen können:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Note

Wenn Sie nicht über eine Testdatei verfügen, verwenden Sie den Parameter "-c ", um eine datei zu erstellen. Wenn Sie diesen Parameter verwenden, achten Sie darauf, den Namen der Testdatei einzuschließen, wenn Sie den Pfad definieren. Beispiel: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. Im Beispielbefehl ist IO.dat der Name der Testdatei, und test01.txt ist der NAME der DISKSPD-Ausgabedatei.

Angeben von Schlüsselparametern

Nun, das war einfach? Leider steckt mehr dahinter. Lassen Sie uns das entpacken, was wir getan haben. Zunächst gibt es verschiedene Parameter, mit denen Sie tüfteln können, und es kann spezifisch werden. Wir haben jedoch den folgenden Satz von Basisplanparametern verwendet:

Note

DISKSPD-Parameter beachten die Groß-/Kleinschreibung.

-t2: Dies gibt die Anzahl der Threads pro Ziel-/Testdatei an. Diese Zahl basiert häufig auf der Anzahl der CPU-Kerne. In diesem Fall wurden zwei Threads verwendet, um alle CPU-Kerne auszulasten.

-o32: Dies gibt die Anzahl der ausstehenden E/A-Anforderungen pro Ziel pro Thread an. Dies wird auch als Warteschlangentiefe bezeichnet, und in diesem Fall wurden 32 verwendet, um die CPU zu belasten.

-b4K: Dies gibt die Blockgröße in Bytes, KiB, MiB oder GiB an. In diesem Fall wurde die 4K-Blockgröße verwendet, um einen zufälligen E/A-Test zu simulieren.

-r4K: Dies gibt den zufälligen E/A-Vorgang an, der an der angegebenen Größe in Byte, KiB, MiB, Gib oder Blöcken ausgerichtet wird (überschreibt den -s-Parameter). Die allgemeine 4K-Bytegröße wurde verwendet, um die Blockgröße ordnungsgemäß auszurichten.

-w0: Dies gibt den Prozentsatz der Vorgänge an, die Schreibanforderungen sind (-w0 entspricht 100% Lesezugriff). In diesem Fall wurden 0% Schreibvorgänge für einen einfachen Test verwendet.

-d120: Dies gibt die Dauer des Tests an, nicht einschließlich Abkühlen oder Aufwärmen. Der Standardwert ist 10 Sekunden, es wird jedoch empfohlen, mindestens 60 Sekunden für eine schwerwiegende Workload zu verwenden. In diesem Fall wurden 120 Sekunden verwendet, um alle Ausreißer zu minimieren.

-Suw: Deaktiviert den Software- und Hardware-Schreibcache (entspricht -Sh).

-D: Erfasst IOPS-Statistiken, z. B. die Standardabweichung, in Intervallen von Millisekunden (pro Thread, pro Ziel).

-L: Misst Latenzstatistiken.

-c5g: Legt die im Test verwendete Beispieldateigröße fest. Die Größe kann in Bytes, KiB, MiB, GiB oder Blöcken festgelegt werden. In diesem Fall wurde eine Zieldatei mit 5 GB verwendet.

Eine vollständige Liste der Parameter finden Sie im GitHub Repository.

Die Umgebung verstehen

Die Leistung hängt stark von Ihrer Umgebung ab. Was ist also unsere Umwelt? Unsere Spezifikation umfasst einen Azure Stack HCI-Cluster mit Speicherpool und Direkte Speicherplätze (S2D). Genauer gesagt gibt es fünf VMs: DC, Knoten1, Knoten2, Knoten3 und den Verwaltungsknoten. Der Cluster selbst ist ein Drei-Knoten-Cluster mit einer dreiseitigen gespiegelten Resilienzstruktur. Daher werden drei Datenkopien verwaltet. Jeder "Knoten" im Cluster ist eine Standard_B2ms VM mit einem maximalen IOPS-Grenzwert von 1920. Innerhalb jedes Knotens gibt es vier Premium-P30-SSD-Laufwerke mit einem maximalen IOPS-Grenzwert von 5000. Schließlich verfügt jedes SSD-Laufwerk über 1 TB Arbeitsspeicher.

Sie generieren die Testdatei unter dem einheitlichen Namespace, den das freigegebene Clustervolume (CSV) bereitstellt (C:\ClusteredStorage), um den gesamten Pool von Laufwerken zu verwenden.

Note

Die Beispielumgebung verfügt nicht über Hyper-V oder eine geschachtelte Virtualisierungsstruktur.

Wie Sie sehen, ist es völlig möglich, entweder die IOPS- oder Bandbreitengrenze auf dem virtuellen Computer oder laufwerkslimit unabhängig zu erreichen. Daher ist es wichtig, die Größe und den Laufwerkstyp Ihres virtuellen Computers zu verstehen, da beide einen maximalen IOPS-Grenzwert und eine Bandbreitengrenze aufweisen. Dieses Wissen hilft dabei, Engpässe zu finden und Ihre Leistungsergebnisse zu verstehen. Weitere Informationen dazu, welche Größe für Ihre Workload geeignet sein kann, finden Sie in den folgenden Ressourcen:

Die Ausgabe verstehen

Mit Ihrem Verständnis der Parameter und der Umgebung sind Sie bereit, die Ausgabe zu interpretieren. Zunächst war das Ziel des früheren Tests, die IOPS ohne Berücksichtigung der Latenz zu maxieren. Auf diese Weise können Sie visuell sehen, ob Sie den künstlichen IOPS-Grenzwert innerhalb Azure erreichen. Wenn Sie die Gesamt-IOPS grafisch visualisieren möchten, verwenden Sie entweder Windows Admin Center oder Task-Manager.

Das folgende Diagramm zeigt, wie der DISKSPD-Prozess in unserer Beispielumgebung aussieht. Es zeigt ein Beispiel für einen 1 MiB-Schreibvorgang von einem Nicht-Koordinator-Knoten. Die dreifache Resilienzstruktur führt zusammen mit dem Betrieb über einen Nicht-Koordinator-Knoten zu zwei Netzwerksprüngen, was die Leistung mindert. Wenn Sie sich fragen, was ein Koordinatorknoten ist, machen Sie sich keine Sorgen! Im Abschnitt " Dinge zu berücksichtigen " erfahren Sie mehr darüber. Die roten Quadrate stellen den virtuellen Computer und Laufwerksengpässe dar.

Nachdem Sie nun ein visuelles Verständnis haben, untersuchen wir die vier Hauptabschnitte der .txt Dateiausgabe:

Eingabeeinstellungen

In diesem Abschnitt werden der Befehl beschrieben, den Sie ausgeführt haben, die Eingabeparameter und zusätzliche Details zur Testausführung.
Details zur CPU-Auslastung

In diesem Abschnitt werden Informationen wie die Testzeit, die Anzahl der Threads, die Anzahl der verfügbaren Prozessoren und die durchschnittliche Auslastung jedes CPU-Kerns während des Tests erläutert. In diesem Fall gibt es zwei CPU-Kerne, deren Auslastung im Durchschnitt bei etwa 4,67 % lag.
Gesamte E/A

Dieser Abschnitt enthält drei Unterabschnitte. Im ersten Abschnitt werden die allgemeinen Leistungsdaten hervorgehoben, einschließlich Lese- und Schreibvorgängen. Die zweiten und dritten Abschnitte teilen die Lese- und Schreibvorgänge in separate Kategorien auf.

In diesem Beispiel können Sie sehen, dass die Gesamtzahl der E/A-Vorgänge während des 120-sekündigen Zeitraums 234408 betrug. IOPS = 234408 /120 = 1953,30. Die durchschnittliche Latenz betrug 32,763 Millisekunden, und der Durchsatz betrug 7,63 MiB/s. Aus früheren Informationen wissen wir, dass die IOPS 1953.30 in der Nähe der IOPS-Beschränkung von 1920 für unsere Standard_B2ms VM liegen. Glauben Sie es nicht? Wenn Sie diesen Test mit verschiedenen Parametern erneut ausführen, z. B. das Erhöhen der Warteschlangentiefe, stellen Sie fest, dass die Ergebnisse immer noch mit dieser Zahl begrenzt sind.

Die letzten drei Spalten zeigen die Standardabweichung von IOPS bei 17,72 (von -D Parameter), die Standardabweichung der Latenz bei 20,994 Millisekunden (von -L Parameter) und den Dateipfad.

Aus den Ergebnissen können Sie schnell feststellen, dass die Clusterkonfiguration schrecklich ist. Sie können sehen, dass sie die VM-Beschränkung von 1920 vor der SSD-Beschränkung von 5000 erreicht hat. Wenn Sie auf die SSD und nicht auf die VM beschränkt waren, könnten Sie bis zu 20000 IOPS (4 Laufwerke * 5000) nutzen, indem Sie die Testdatei über mehrere Laufwerke erstrecken.

Am Ende müssen Sie entscheiden, welche Werte für Ihre spezifische Arbeitsauslastung akzeptabel sind. Die folgende Abbildung zeigt einige wichtige Beziehungen, mit denen Sie die Kompromisse berücksichtigen können:

Die zweite Beziehung in der Abbildung ist wichtig, und sie wird manchmal als Little’s Law bezeichnet. Das Gesetz führt die Idee ein, dass es drei Merkmale gibt, die das Prozessverhalten steuern und dass Sie nur einen ändern müssen, um die beiden anderen und damit den gesamten Prozess zu beeinflussen. Und wenn Sie mit der Leistung Ihres Systems unzufrieden sind, haben Sie drei Dimensionen der Freiheit, sie zu beeinflussen. Little's Law besagt, dass in unserem Beispiel IOPS der „Durchsatz“ (Eingabe-/Ausgabevorgänge pro Sekunde) ist, die Latenz die „Wartezeit in der Warteschlange“ ist und die Warteschlangentiefe der „Bestand“ ist.
Analyse von Latenzperzentilen

In diesem letzten Abschnitt werden die Perzentil-Latenzen der Speicherleistung nach Vorgangstyp vom minimalen bis zum maximalen Wert detailliert beschrieben.

Dieser Abschnitt ist wichtig, da er die "Qualität" Ihrer IOPS bestimmt. Es zeigt, wie viele der E/A-Vorgänge einen bestimmten Latenzwert erzielen konnten. Sie entscheiden, welche Latenz für dieses Perzentil akzeptabel ist.

Darüber hinaus beziehen sich die "neun" auf die Anzahl der Neuner. Beispielsweise entspricht „drei Neunen“ dem 99. Perzentil. Die Anzahl der Neunen zeigt, wie viele E/A-Vorgänge bei diesem Perzentil ausgeführt wurden. Schließlich erreichen Sie einen Punkt, an dem es nicht mehr sinnvoll ist, die Latenzwerte ernst zu nehmen. In diesem Fall können Sie sehen, dass die Latenzwerte nach "4-neuns" konstant bleiben. Zu diesem Zeitpunkt basiert der Latenzwert nur auf einem E/A-Vorgang aus den 234408-Vorgängen.

Zu berücksichtigende Dinge

Nachdem Sie nun mit DISKSPD begonnen haben, gibt es mehrere Dinge, die Sie berücksichtigen sollten, um echte Testergebnisse zu erhalten. Dazu gehört, genau auf die von Ihnen festgelegten Parameter, den Zustand des Speicherplatzes und die Variablen, die CSV-Besitzverhältnisse sowie den Unterschied zwischen DISKSPD und dem Kopieren von Dateien zu achten.

DISKSPD im Vergleich zur realen Welt

Der künstliche Test von DISKSPD liefert Ihnen relativ vergleichbare Ergebnisse für Ihre echte Arbeitsauslastung. Sie müssen jedoch genau auf die parameter achten, die Sie festlegen und ob sie mit Ihrem tatsächlichen Szenario übereinstimmen. Es ist wichtig zu verstehen, dass synthetische Arbeitslasten während der Bereitstellung niemals perfekt die echte Arbeitsauslastung Ihrer Anwendung darstellen.

Vorbereitung

Vor dem Ausführen eines DISKSPD-Tests gibt es einige empfohlene Aktionen. Dazu gehören die Überprüfung der Integrität des Speicherplatzes, die Überprüfung der Ressourcennutzung, sodass ein anderes Programm den Test nicht beeinträchtigt, und das Vorbereiten des Performance-Managers, wenn Sie zusätzliche Daten sammeln möchten. Da das Ziel dieses Abschnitts jedoch darin besteht, DISKSPD schnell zum Laufen zu bringen, wird nicht näher auf die Details dieser Schritte eingegangen. Weitere Informationen finden Sie unter Testen der Leistung von Speicherplätzen mithilfe synthetischer Workloads in Windows Server.

Variablen, die sich auf die Leistung auswirken

Die Speicherleistung ist eine heikle Sache. Das heißt, es gibt viele Variablen, die sich auf die Leistung auswirken können. Und so ist es wahrscheinlich, dass Sie eine Zahl feststellen können, die mit Ihren Erwartungen inkonsistent ist. Im Folgenden werden einige der Variablen hervorgehoben, die sich auf die Leistung auswirken, obwohl es keine umfassende Liste ist:

Netzwerkbandbreite
Resilienzauswahl
Konfiguration des Speicherdatenträgers: NVME, SSD, HDD
E/A-Puffer
Cache
RAID-Konfiguration
Netzwerksprünge
Festplatten-Spindelgeschwindigkeiten

CSV-Besitz

Ein Knoten wird als Besitzer eines Volumes oder als Koordinator-Knoten bezeichnet (ein Nicht-Koordinator ist ein Knoten, dem kein bestimmtes Volume gehört). Jedem Standardvolume wird ein Knoten zugewiesen, und die anderen Knoten können über Netzwerkhüpfen auf dieses Standardvolume zugreifen, was zu einer langsameren Leistung (höhere Latenz) führt.

Ebenso hat ein Cluster Shared Volume (CSV) ebenfalls einen „Besitzer“. Eine CSV ist jedoch insofern „dynamisch“, als sie bei jedem Neustart des Systems (RDP) zwischen Knoten wechselt und den Besitzer wechselt. Daher ist es wichtig zu bestätigen, dass DISKSPD vom Koordinatorknoten ausgeführt wird, der die CSV besitzt. Falls nicht, müssen Sie den CSV-Besitz möglicherweise manuell ändern.

So bestätigen Sie den CSV-Besitz:

Überprüfen Sie den Besitz, indem Sie den folgenden PowerShell-Befehl ausführen:
```
 Get-ClusterSharedVolume
```
Wenn der CSV-Besitz falsch ist (Beispielsweise befinden Sie sich auf Node1, Aber Node2 besitzt die CSV), verschieben Sie die CSV-Datei auf den richtigen Knoten, indem Sie den folgenden PowerShell-Befehl ausführen:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Dateikopie vs. DISKSPD

Einige Leute glauben, dass sie die Speicherleistung testen können, indem sie eine riesige Datei kopieren und einfügen und messen, wie lange dieser Prozess dauert. Der Hauptgrund für diesen Ansatz ist höchstwahrscheinlich, weil es einfach und schnell ist. Die Idee ist in dem Sinne nicht falsch, dass sie eine bestimmte Workload testet, aber es ist schwierig, diese Methode als "Testspeicherleistung" zu kategorisieren.

Wenn Ihr reales Ziel darin besteht, die Leistung von Dateikopien zu testen, kann dies ein absolut gültiger Grund für die Verwendung dieser Methode sein. Wenn Sie jedoch das Ziel haben, die Speicherleistung zu messen, empfehlen wir, diese Methode nicht zu verwenden. Sie können sich den Dateikopieprozess wie die Verwendung einer anderen Gruppe von "Parametern" (z. B. Warteschlange, Parallelisierung usw.) vorstellen, die für Dateidienste spezifisch ist.

In der folgenden kurzen Zusammenfassung wird erläutert, warum die Verwendung der Dateikopie zur Messung der Speicherleistung möglicherweise nicht die ergebnisse liefert, nach denen Sie suchen:

Dateikopien sind möglicherweise nicht optimiert, Es gibt zwei Ebenen der Parallelität, die auftreten, eine interne und die andere extern. Intern wendet die CopyFileEx-Engine, wenn die Dateikopie für ein Remoteziel bestimmt ist, ein gewisses Maß an Parallelisierung an. Extern gibt es verschiedene Methoden zum Aufrufen des CopyFileEx-Moduls. Beispielsweise sind Kopien aus dem Datei-Explorer single threaded, aber Robocopy ist multithreaded. Aus diesen Gründen ist es wichtig zu verstehen, ob die Auswirkungen des Tests das sind, wonach Sie suchen.
Jede Kopie hat zwei Seiten. Wenn Sie eine Datei kopieren und einfügen, verwenden Sie möglicherweise zwei Datenträger: den Quelldatenträger und den Zieldatenträger. Wenn eine langsamer als die andere ist, messen Sie im Wesentlichen die Leistung des langsameren Datenträgers. Es gibt andere Fälle, in denen sich die Kommunikation zwischen Quelle, Ziel und Kopiermodul auf einzigartige Weise auf die Leistung auswirken kann.

Weitere Informationen finden Sie unter Verwenden der Dateikopie zum Messen der Speicherleistung.

Experimente und allgemeine Arbeitslasten

Dieser Abschnitt enthält einige weitere Beispiele, Experimente und Arbeitsauslastungstypen.

Den Koordinatorknoten bestätigen

Wie bereits erwähnt, werden Sie, wenn die VM, die Sie derzeit testen, nicht Eigentümer der CSV ist, einen Leistungsabfall (IOPS, Durchsatz und Latenz) feststellen – im Vergleich zu einem Test, bei dem der Knoten Eigentümer der CSV ist. Dies liegt daran, dass das System bei jeder Ausgabe eines E/A-Vorgangs einen Netzwerksprung an den Koordinatorknoten durchführt, um diesen Vorgang auszuführen.

Bei einer dreiknotigen, dreifach gespiegelten Konfiguration erfordern Schreibvorgänge immer einen Netzwerksprung, da die Daten auf allen Laufwerken verteilt auf die drei Knoten gespeichert werden müssen. Daher erfordern Schreibvorgänge in jedem Fall einen Sprung über das Netzwerk. Wenn Sie jedoch eine andere Resilienzstruktur verwenden, kann sich dies ändern.

Im Folgenden finden Sie ein Beispiel:

Wird auf dem lokalen Knoten ausgeführt: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Wird auf einem nichtlocalen Knoten ausgeführt: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

In diesem Beispiel können Sie in den Ergebnissen der folgenden Abbildung deutlich sehen, dass die Latenz verringert, IOPS erhöht und der Durchsatz erhöht wurde, wenn der Koordinatorknoten die CSV besitzt.

OLTP-Workload (Online Transaction Processing)

Online Transactional Processing (OLTP)-Workloadabfragen (Update, Insert, Delete) konzentrieren sich auf transaktionsorientierte Aufgaben. Im Vergleich zu OLAP (Online Analytical Processing) ist OLTP speicherlatenzabhängig. Da jede Operation nur wenig E/A verursacht, ist entscheidend, wie viele Operationen pro Sekunde dauerhaft bewältigt werden können.

Sie können einen OLTP-Workloadtest entwerfen, um sich auf zufällige, kleine E/A-Leistung zu konzentrieren. Konzentrieren Sie sich bei diesen Tests darauf, wie weit Sie den Durchsatz pushen können, während akzeptable Latenzen beibehalten werden.

Die grundlegende Designauswahl für diesen Workloadtest sollte mindestens folgendes umfassen:

8 KB Blockgröße => ähnelt der Seitengröße, die SQL Server für die zugehörigen Datendateien verwendet.
70% Lesen, 30% Write => ähnelt dem typischen OLTP-Verhalten.

OLAP-Arbeitsauslastung (Online Analytical Processing)

OLAP-Workloads konzentrieren sich auf das Abrufen und Analysieren von Daten, sodass Benutzer komplexe Abfragen ausführen können, um mehrdimensionale Daten zu extrahieren. Im Gegensatz zu OLTP sind diese Workloads nicht empfindlich gegenüber Speicherlatenz. Sie betonen, viele Operationen in eine Warteschlange einzureihen, ohne sich groß um die Bandbreite zu kümmern. Daher führen OLAP-Workloads häufig zu längeren Verarbeitungszeiten.

Sie können einen OLAP-Workloadtest entwerfen, um sich auf sequenzielle, große E/A-Leistung zu konzentrieren. Konzentrieren Sie sich bei diesen Tests nicht auf die Anzahl der pro Sekunde verarbeiteten Daten, sondern auf die Anzahl der IOPS. Latenzanforderungen sind auch weniger wichtig, aber dies ist subjektiv.