Speicherleistung – CS
Dieser Test überprüft, ob die Leistung des Speichergeräts den Leistungsanforderungen entspricht.
Testdetails
| Spezifikationen |
|
| Plattformen |
|
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 240 |
| Kategorie | Vergleichstest |
| Zeitüberschreitung (in Minuten) | 14400 |
| Neustart erforderlich | false |
| Erfordert eine spezielle Konfiguration | false |
| Typ | automatic |
Zusätzliche Dokumentation
Tests in diesem Funktionsbereich enthalten möglicherweise zusätzliche Dokumentation, einschließlich Informationen zu Voraussetzungen, Einrichtung und Fehlerbehebung, die in den folgenden Themen zu finden sind:
Ausführen des Tests
Das Speichergerät muss an den entsprechenden Controller angeschlossen werden. Der Test ist nicht destruktiv, sodass während des Tests keine Dateien oder Partitionen zerstört werden. Es werden jedoch Dateien auf das Laufwerk geschrieben. Es ist wichtig, die Anzahl Aktivitäten zu minimieren, die auf dem Laufwerk außerhalb des Logotests auftreten. Da es sich um einen Leistungstest handelt, können externe Aktivitäten die Ergebnisse beeinflussen.
Problembehandlung
Allgemeine Informationen zur Problembehandlung von HLK-Testfehlern finden Sie unter Problembehandlung von Windows HLK-Testfehlern.
Überprüfen der WTT-Ablaufverfolgung:
Wechseln Sie zu den untergeordneten Auftragsergebnissen von RunJob – Speicherleistungsbibliothek.
Zeigen Sie das Vorgangsprotokoll der StorPerf-Ausführung an.
Öffnen Sie die Protokolldatei "StorPerf.wtl".
Suchen Sie nach Nachrichten, die das Problem möglicherweise beheben können.
Fehler bei der Span-Größe:
Fehlermeldung: "Die angeforderte Span-Größer von 10737418240 Bytes ist größer als die Vorbedingungsdatei, 7195066368 Bytes. Logotest ungültig."
Wenn die angeforderte Span-Größe größer als die Vorbedingungsdatei ist, wird zwar ein Fehler protokolliert, der Test wird jedoch weiterhin ausgeführt. Die erstellte Datei "testzone.tmp" ist zu klein, um den vom Test erforderlichen Bereich ausreichend zu testen.
Es muss mehr Speicherplatz bereitgestellt werden, oder die Datei war zu klein und wurde nicht ordnungsgemäß gelöscht, bevor der Test gestartet wurde.
Derzeit beträgt die erforderliche Mindestgröße der Vorbedingungsdatei 10 Gb. Zudem muss auf dem Laufwerk 20 % freier Speicherplatz frei bleiben. In der Vorbedingungsphase wird eine Datei geschrieben, die den gesamten freien Speicherplatz ausfüllt und 20 % des Gesamtspeicherplatzes auf dem Laufwerk beibehält.
Datenträgergesamtgröße * 20 % + 10 GB < freier Speicherplatz
Überprüfen der individuellen Testergebnisse:
Durchsuchen Sie die Auftragsprotokolle der Speicherleistung CS/Speicherleistung USB3.
Es gibt mehrere Arten von Dateien für jeden Testfall, der innerhalb des Tests ausgeführt wird. Diese Dateien werden zur Selektierung zurück auf den Controller kopiert. Sie Dateien enthalten mehr Informationen als in den WTT-Protokollen verfügbar sind.
Die Ergebnisdateien (.result) sind die Konsolenausgabe jedes Prozesses, der aus diesem Test gestartet wird.
Die XML-Dateien werden von dem Workload generiert, der von diesen Tests gestartet wird. Diese Analyse erfolgt, um die Metriken abzurufen.
Die CSV-Datei ist das Aggregat aller analysierten Daten für die einzelnen Testfälle.
Die XLS-Datei ist dasselbe Aggregat wie die CSV-Datei mit demselben Namen, mit der Ausnahme, dass sie neben dem erwarteten Wert des Metrikbalkens Pass/Fail-Farbcodierungen enthält.
Die Benennung der Ergebnis (.result)- und XML-Dateien identifiziert eindeutig die Ausführung des Testfalls.
Scen = Szenario.
Die lange hexadezimale Zeichenfolge identifiziert alle Parameter, die an die Workload übergeben werden.
Die dreistellige Hexadezimalzeichenfolge ist die Thread-ID.
Die letzten entsprechen den Ausführungen dieses exakten Testfalls für denselben Workload.
Wenn ein Fehler im Protokoll auftritt, überprüfen Sie zunächst die Ergebnisdatei mit dem Namen des Testfalls, in dem der Fehler aufgetreten ist. Wenn ein Fehler im Workload auftritt, wird die Ergebnisdatei in die WTL-Protokolldatei kopiert, um den Zugriff auf den Inhalt zu erleichtern.
Wenn ein Handle nicht auf dem Datenträger geöffnet werden kann, verfügt er möglicherweise über keine Partition auf dem Laufwerk oder wird nicht als Administrator ausgeführt.
Wenn es eine Diskrepanz bezüglich der Metrik gibt, befinden sich die Werte in der XML-Datei.
Wenn es eine Diskrepanz hinsichtlich der Varianz- oder Testfallinteraktionen gibt, werden in den CSV/XLS-Dateien die Ergebnisse für alle Tests angezeigt.
Probleme mit geöffneten ETW-Protokollen:
Wenn der Test während der Ausführung geschlossen wird, ist es möglich, dass ein ETW-Protokoll aktiv bleibt.
Die einfachste Möglichkeit zum Zurücksetzen besteht darin, den Computer neu zu starten.
Der Logger kann auch manuell geschlossen werden:
Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten.
Ausführen: logman query -ets
Ausführen: logman stop -ets "Circular BitLocker Logger"
Weitere Informationen zur Problembehandlung finden Sie unter Problembehandlung bei Device.Storage-Tests.
Weitere Informationen
Der Auftrag übernimmt die Geräteinstanz-ID des getesteten Geräts und konvertiert die Geräteinstanz-ID je nach Szenario in eine physische Laufwerksnummer oder einen Laufwerkbuchstaben. Sofern laut Szenario erforderlich, partitioniert und formatiert der Auftrag das Laufwerk, um es so zu konfigurieren, wie für den Test erforderlich. Der Test führt eine Reihe von Testfällen durch, die den Elementen in den Anforderungen zugeordnet sind. Die Testfälle sind eigenständig und werden sequenziell ausgeführt. Eine Liste der Testfälle kann mithilfe der Befehlszeilenoption "PrintPolicy" mit dem angegebenen Gerät abgerufen werden. Jeder dieser Testfälle kann mithilfe des Tests im eigenständigen Modus mit einer benutzerdefinierten XML-Richtliniendatei ausgeführt werden. Dabei wird die PolicyXML-Befehlszeilenoption für weitere Test- oder Debugging-Vorgänge verwendet.
Der Speicherleistungstest speichert eine Richtlinientabelle, die für jeden Gerätetyp definiert, welche Leistungstests ausgeführt werden sollen und wie die entsprechenden Metriken lauten sollen. Sobald die entsprechenden Elemente in der Tabelle ausgewählt wurden, erzeugt der Test sequenziell Instanzen des angegebenen Workloads, in diesem Fall StorageAssessment, um die in der Tabelle für dieses Gerät angegebenen Elemente zu testen. Nachdem StorageAssessment seine Tests abgeschlossen und die Ergebnisse erstellt hat, analysiert der Speicherleistungstest diese Werte und vergleicht sie mit den Balken, die in den Logoanforderungen definiert sind, um Pass-/Fail-Protokolle zu auzugeben.
Das zu testende Szenario wird vom DeviceTag-Flag in der Befehlszeile referenziert. Dieses Flag ist ein TestcaseGroup-Element in der Richtlinien-XML-Datei. Der Test verfügt über einige integrierte Szenarien, ermöglicht jedoch auf Wunsch auch benutzerdefinierte Szenarien.
Ein Szenario wird durch einen Auftrag, Workload, Zugriff, Vorgang, Vorgangswert, eine EA-Größe, Span-Größe, Laufzeit, Warteschlangentiefe sowie durch Prozent- und MB-Werte für die Vorbedingung definiert. Jedes in der Tabelle definierte Szenario entspricht dem Workload, der einmal erzeugt wird. Wenn einem einzelnen Gerät mehrere identische Szenarien definiert sind, rufen sie dennoch nur einen Testfall auf.
Eine Metrik wird durch ihren Typ und Wert definiert. Die Metrik ist systemintern und gibt an, ob der Balken ein oberer oder unterer Grenzwert ist. Für die einzelnen Szenarien können viele Metriken angegeben werden, das dazu führt, dass nur ein Testfall für ein bestimmtes Szenario aufgerufen wird.
Für jeden Eintrag in der Tabelle gibt es Varianzkriterium, das die maximale Varianz definiert, die für den letzten Ausführungssatz zulässig ist, bevor der Testfall beendet wird. Für viele der Einträge ist es mit mindestens 5 Ausführungen und maximal 30 Ausführungen definiert, und die Varianz über die letzten 5 Ausführungen muss unter 10 % betragen, damit der Test fortgesetzt wird. Der Testfall wird bis zu 30 Mal oder bis zur Erfüllung der Varianzanforderung erneut ausgeführt. An diesem Punkt wird die Metrik anhand der definierten Eigenschaften der Metrik (Minimum, Maximum, Mittelwert, Durchschnitt usw.) über die letzten Ausführungssätze ausgewertet.
Obwohl der Test der Speicherleistung nicht auf einen Workload beschränkt ist, verwenden die meisten in der Richtlinientabelle definierten Szenarien den StorageAssessment-Workload, um die Metriken und den Workload bezüglich der Leistung zu generieren.
Befehlssyntax
| Befehl | Beschreibung |
|---|---|
StorPerf.exe /DriveLetter [StorageDriveLetter] /DeviceTag CS_Boot |
Führt die CS-Tests auf dem angegebenen Laufwerk aus. DeviceTag kann auch CS_Boot_HS200 für HS200-fähige Laufwerke sein. |
Befehlssyntax
| Befehlsoption | Beschreibung |
|---|---|
/DriveNumber <Nummer> |
Nummer des physischen Laufwerks des getesteten Geräts. Beispiel: /DriveNumber 0 |
/DriveLetter <Buchstabe> |
Laufwerkbuchstabe des getesteten Geräts. Beispiel: /DriveLetter C |
/DeviceTag <Wert> |
Gibt an, welche Testfallgruppe (TestcaseGroup) oder Vergleichsgruppe (ComparisonGroup) als Eingabe aus den XML-Konfigurationsdateien ausgewählt werden soll. Bei diesem Parameter wird zwischen Groß- und Kleinschreibung unterschieden, und er wird zum Indizieren der XML-Richtliniendatei und der XML-Vergleichsdatei verwendet. Beispiel: /DeviceTag CS_Boot |
/PolicyXML <Wert> |
Der Name der XML-Richtliniendatei. Definiert alle Parameter für die Ausführung derE/A-Workloads. Ist keine Option angegeben, wird die Standarddatei generiert. Beispiel: /PolicyXML CSPolicy.xml |
/Compare <Wert><Wert> |
Die beiden zu vergleichenden XML-Dateien. Diese müssen in einer vorherigen Ausführung dieses Tests generiert worden sein. Verwenden Sie anstelle der Dateien vom Typ „AllTestCasesAggregated*.xml“ die Dateien vom Typ „FinalTestCasesAggregated*.xml“, da nicht garantiert werden kann, dass die Iterationsanzahl für jeden Testfall identisch ist. Beispiel: /Compare FinalTestCasesAggregated_42f4.xml FinalTestCasesAggregated_a732.xml |
/CompareXML <Wert> |
Der Name der XML-Vergleichsdatei. Definiert alle Parameter für den Vergleich. Ist keine Option angegeben, wird die Standarddatei generiert. Beispiel: /CompareXML CSCompare.xml |
/PrintPolicy |
Gibt die Richtlinientabelle aus. |
Hinweis
Geben Sie /h ein, um die Befehlszeilenhilfe für diese Testbinärdatei anzuzeigen.
Dateiliste
| Datei | Standort |
|---|---|
StorPerf.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\ |
StorageAssessment.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
ssdtest.dat |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
Parameter
| Parametername | Parameterbeschreibung |
|---|---|
| LLU_NetAccessOnly | Benutzerkonto für den Zugriff auf die Testdateifreigabe. |
| LLU_LclAdminUsr | Benutzerkonto zum Ausführen des Tests. |
| WDKDeviceID | Instanzpfad des zu testenden Geräts. |
| DeviceID | Entweder DriveLetter oder DriveNumber |
| DeviceTag | |
| DiskDeviceObjLink | Zugewiesen durch Parameter bei der Speichererstellung. |
| Destructive | (0,1) 0=Passiv, 1=Destruktiv |
| QueryHS200 | Fragt ab, ob ein Gerät den HS200-Modus unterstützt |