Problem mit Einbrüchen der SSD-Übertragungsrate

[snipor]

Hallo Leute,

ich habe hier ein System mit ESXi aufgesetzt, leider habe ich da ein paar Probleme.

System:
Supermicro X10SDV-TLN4F Xeon-D 1541 8Core/16Thread
2x Samsung DIMM 32GB, DDR4-2400, CL17-17-17, reg ECC M393A4K40BB1
Dell Perc H310 geflasht mit LSI IT Firmware Version 20.00.07.00 zeigt jetzt LSI 9211-8i an, in ESXi und unter Windows wird es aber als DELL SAS 6GB erkannt
1xSamsung 840, 250GB an SATA Port des Boards
2xSeagate Nytro XF1230 1920GB am H310

Installiert ist ESXi 6.5.0 Update 1 (Build 7388607) auf der Samsung SSD.

Ich habe drei Datastores (VMFS6):
-Store1: Einmal der von ESXi nicht benötigte Speicher auf der Samsung SSD, darauf liegt auch die einzige VM Windows Server 2016.
-Store2 und Store3: jeweils der Speicher der Seagate SSDs

Die VM (4C/8GB) hat eine 100 GB OS Partion auf Store 1 und je eine 1TB Partition auf Store2 und Store3.

Kopiere ich jetzt eine Datei von Store2 nach Store3 bzw. von Store3 nach Store2 habe ich eine total niedrige Übertragungsrate mit starken Einbrüchen.

Habe dann folgendes versucht:

-Passthrough des H310

-RDM
keine Besserung

-mehr RAM an die VM
keine Besserung

Habe dann weiter herumprobiert mit den Einstellungen, wenn ich die Platten als RDM einbinde und den den VMware Paravirtual statt LSI Logic SAS verwende ist es etwas besser.

Danach habe ich mal meinen LSI 9361-8i eingebaut. SSDs als JBod und ebenfalls RDM und Paravirtual:

Der Einbruch ist auch hier vorhanden. Der Einbruch finden übrigens nicht immer statt und wenn er auftritt nicht immer nach der gleichen übertragenen Datenmenge.
Kann da also keinen direkten Zusammenhang zwischen Arbeitsspeicher und Einbruch erkennen.

Hat jemand noch eine Idee an was es liegen könnte?

Vielen Dank im Voraus

[UrsDerBär]

Tach,

Wie sieht Deine CPU-Belastung innerhalb der VM's aus? 2.1GHZ Sollte zwar nicht wirklich auf 140MB einbremsen aber dennoch ist Deine CPU nicht die schnellste.

Die Nitro's haben zudem 17'000 x 4kb Write IOPS, das heisst max. 68MB Übertragungsrate. Insofern wären die 140MB/s als excellent zu bezeichnen oder als den Specs entsprechend wenn Du sie im RAID 0 betreibst.

Bei SSD's trennt sich die Spreu vom Weizen im typischen Virtualisierungsumfeld sehr schnell. Insbesondere im RAID-Betrieb. Da kommt es enorm auf die Latenz-Stabilität der SSD's an.
--> Je mehr SSD's im Verbund sind, je breiter die Streuung der Latenz und je öfter ein Write nicht innerhalb der Spezifizierten Zeit abgearbeitet wird, desto häufiger läuft ein Write nicht im angegebenen Latenz Bereich. Die Folge davon: Die Leistung bricht teilweise enorm ein und die IOPS werden im RAID-Verbund nicht mehr erreicht.

Passtrough ist immer schneller und vermutlich läuft dann auch noch die Pufferung mit wodurch Du eine schnellere Übertragung hast. Auch fällt dann ein CPU-Cycle auf der virtuellen Netzwerkkarte weg.

[Dayworker]

Der H310 ist nix weiter als ein H200 mit grösserem FW-Flashspeicher. Beiden Controllern gemein ist, daß sie keinen Cache haben. Der einzig nennenswerte Unterschied ist die deutlich längere Queue beim H310.

Bei der LSI-FW muß man leider etwas aufpassen. Diese muß sowohl zum Treiber als auch zu den HDD/SSDs passen. Bei einigen FW-Versionen wie der P20 weiß man jedoch, daß dazu Threads ob der schwachen Performance geschrieben wurden. LSI, bzw wie auch immer der jetzige Eigentümer heißt, hat jedoch neue Treiberversionen veröffentlicht. Mehr, als sich in diese Thematik einzulesen, bleibt leider nicht und notfalls muß man ein FW-Downgrade in Erwägung ziehen. Leider erfordern die Treiberversionen entsprechende FW-Stände und man kann halt nicht beliebig FW und Treiber kombinieren.

Reichst du den Controller per Passthrough durch, greift der Dateisystem-Cache des jeweiligen Gast-OS. Der ESXi dagegen hat diesen Cache nicht, weil er ausser VMFS keine anderen Dateisysteme kennen muß. Das erklärt dann die deutlichen IO-Unterschiede.

[UrsDerBär]

@Dayworker: Denke nicht, dass die Firmware hier einbremst. Die Specs der SSD sind 17k. Insofern liegt er da schon über den Specs und sollte happy sein =)

Reichst du den Controller per Passthrough durch, greift der Dateisystem-Cache des jeweiligen Gast-OS. Der ESXi dagegen hat diesen Cache nicht, weil er ausser VMFS keine anderen Dateisysteme kennen muß. Das erklärt dann die deutlichen IO-Unterschiede.

Das meinte ich übrigens damit, dass noch die Pufferung mitläuft (des OS).


Da Du zudem mit grossen Files innerhalb der gleichen VM hantierst, liegst bei Passtrough auch sicher im sequentiellen Bereich und via VMFS eben tendenziell im 4KB Block Bereich.

[snipor]

Vielen Dank für eure Antworten.

Die SSDs sind nicht im Raid, beide einzeln.

Hier mal ein paar CDM Tests:

Ganz normal als Virtual Disk:

Passthrough:

Wenn es am fehlenden Cache des H310 liegt, sollte es dann nicht mit dem LSI 9361-8i mit Platten als JBOD besser sein?

Warum bricht es nie ein wenn ich von der Samsung SSD auf eine der Seagates schreibe, hier sollte sich doch Probleme mit der Schreibleistung der SSDs auch bemerkbar machen?

CPU Last ist immer 40-60% egal ob Passthrough oder nicht, direkt auf der physischen Maschine installiertes Windows 1-3%.

Passthrough ist zum großteil sogar langsamer als die anderen getesteten Szenarien. Sollte sich das da nicht eher wie direkt wie auf der physischen Maschine verhalten?

Also schneller sein? Warum bricht die Übertragungsrate, wenn sie denn einbricht, erst nach einer bestimmten, nicht immer gleichen Menge an geschriebenen Daten ein?
Es wurde immer die gleiche Datei zum Testen genutzt.


Vielen Dank

Jürgen

[UrsDerBär]

Ein Cache auf dem Controller verschnellert eine SSD in der Regel nicht. Es ist eher das Gegenteil der Fall. Deshalb schalten die meisten Controller den Cache für SSD-Verbünde sogar aus.

Alle Deine Übertragungsarten sind ungefähr da wo sie der Hersteller spezifiziert. Man kann im Test auch gut die lausige Read-Rate für Low-Queue bei 4kb Random erkennen. Ist leider typisch für viele SSD's.

Es ist schwierig ganz genau Ursachen zu definieren. Deine Platten liegen auf dem gleichen Controller. Also tendenziell möglich, dass Sie sich gegenseitig beeinflussen und so langsamer sind als Controller zu Controller. Dann müssen SSD's - so zumindest die Thoerie - erst auf Maximal-Auslastung gebracht werden bevor man reproduzierbare Daten erhält. Dann kann es noch sein, dass die Reads von Deiner Samsung stabiler ankommen als die der Nytros. Und dann eben noch der OS-Cache.

Deine letzten Screen-Shots zeigen aber eher Passtrough im Vorteil

[snipor]

Habe weiter getestet. Alle drei SSDs an die Board SATA Ports, keine extra Controller.
DIe beiden Seagate SSDs an einen ParaVirtual und mit provisioning thick eager zeroed.

CPU Last hier nur 20% und höhere Schreibleistung

Ich habe irgendwie trotzdem das Gefühl, dass da ESXi irgendwie ein Problem mit Controllern über PCIe hat. Kann das vielleicht ein Einstellungsproblem sein, evtl. auch im Bios des Boards?

Danke

[Dayworker]

Unabhängig von Passthrough hängt die Übertragungsleistung in einer VM immer auch von der Host/Gast-Auslastung ab. Eine VM bekommt nur dann Rechenzeit zugeteilt, wenn die konfigurierte Menge an vCPUs auch wirklich frei ist. Ist das nicht der Fall, wird die VM pausiert und erhält Boni im RR-Verfahren. Die Zeit in einer VM ist damit nicht stabil und der VM-Plattencontroller wird ohne Passthrough auch "nur" in SW abgebildet. Die Meßwerte in einer VM sagen demzufolge rein garnix aus und müssen auch in Relation der Ausgabe von esxtop gesehen werden.
Wenn du also reale, vergleichbare Meßwerte haben willst, kannst du das nur direkt auf dem ESXi und bei abgeschalteten VMs erreichen.


Wie von Urs bereits angesprochen, haben viele SSDs Schwierigkeiten ihre Leistung auch bei niedrigen IO-Queuetiefen zu erbringen. Entweder wurde eine SSD darauf "geeicht" oder die IO-Leistung fällt in solchen Fällen sehr deutlich ab. Die Frage ist auch, welche Relevanz sequentielle IO-Messungen bei den üblichen Aufgaben haben. In der Virtualisierung dürften deutlich mehr Anfragen mit Bezug zum 4KB- oder 4MB-Raster auftreten.

Hinsichtlich der IO-Werte am selben Controller muß man sich auch mal dessen CPU-Anbindung genauer anschauen. Soweit mir bekannt ist, verwendet Intel dazu DMI/UMI sprich eine abgewandelte PCIe-Verbindung und damit ist auch die maximale IO-Rate limitiert. Ob du bereits in dieses Limit reinreichst, kann ich dir jedoch nicht sagen.

[snipor]

Leider bin ich hier immer noch nicht weiter gekommen.
Es befindet sich im Moment nur eine einzige VM auf dem System.
Fragen die noch offen sind.
-Warum gibt es keine Probleme und Einbrüche wenn ich von der Samsung SSD auf die Seagates kopiere?
-Warum habe ich eine hohe CPU Last in der VM beim Kopieren, Windows direkt auf der physischen Maschine hat keine CPU Last (0-2%)

Habe jetzt noch folgendes probiert.
Eine Seagate am H310 und für diesen Passthrough aktiviert.
Zweite Seagate an einen Sata Port. Paravirtual und eger zeroed eingestellt.

4GB RAM

8GB RAM

16GB RAM

Kann noch jemand etwas dazu sagen?

Danke

[Dayworker]

-Warum gibt es keine Probleme und Einbrüche wenn ich von der Samsung SSD auf die Seagates kopiere?

Der 6.5er kann mit SSDs deutlich besser umgehen, weil bei SSDs auch noch Verbesserungen stattfinden. Bei HDDs gibt es nur noch Grössere Laufwerke und das war es.

-Warum habe ich eine hohe CPU Last in der VM beim Kopieren, Windows direkt auf der physischen Maschine hat keine CPU Last (0-2%)

Windows hat einen Dateisystem-Cache der extrem viel abfedert. Laß mal einen sequentiellen SSD-Bench bei 64er Queuetiefe mit mehr als 8GB Datengrösse laufen und du wirst dich wundern, wie hoch die CPU-Auslastung ansteigt. Eigentlich logisch, weil umso schneller eine SSD sequentiell übertragen kann, desto schneller muß die CPU auch neue Daten ranschaffen.

[snipor]

-Warum gibt es keine Probleme und Einbrüche wenn ich von der Samsung SSD auf die Seagates kopiere?

Der 6.5er kann mit SSDs deutlich besser umgehen, weil bei SSDs auch noch Verbesserungen stattfinden. Bei HDDs gibt es nur noch Grössere Laufwerke und das war es.

Leider kann ich Deiner Ausführung nicht ganz folgen bzw. kann den Zusammenhang zu meiner Frage nicht erkennen. Könntest Du das bitte nochmal etwas genauer erklären?

Vielen Dank

[Dayworker]

Die Samsung 840 ist für Lesen/Schreiben mit bis zu 96k/​62k IOPS angegeben, deine Nytro XF1230 dagegen mit bis zu 98K IOPS beim Lesen und nur bis zu 16K IOPS beim Schreiben. Sequentiell nehmen sich beide nicht viel und erreichen beim Lesen Werte nahe am SATA3-Maximum. Beim Schreiben sieht es anders aus, da erreicht die Samsung nur noch 250MB/s und Seagates angeblich bis zu 500 MB/s. Letzteres dürfte nur für Daten im Cache gelten, denn wenn man mal gegenrechnet, ergeben bei der Samsung 62k Schreib-IOPs x 1000 x 4KB = 248MB/s. Das stimmt dann fast mit den Samsung-Angaben überein. Bei den Seagates dagegen stehen nur 16k Schreib-IOPs x 1000 x 4KB = 64MB/s an, wenn die Daten nicht aus dem Cache kommen. Die Seagates werden auch als "Kostengünstige Leistungssteigerung für Cloud- und Unternehmensanwendungen" und ideal für "Öffentliche und private Clouds, Tiered-Storage-Analysen, Webserver, leseintensive Umgebungen, Boot-Anwendungen" beworben.

In die Überlegungen fällt auch die Frage mit rein, ob die Seagates für den H310-Controller freigegeben wurden. Die Samsung gibt es schon länger am Markt als die Seagates. Es ist also gut möglich, daß die Controller mit der Samsung besser "klarkommen". Mit in diese Schiene rein fällt, daß SSDs extern nicht nur mit 4KB sondern auch grösserer Sektorgrösse daherkommen und intern noch mit deutlich grösseren Verwaltungsgrössen zwischen 4-8MB operieren. Je nach SSD-Füllstand und Effektivität deren GC kommen dann noch andere, für IO-Leistung negative Effekte hinzu. Die andere Frage ist, ob der ESXi alle SSDs überhaupt als solche erkannt und entsprechend geloggt hat.

Wie bereits geschrieben, sind dein Meßwerte nicht wirklich brauchbar, weil die Zeit in einer VM in Abhängigkeit zur CPU-Auslastung im Fluß ist. D.h., daß du direkt auf ESXi-Ebene ganz andere Meßwerte über esxtop erhalten wirst und diese sind die einzig verwertbaren Meßgrössen.

Die Meßwerte auch in der VM müßten sich eigentlich verändern, wenn du wie zuletzt geschrieben 1 Seagate am H310 und die andere wie die Samsung am Chipsatz-Sata zu hängen hast. Wenn sich dabei keine Unterschiede zeigen, siehst du nur wie effektiv der Dateisystem-Cache von Windows ist.

[snipor]

Habe mal die Anzeige in Windows mit der in esxtop verglichen. Dort ist der Einbruch nicht zu sehen, wenn ich das richtig interpretiere.

Die Werte des H310 lassen sich so nicht mehr überprüfen da Passthrough für diesen aktiviert wurde, richtig?

Außerdem habe ich einen Test mit einer Ubuntu VM durchgeführt, dort erreiche ich laut Anzeige nur 80 MB/s egal welche SSD Ziel und Quelle.

[Dayworker]

Wenn Passthrough aktiviert und die damit ausgestattete VM läuft, ist der ESXi aussen vor, weil die Gerätekontrolle dann der Gast hat. Der ESXi ist auch aussen vor, wenn auf dem Controller bzw genauer dem Datenträger am Controller kein VMFS läuft. Der ESXi kann nur VMFS.

Wegen der Ubuntu-VM schau mal nach, worin die Config-Unterschiede zur Win-VM liegen und gleiche die erstmal an, damit beide OS ihren Dateisystem-Cache möglichst gleichgroß auslegen können. Wie bereits geschrieben sind die Meßwerte in einer VM nicht aussagekräftig aufgrund der variablen Zeit. In beiden Bildern ist jedoch die Ausgabe von esxtop druntergelegt und die sind in meinen Augen doch fast identisch.