Disk speed sehr langsam

M

mcflux101

Member
Jul 3, 2021
18
0
6
34
Hallo
Ich habe heute eine Windows 10 VM erstellt (2 CPUs, 6GB Ram, 64GB disk) und ich habe zum einschlafen langsame Schreibgeschwindigkeit auf der VM
slowspeed_disk.PNG
Das Maximum was ich bisher hatte war 3MB/s. Ich kann so nicht das Sprachpaket installieren.

VirtIO Guest Treiber sind installiert und werden verwendet:
slowspeed_dis_02.PNG

Bin immernoch Anfängre was Proxmox angeht und bin ein wenig aufgeschmissen.

Kann mir da jemand helfen? Kann auch grne mehr infos liefern.

Grüsse
mcflux
 
Deine virtuelle Disk ist auf "ide" gestellt. Wenn du gute Leistung willst solltest du die Virtio Treiber installieren und auf "virtio SCSI" + "SCSI" stellen statt "virtio SCSI" + "IDE". Wenn du dann nochmal etwas mehr Leistung willst kannst du auch noch die "io thread" checkbox für die virtuelle Disk aktivieren. Wenn der Rechner an einer USV hängt könntest du auch noch den Cache Mode von "none" auf "writeback" stellen.

Das gleiche bei der NIC. Die E1000 ist lahm, hier hilft wieder virtio welche wieder die virtio Treiber braucht.

Auf was für Laufwerken laufen denn deine VMs? Wenn auf dem Host der IO Delay hoch ist, solltest du überlegen eine (fürs Schreiben oder mixed Workloads optimierte Enterprise/Datacenter) SSD zu holen.
 
Last edited:
Die Disks sind WD Red Plus 5400 (WD10EFRX). Hab vorhin bemerkt dass man die Disk Detahcen kann und dann umstellen kann. Allerdings startet die Disk so nicht mehr. Muss jetzt windows auf der neuen disk neu installieren. Scheint aber auch langsam zu sein.
 
Wenn es nach der Neuinstallation immer noch zu langsam ist, dann sollten deine HDDs der Flaschenhals sein. WD Reds sind ok also Datengram für ein NAS aber nicht wirklich für einen Hypervisor brauchbar. Ein Windows PC ist ja so schon echt lahm, wenn man eine HDD statt SDD benutzt.
Und wenn du jetzt 10 VMs erstellst, dann hast du quasi 10 Rechner die sich eine HDD teilen müssen, wobei das bei einem Rechner ja schon recht lahm wäre. Und dann multiplizieren sich noch die Zugriffe auf die HDD da du wegen Virtualisierung und unterschiedlichen Blockgrößen (Stichpunkt: Write Amplification).
Und dann hast du noch die lahmen 5400 U/min statt 10000 oder 15000 U/min wie bei SAS Festplatten, also nur 1/2 oder 1/3 der IOPS einer schnellen HDD.

Am besten mal iostat auf dem host laufen lassen. Ist Teil des sysstat Packages und muss erst installiert werden: apt update && apt install sysstat.
Danach kannst du mal iostat 600 2 ausführen und 10 Minuten warten. Am besten dabei gucken, dass da in den 10 Minuten auch alle VMs maximal ausgelastet sind. Iostat gibt dir einmal sofort Statistiken aus und dann noch ein zweites mal wenn die 10 Minuten um sind. Die ersten Statistiken sind der Durchschnitt bzw die Summe an IOPS, Schreib-/LEserate und Menge der gelesenen/geschriebenen Daten seit dem Reboot. Die Statistiken nach 10 Minuten zeigen nur das an was in den letzten 10 Minuten gemessen wurde.

Eine HDD kann nur so 100-300 IOPS verkraften (bei dir wohl eher Richtung 100). Da kannst du dann gut sehen, mit wievielen IOPS da deine VMs deine HDD befeuern und vergleiche ziehen.

Also kurz:
HDDs sind ziemlich grottig als Storage für VMs, weil sie einfach keine parallelen Zugriffe von vielen VMs verkraften können. Erst recht wenn du die nicht in einem Raid10 oder so betreibst, wo sich die Last auf mehrere HDDs aufteilen könnte. SSDs sind da viel besser und schaffen leicht das 100-fache oder mehr an IOPS, aber hier muss man auch gucken was man nimmt. Enterprise SSDs kommen mit allen Workloads klar, sind immer schnell und halten viel länger (doppelter-dreifacher Preis aber bis zu 30x längere Lebenserwartung). Consumer/Prosumer SSDs sind ok für verschiedene Workloads, brechen aber z.B. bei Sync Writes (also wenn eine DB läuft z.B.) auch super ein und sind dann kaum schneller als eine HDD. Und je nach Workload kann man so eine Consumer SSD wegen der Write Amplification auch schon nach Monaten statt Jahren kaputtgeschrieben haben.
 
Last edited:
bisher hatte ich da ein normales Betriebssystem drauf und das ist die erste VM die ich darauf laufen habe. Habe auch nicht vor 10 darauf laufen zu lassen. Also dort meine VMs maximal auslasten wenn die eine ja nichtmal ein Sprachpaket installieren kann und nur beim Leerlauf die Disk voll ausgelastet ist. Kann mir nicht vorstellen dass das normal ist. Mal gucken ob ich mir eine SSD mal noch leisten will. Verwende es nicht Professionell. Hatte vorher mein Gen 8 Microserver zur Entwicklung verwendet und ging ganz gut. Nun hab ich Proxmos drauf gemacht und dachte dass ich wenigstens einigermaxxen in einer VM arbeiten könnte. Aber das hab ich echt nicht erwartet.
 
Du darfst halt nicht die Write Amplification vergessen die du nicht bei der normalen bare metal Installation von Windows hast.
Ich habe hier z.B. eine Write Amplification von Faktor 7 vom Gast zum Host. Für jeden 1MB den ich in der VM schreibe müsste der Host 7MB schreiben. Dann habe ich noch eine Write Amplification von Faktor 3 innerhalb der SSD, weil eine SSD nie optimal den NAND Flash beschreiben kann. Aus den 7MB werden dann schon 21MB. Und wenn dann noch Sync Write ins Spiel kommen, dann muss mein ZFS sogar noch alles doppelt schreiben. Dann werden die 21MB zu 42MB. Für jeden 1MB den ich synchron in der VM schreibe werden also 42MB auf die SSD geschrieben.
Meine SSDs machen das von der Performance easy mit (eher unschön wegen Lebenserwartung) aber eine HDD, die eh schon zu kämpfen hat, überfordert so etwas natürlich.
Auch wenn du dir bei einer HDD nicht die Write Amplification wegen dem NAND Flash einfängst, hast du dennoch eine gewisse Write Amplification vom Gast zum Host, da du ja auf eine virtuelle Disk schreibst und das irgendwie so bearbeitet werden muss, dass das auf die physische HDD geschrieben werden kann.
Mein Homeserver schreibt hier wegen der Write Amplification im Idle gerade 1TB am Tag. Und das meiste davon sind eigentlich nur Logs, Metrics etc die er selbst erzeugt.
 
Last edited:
Ich lass mal den von dir erwähnten Befehl laufen und guck was der mir aussagt.
 
Last edited:
Also hab das iostat 600 2 mal laufen lassen, hat sich aber nur einmal was getan und wusste nicht ob ich das einfach abbrechen muss oder ob man irgendwie dann die Daten ausgewertet bekommt.

das war auf jeden Fall ausgegeben:
1625344687476.png
 
mcflux101 said:
Also hab das iostat 600 2 mal laufen lassen, hat sich aber nur einmal was getan und wusste nicht ob ich das einfach abbrechen muss oder ob man irgendwie dann die Daten ausgewertet bekommt.
Click to expand...
Der Befehl läuft ohne Rückmeldung für 600 Sekunden weiter. Da muss man dann warten bis die 10 Minuten um sind ohne abzubrechen. Man muss nicht zwingend 600 Sekunden wählen, aber ich finde unterhalb werden die Ergebnisse zu schwammig, da die Laufwerke ja auch Cachen und teils stoßweise schreiben oder noch lange nacharbeiten bis der Cache leer ist.

108 IOPS im Schnitt seit Boot ist schon ziemlich viel für eine HDD. Die ist dann im Idle schon ziemlich gut ausgelastet und fehlt dann nicht mehr viel um sie mit aktiver Nutzung ans Limit zu bringen. Wenn ich mir benchmarks der verschiedenen WD Reds so angucke, dann schaffen die so je nach Modell 70-150 IOPS.
 
Ich komme für unseren Ceph Cluster (den HDD Teil) ebenfalls auf ca 60-80 iops.
Was ich aber nicht ganz verstehe, ist der Teil mit der Write amplification. Das macht aus meiner Sicht nur Sinn, wenn ich einen Storage habe, der redundant schreibt, oder z.B. die zu schreibenden Blockgrößen keine geraden Vielfachen der zugrundeliegenden Hardware-Blöcke sind.
Beispiel wäre eine HDD deren physical Blocksize 4096KB beträgt. Wenn man da ein VM Image drauf liegen hat, wo die VM mit einer Blocksize von 512B arbeitet, muss beim sequential write der physikalische Block im schlimmsten Fall 8x beschrieben werden, wobei das nur bei direct IO so passiert. Ansonsten wird durch NCQ und HDD Cache sowas in der Regel abgefangen und ein solcher Sektor nur einmal beschrieben. Bei random writes haut das aber richtig rein, weil der Cache in solchen Fällen sowas gar nicht abfangen kann.

Die 7MB/s sind ziemlich sicher der Anbindung via IDE geschuldet. Das wird emuliert und ist daher sehr lahm. Ansonsten, wenn das die einzige VM ist und sonst da nichts läuft außer PVE, sollte das meiner Meinung nach nicht so einen derben Unterschied machen. PVE schreibt im ganz normalen Betrieb Logs lediglich in den RAM und erzeugt ansonsten auch kaum IO auf der Festplatte. Es bleibt also mehr oder weniger eigentlich alles an IO für deine VM übrig.
Es bleibt noch die Frage wie dein Storage bei PVE eingehängt ist. Wird das VM Disk Image auf dem Dateisystem als Datei abgelegt, oder nutzt der HDD Storage via LVM direkt die Festplatte ohne Dateisystem?
Wenn die Images als Datei im Dateisystem abgelegt werden, dann ist das ein weiteres Performance Bottleneck, denn dann hast du den Overhead des Dateisystems noch. Beispielsweise wenn es ein ZFS oder ein BTRFS ist, das für den Storage herhalten muss, dann gibt es da natürlich auch nochmal Checksummen, Logs etc. die geschrieben werden müssen. Dann kannst du tatsächlich solche Write Amplification probleme bekommen.
Ich hab dir das mal als Beispiel hier eingefügt, damit du siehst wo du das findest
PVE_Storage.png
LVM ist für local storage auf jeden Fall zu bevorzugen, da es ohne Umweg über ein Dateisystem die Daten direkt in ein Logical Volume auf die Festplatte schreibt. Es kann daher die Festplatte mehr oder weniger direkt nutzen und erzeugt kaum overhead.
 
Last edited:
Ingo S said:
Beispiel wäre eine HDD deren physical Blocksize 4096KB beträgt. Wenn man da ein VM Image drauf liegen hat, wo die VM mit einer Blocksize von 512B arbeitet, muss beim sequential write der physikalische Block im schlimmsten Fall 8x beschrieben werden, wobei das nur bei direct IO so passiert. Ansonsten wird durch NCQ und HDD Cache sowas in der Regel abgefangen und ein solcher Sektor nur einmal beschrieben. Bei random writes haut das aber richtig rein, weil der Cache in solchen Fällen sowas gar nicht abfangen kann.
Click to expand...
Ja, das meine ich damit. Fast alle Proxmox Server dürften mit mit virtio arbeiten was immer mit 512B schreibt wenn man es nicht manuell auf 4K abändert. Und da Proxmox eine solche Option weder per CLI noch GUI anbietet, wird es wohl auch kaum einer umstellen. Bei TrueNAS hat man da z.B. die Wahl ob virtio mit 512B oder 4K arbeiten soll, wenn man eine neue virtuelle Disk mit bhyve erstellt, welches ja auch KVM nutzt.
Da sieht das mit den Blöckgrößen dann ja eher so aus:
4K (Gast OS Dateisystem wie z.B. ext4) -> 512B (virtio virtuelle Disk) -> 8K (standard volblocksize des zvol) -> 4K (ashift=12 vom ZFS Pool) -> 4K (LBA der physischen Disks)

Gerade beim Schritt "512B (virtio virtuelle Disk) -> 8K (standard volblocksize des zvol)" fängt man sich dann ja Write Amplification ein. Ist ja eigentlich nie gut von einer kleineren auf eine größere Blockgröße zu schreiben.
 
Dunuin said:
Gerade beim Schritt "512B (virtio virtuelle Disk) -> 8K (standard volblocksize des zvol)" fängt man sich dann ja Write Amplification ein. Ist ja eigentlich nie gut von einer kleineren auf eine größere Blockgröße zu schreiben.
Click to expand...
Hmm jaein... Ich glaube nicht, das das so einfach ist. Schließlich hat jeder Datenträger einen mehr oder weniger großen Cache und eine Menge an interne Logik um Schreibzugriffe zu beschleunigen. Klar ist, wenn ich 512B Blöcke absolut random auf ein Gerät schreibe das mit 4K Sektoren arbeitet, ja, dann hab ich Write Amplification. Aber jeder Schreibzugriff der sich mithilfe des Cache irgendwie sequentieller gestalten lässt wird totsicher auch sequentiell abgearbeitet. Die Logik in dem Gerät sortiert die Schreibzugriffe insbesondere bei Festplatten grundsätzlich so um das sich der Kopf möglichst wenig bewegen muss und wenn sich mehrere Schreibzugriffe auf den selben Sektor mit 512B Größe im Cache finden werden diese ganz sicher zu 4K Blöcken zusammen gefasst.
Nur wenn man außerdem noch direct IO macht, ganz ohne Cache etc. dann geht sowas natürlich nicht. Darum sieht man ja auch so üble Performance hits in solchen Fällen.
 
You must log in or register to reply here.
Top Bottom