Windows Server 2025 mit RDP / Festplatten Geschwindigkeit sehr schlecht

[Tompa]

Hallo Zusammen

Wir haben vor kurzem einen Server mit Proxmox (Version aktuell 9.1.5) ausgestattet und drei Windows Server 2025 darauf installiert.
Einer davon fungiert als RDP Host Server.

Soweit hat auch alles geklappt mit der Installation, auch laufen alle Server.
Nun ist uns aber aufgefallen das vor allem der RDP Server bei kleinsten Aktionen eine sehr hohe Festplattenauslastung aufweist.
Zum testen haben wir mal eine Webseite geöffnet (Blick.ch) und die Festplattenaktivität gingt blitzartig auf 100% für ca. 15s.
Der Durchsatz lag aber nur bei 0.1Mbit/s.



Wird wiederum eine 450MB Datei aus dem Internet gezogen dann ist diese in ca. 10s heruntergeladen.

System:
Host: HPE ML110 Gen11 (Gold 5416S 16 Cores)
RAM: 128GB
Datenträger: SSD WD Red 1TB (jeweils in zwei Raid 1)
Anbindung an Proxmox mit HPE HW Raid Controller p408i
Datastorage: LVM

Der RAM und CPU liegen entsprechend im grünen Bereich egal ob 5 oder 10 User auf dem RDP sind.
Nun sind wir uns unsicher ob es einfach ein Anzeige Problem ist oder es wirklich irgendwo klemmt.
Gemerkt wurde es aufgrund dessen das Outlook extrem lange hatte bis es geöffnet wurde, denn auch wenn man Outlook auf dem RDP öffnet geht die Auslastung des Speichers gleich auf 100%.
Auch stürzt Outlook oder generell Office sehr oft ab, das konnte innerhalb von 15min vier mal beobachtet werden.
Wir vermuten das es was mit der Überlastung der Festplatten zu tun haben könnte.

Anbei die Einstellungen welche aktuell vorhanden sind.
VirtIO und Guest Agent sind installiert. (Version virtio-win-0.1.271-1)



Da es unser erstes Produktives System ist, sind wir nicht in allen Punkten so sattelfest. Die Einstellungen haben sicher noch Luft nach oben. ;-)
Darum würde ich mich über eure Hilfe freuen und bin über jeden Input froh. Vielleicht braucht es noch mehr Infos, last mich das bitte wissen.
Da das System bereits im Einsatz ist können wir nur behutsam Änderungen vornehmen.

Vielen Dank für eure Hilfe.

 

[6equj5]

Einer davon fungiert als RDP Host Server.

Und nur der hat die Probleme? Worin unterscheiden die sich denn?

... und die Festplattenaktivität ging blitzartig auf 100% für ca. 15s.

Anderer Browser?

Auch stürzt Outlook oder generell Office sehr oft ab, das konnte innerhalb von 15min vier mal beobachtet werden.

Platte voll? ;-)

Sieht man auf dem PVE auch was? (I/O pressure)

 

[cwt]

WD Red SSD, consumer drives im HW RAID1, da kann man nicht viel an Performance erwarten. Gerade bei virtualisierten Terminalservern mit multiplen User sessions. Ihr habt hoffentlich nicht noch ZFS auf das HW RAID gepackt?

Wie sieht denn der I/O delay im PVE aus, wenn die Symptome auftreten?

 

[6equj5]

hoffentlich nicht noch ZFS auf das HW RAID

Er schreibt was von LVM.

WD Red SSD, consumer drives

Ich hab die SN700 und die gehen einwandfrei. Hab zwar keinen TS laufen aber 'n WS2K25 auf meinem PVE-NAS und es läuft Chrome mit xx Tabs und meist noch ein FF. Outlook auch. Und es gibt keine Spikes auf den virtuellen Disks. Ich hab allerdings kein LVM sondern ZFS.
Das mit dem "Enterprise-SSD-only" halt ich für arg übertrieben. Jedenfalls die hier beschriebenen Symptome haben damit m.E. nix zu tun.

 

[Tompa]

Und nur der hat die Probleme? Worin unterscheiden die sich denn?

Es ist effektiv nur beim RDP Host spürbar, auf dem DC und auch auf dem Fileserver sieht man keine solchen Schwankungen.
Unterschieden werden sie hauptsächlich durch die Ressourcen (CPU und RAM, Maschinentyp und Prozessor), Speicher ist jedoch der selbe.

Platte voll? ;-)

Anderer Browser kann ich noch versuchen, jedoch ist 100% bei 0.1Mbit/s schon recht unterirdisch.
Nein der Speicher ist nicht voll, da ist noch reichlich Platz verfügbar.

Sieht man auf dem PVE auch was? (I/O pressure)

Ich kann die Tabelle schlecht einschätzen ob das nun eher schlecht oder in Ordnung ist.
Ist natürlich eine Momentaufnahme, die Aufzeichnung läuft im 5min Takt, da kann man schlecht rausfinden ob genau dann wenn etwas abstürzt ein hohes I/O Aufkommen war.

 

[Tompa]

WD Red SSD, consumer drives im HW RAID1, da kann man nicht viel an Performance erwarten. Gerade bei virtualisierten Terminalservern mit multiplen User sessions. Ihr habt hoffentlich nicht noch ZFS auf das HW RAID gepackt?

Wie sieht denn der I/O delay im PVE aus, wenn die Symptome auftreten?

Ja das ist uns bewusst, aber eben 0.1Mbit/s ist auch für eine WD Red massiv zu wenig.
Wobei ja der Download der grossen Datei recht flott ging, da würde ich nicht von einem Performance Problem sprechen.

Nein es ist kein ZFS im Spiel, das haben wir gewusst das dies keine schlaue Kombo ist.

 

[cwt]

Er schreibt was von LVM.

Ich hab die SN700 und die gehen einwandfrei. Hab zwar keinen TS laufen aber 'n WS2K25 auf meinem PVE-NAS und es läuft Chrome mit xx Tabs und meist noch ein FF. Outlook auch. Und es gibt keine Spikes auf den virtuellen Disks. Ich hab allerdings kein LVM sondern ZFS.
Das mit dem "Enterprise-SSD-only" halt ich für arg übertrieben. Jedenfalls die hier beschriebenen Symptome haben damit m.E. nix zu tun.

Single User Kram auf consumer drives - Glückwunsch, wenn es bei Dir läuft. Aber ein Terminalserver ist eine andere Liga als ein User, der ein bisschen surft oder einen Mailclient offen hat. Das sind komplett unterschiedliche Workloads.

Und nein, der Punkt bezüglich consumer drives im professionellen Umfeld (ein TS ist kein Schnäppchen und wird zu 99,9% produktiv genutzt) ist nicht arg übertrieben. Die Symptome (100% Auslastung, aber nur wenig wirklicher Durchsatz) sind typisch für Storage-Latenz bzw. I/O-Stalls. Die SSDs sind für niedrigere Dauerlast und sequentielle writes optimiert, also eher für Dateiserver/NAS. Windows Terminalserver mit RDP benötigt aber random write mit Sync, konstante Latenz hohe IOPS bei kleinen Blöcken. Der HW RAID Controller macht es zudem nicht besser. Kein sauberes TRIM, GC läuft u.U. blind, write cache + flush Chaos.

Gerade Outlook/Office ist bei konkurrierendem Zugriff empfindlich, was I/O-Timeouts und sich blockierende writes angeht.

 

[Tompa]

Single User Kram auf consumer drives - Glückwunsch, wenn es bei Dir läuft. Aber ein Terminalserver ist eine andere Liga als ein User, der ein bisschen surft oder einen Mailclient offen hat. Das sind komplett unterschiedliche Workloads.

Und nein, der Punkt bezüglich consumer drives im professionellen Umfeld (ein TS ist kein Schnäppchen und wird zu 99,9% produktiv genutzt) ist nicht arg übertrieben. Die Symptome (100% Auslastung, aber nur wenig wirklicher Durchsatz) sind typisch für Storage-Latenz bzw. I/O-Stalls. Die SSDs sind für niedrigere Dauerlast und sequentielle writes optimiert, also eher für Dateiserver/NAS. Windows Terminalserver mit RDP benötigt aber random write mit Sync, konstante Latenz hohe IOPS bei kleinen Blöcken. Der HW RAID Controller macht es zudem nicht besser. Kein sauberes TRIM, GC läuft u.U. blind, write cache + flush Chaos.

Gerade Outlook/Office ist bei konkurrierendem Zugriff empfindlich, was I/O-Timeouts und sich blockierende writes angeht.

Wir haben die gleichen SSD auch bei uns verbaut der Unterschied ist jedoch das es sich um einen anderes Server Modell handelt DL380 Gen10 und das es auf Esxi 8.0 läuft.
Auch mit HW Raid Controller und Raid 1, da haben wir keine solchen extremen Lastspitzen auch wenn sich mehrere Personen auf dem RDP befinden.
Wir wollen ja weg von Esxi....

 

[6equj5]

Auch mit HW Raid Controller und Raid 1, da haben wir keine solchen extremen Lastspitzen auch wenn sich mehrere Personen auf dem RDP befinden.

Das ist hier so 'ne Standardantwort, "Consumer SSD? Weg damit - Problem gelöst". Überzeugt mich nie so recht, aber leider kann ich Dir auch keine andere einfache Lösung nennen.

Also ... der RDS ist neu und testweise auf PVE, richtig? Von wievielen (Test-)Usern reden wir denn da? 500? Oder eher 5? Und wann geht die Disk auf 100%? In einer RD-Session oder lokal auf dem Server? Nur wenn erst ein paar User drauf sind oder schon bei einem einzigen?

Und ... mich irritiert das numa=1 ... Ist auf der Maschine m.E. nicht nötig. Ob es schadet, darüber gibt's wie immer unterschiedliche Meinungen. Aber wenn es meiner wär, würd ich's mal rausnehmen.

Dann laß vielleicht mal den CrystalDiskMark laufen, ich finde, der sagt schon was aus. Auf meinen Consumer-SSD sieht das so aus:


Stimmt schon, die IOPS sind nun nicht die Welt, aber ... wenn ich z.B. auf den RDS in unsrer Firma gucke, mit 50 Sessions, der braucht CPU. I/O ist da völlig vernachlässigbar.

 

[Johannes S]

Nun ja SSDs mit plp können rein technisch Dinge, die Consumer-ssfs nicht können, das wurde auch mal sehr erschöpfend hier im Forum ausdiskutiert:

F

Thread 'Powerloss Protection (PLP) Mythos'

Nov 5, 2024

Ich habe mich früher schon gefragt, warum man eigentlich eine Batterie für einen Raidcontroller Cache braucht, wenn man denn 2 Netzteile und 'ne USV hat. Das man also ohne BBU den Cache nicht verwenden kann, fand ich damals schon dämlich.

Hier im Forum wird immer wieder betont, wie wichtig PLP bei SSDs ist, weil man dadurch deutlich mehr Performance bekommt. Ich habe mich damals schon gefragt, was PLP denn mit Performance zu tun hat. Da ich mich aber nicht auskenne, habe ich die Aussage einfach übernommen. Jetzt bin durch die horrenten Preise zu PLP SSDs wieder über die Frage...

• floh8
• zfs performance
• Replies: 56
• Forum: Proxmox VE (Deutsch/German)

Was ich nicht überzeugend finde: Aus der privaten "hier geht es"-Erfahrung auf Anforderungen für einen multi-user-Terminalserver im Unternehmenseinsatz zu schließen, aber jeder wie er mag.

 

[Tompa]

Das ist hier so 'ne Standardantwort, "Consumer SSD? Weg damit - Problem gelöst". Überzeugt mich nie so recht, aber leider kann ich Dir auch keine andere einfache Lösung nennen.

Also ... der RDS ist neu und testweise auf PVE, richtig? Von wievielen (Test-)Usern reden wir denn da? 500? Oder eher 5? Und wann geht die Disk auf 100%? In einer RD-Session oder lokal auf dem Server? Nur wenn erst ein paar User drauf sind oder schon bei einem einzigen?

Und ... mich irritiert das numa=1 ... Ist auf der Maschine m.E. nicht nötig. Ob es schadet, darüber gibt's wie immer unterschiedliche Meinungen. Aber wenn es meiner wär, würd ich's mal rausnehmen.

Dann laß vielleicht mal den CrystalDiskMark laufen, ich finde, der sagt schon was aus. Auf meinen Consumer-SSD sieht das so aus:
View attachment 96836

Stimmt schon, die IOPS sind nun nicht die Welt, aber ... wenn ich z.B. auf den RDS in unsrer Firma gucke, mit 50 Sessions, der braucht CPU. I/O ist da völlig vernachlässigbar.

Habe den Test auch gemacht.
Sieht schon etwas anders aus als bei dir. Die Werte hauen einem absolut nicht vom Hocker.
Nur liegts an der SSD selber oder an fehlenden Treibern?

Gemäss Specs von WD müssten über 500Mbit/s drin liegen, wenn man dann noch etwas abzieht wegen HW Raid und Virtualisierung sollte doch mind. noch die Hälfte drin liegen.



Hier noch der Test von unserem Server mit den gleichen SSD's.
Auch nicht der Oberhammer aber schon einiges Performanter als mit dem Proxmox Setup.



Noch als Randinfo, mit CrystalDiskInfo wird das Laufwerk auf dem Server gar nicht erst gefunden, Meldung keine Disk erkannt.

 

[cwt]

ESXi vs. Proxmox kann man nie 1:1 vergleichen, da ESXi anders arbeitet und einiges „kaschiert“. ESXi puffert writes wesentlich aggressiver und verzögert Flushes. Die Interaktion mit HW RAID ist auch anders als bei Proxmox. Und um wirkliche Vergleiche ziehen zu können im Sinne „Da läuft es besser“: ist das denn der exakt gleiche Workload? Das kann man auf einem TS schwerlich nachstellen.

CrystalDiskMark ist wenig aussagekräftig. Reale workloads für den Storage innerhalb der VM simuliert man besser mit DiskSpd (in der Shell).

diskspd.exe -c5G -d60 -r -w30 -b4K -o32 -t4 -Sh -L testfile.dat

- kleine Blöcke (b4k)
- random I/O (r)
- write 30% / read 70% (w30)
- queue depth (o32), um multiuser zu „simulieren“
- Threads (t4)
- kein OS cache (Sh)
- L (Latenz)

Den Test mehrfach wiederholen. Wichtig ist hier die Latenz. Grenzwertig sind Avg. 3-11ms und 99th 20-50ms.

Und noch mal was zum Thema consumer vs. enterprise SSDs: das Thema wurde schon mehr durchgekaut als eine Palette Kaugummis. Wer im Forum sucht bzw. der Suche mächtig ist, findet genügend Erklärungen zum Thema und was die Laufwerkstypen voneinander unterscheidet.

 

[6equj5]

Hier noch der Test von unserem Server mit den gleichen SSD's.

Bin letztes Jahr umgestiegen von VMware. Hab übrigens die exakt gleiche CPU wie bei Euch (im Homelab). Und es ist definitiv nix langsamer geworden unter PVE. Das ist grundsätzlich schon ziemlich gut. Also ... irgendwo hakt's bei der Konfig.

Datenträger: SSD WD Red 1TB (jeweils in zwei Raid 1)
Anbindung an Proxmox mit HPE HW Raid Controller p408i

Kannst Du das noch näher erläutern, ggf. Screenshot vom iLO.
Hab letzte Woche erst 'n ProLiant Gen10 umgestellt. Der hat SAS SSD (die berühmte Enterprise Class). Bei Euch sind SATA, richtig? Ist natürlich schon ein Unterschied... Aber: wie gesagt, wenigstens dieselbe Leistung wie unter ESXi muß drin sein. Hab ich noch nie anders erlebt.

 

[6equj5]

CrystalDiskMark ist wenig aussagekräftig.

Kann ich nicht nachvollziehen.

Reale workloads für den Storage innerhalb der VM simuliert man besser mit DiskSpd (in der Shell).

Da kommt ziemlich genau dasselbe raus:

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1775222784 |       433404 |      28.22 |    7223.42 |    0.319 |     0.234 | testfile.dat (64GiB)
     1 |      1780256768 |       434633 |      28.30 |    7243.90 |    0.318 |     0.212 | testfile.dat (64GiB)
     2 |      1799565312 |       439347 |      28.60 |    7322.47 |    0.315 |     0.186 | testfile.dat (64GiB)
     3 |      1821843456 |       444786 |      28.96 |    7413.12 |    0.312 |     0.152 | testfile.dat (64GiB)
     4 |      1786023936 |       436041 |      28.39 |    7267.37 |    0.339 |     0.188 | testfile.dat (64GiB)
     5 |      1808527360 |       441535 |      28.75 |    7358.94 |    0.335 |     0.167 | testfile.dat (64GiB)
     6 |      1838800896 |       448926 |      29.23 |    7482.12 |    0.332 |     0.163 | testfile.dat (64GiB)
     7 |      1831006208 |       447023 |      29.10 |    7450.40 |    0.333 |     0.168 | testfile.dat (64GiB)
-----------------------------------------------------------------------------------------------------
total:       14441246720 |      3525695 |     229.54 |   58761.74 |    0.325 |     0.185
Total latency distribution:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.000 |      0.000 |      0.000
   25th |      0.261 |      0.219 |      0.252
   50th |      0.320 |      0.268 |      0.297
   75th |      0.394 |      0.311 |      0.374
   90th |      0.471 |      0.375 |      0.451
   95th |      0.528 |      0.406 |      0.504
   99th |      0.771 |      0.530 |      0.711
3-nines |      2.690 |      1.531 |      2.417

7K IOPS, etwas weniger MB/s, etwas höhere Latenz. Die Größenordnung ist jedenfalls genau dieselbe wie bei Crystal. Das alles auf einem LVM-Thin aus drei nicht mehr allzuneuen Consumer-SSD.
Um richtig "schlechte" Werte zu bekommen, muß ich schon etwas Aufwand betreiben. Auf meinem NAS im 4-disk raidz1 ohne jegliche SSD-Unterstützung geht das.

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       791425024 |       193219 |      12.58 |    3220.27 |    8.665 |    58.189 | v:\testfile.dat (128GiB)
     1 |       898871296 |       219451 |      14.29 |    3657.46 |    7.606 |    50.685 | v:\testfile.dat (128GiB)
     2 |       924884992 |       225802 |      14.70 |    3763.31 |    7.452 |    51.665 | v:\testfile.dat (128GiB)
     3 |       925495296 |       225951 |      14.71 |    3765.79 |    7.521 |    50.799 | v:\testfile.dat (128GiB)
-----------------------------------------------------------------------------------------------------
total:        3540676608 |       864423 |      56.28 |   14406.83 |    7.780 |    52.736
Total latency distribution:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.021 |      0.018 |      0.018
   25th |      1.484 |      0.636 |      1.232
   50th |      3.044 |      1.966 |      2.698
   75th |      8.677 |      4.655 |      7.162
   90th |     22.035 |      9.859 |     17.274
   95th |     34.368 |     13.529 |     28.388
   99th |     67.732 |     21.985 |     60.134
3-nines |    162.085 |     80.046 |    151.153

Aber sowie ich ein special vdev aus 2x WD SN700 NMVE hinzunehme, rennt es da auch.

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      7457787904 |      1820749 |     118.51 |   30338.38 |    0.886 |    18.003 | v:\testfile.dat (128GiB)
     1 |      7652585472 |      1868307 |     121.60 |   31130.82 |    0.871 |    18.200 | v:\testfile.dat (128GiB)
     2 |      7811358720 |      1907070 |     124.13 |   31776.71 |    0.859 |    17.560 | v:\testfile.dat (128GiB)
     3 |      7963713536 |      1944266 |     126.55 |   32396.49 |    0.844 |    17.338 | v:\testfile.dat (128GiB)
-----------------------------------------------------------------------------------------------------
total:       30885445632 |      7540392 |     490.79 |  125642.39 |    0.865 |    17.771
Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      7457787904 |      1820749 |     118.51 |   30338.38 |    0.886 |    18.003 | v:\testfile.dat (128GiB)
     1 |      7652585472 |      1868307 |     121.60 |   31130.82 |    0.871 |    18.200 | v:\testfile.dat (128GiB)
     2 |      7811358720 |      1907070 |     124.13 |   31776.71 |    0.859 |    17.560 | v:\testfile.dat (128GiB)
     3 |      7963713536 |      1944266 |     126.55 |   32396.49 |    0.844 |    17.338 | v:\testfile.dat (128GiB)
-----------------------------------------------------------------------------------------------------
total:       30885445632 |      7540392 |     490.79 |  125642.39 |    0.865 |    17.771

Also. "Consumer-SSD" sind so schlecht nicht. Die SN700 haben jetzt in 4 Jahren gerade mal 16% verwirkt. Das reicht also für weitere 20 Jahre.
Was ich nicht habe, ist PLP. Da verzicht ich halt, genauso wie auf ECC.

 

[cwt]

Es ist ja völlig in Ordnung, wenn dein Setup in deinem Umfeld gut funktioniert. Das stellt auch niemand in Frage. Hat aber mit dem Workload des TE nichts zu tun. Deine Werte sind auch in Ordnung – aber sie zeigen nur, dass dein Setup unter diesen synthetischen Bedingungen gut performt.

Entscheidend bei einem Terminalserver ist nicht die durchschnittliche Performance, sondern die Latenz-Stabilität unter konkurrierender Last über längere Zeiträume. Genau dort unterscheiden sich Consumer- und Enterprise-SSDs (QoS, Garbage Collection, PLP etc.). Genau diese Situationen (GC, Flush, konkurrierende Writes) treten in kurzen synthetischen Tests typischerweise gar nicht oder nur unzureichend auf.

Ein einzelner DiskSpd-Lauf auf einem ruhigen System bildet diese Szenarien daher nicht ab. Deshalb lassen sich daraus keine generellen Aussagen zur Eignung für TS-Workloads ableiten. Noch ein kleiner Hinweis zu Deiner Idee, dass die Laufwerke noch 20 Jahre halten: wear out ist nicht linear und sagt vor allem nichts über das Laufzeitverhalten unter Last aus. Füllen sich die SSDs → mehr write amplification → aggressivere GC → mehr interne writes.

Und zum Thema PLP: Bei Laufwerken mit Power Loss Protection sind Writes tatsächlich committed und nicht nur im Cache. Ohne PLP muss eine SSD Write-Caches konservativer behandeln und häufiger flushen, was zu erhöhten Latenzen und genau den beschriebenen Spikes führen kann.

 

[Tompa]

Bin letztes Jahr umgestiegen von VMware. Hab übrigens die exakt gleiche CPU wie bei Euch (im Homelab). Und es ist definitiv nix langsamer geworden unter PVE. Das ist grundsätzlich schon ziemlich gut. Also ... irgendwo hakt's bei der Konfig.

Kannst Du das noch näher erläutern, ggf. Screenshot vom iLO.
Hab letzte Woche erst 'n ProLiant Gen10 umgestellt. Der hat SAS SSD (die berühmte Enterprise Class). Bei Euch sind SATA, richtig? Ist natürlich schon ein Unterschied... Aber: wie gesagt, wenigstens dieselbe Leistung wie unter ESXi muß drin sein. Hab ich noch nie anders erlebt.

Ja bei unserem Server stimmen die Werte so auch, was man halt erwarten kann.
Ist auch völlig ausreichend.

Anzahl TS Teilnehmer zur gleichen Zeit zwischen 4-6.
Ich würde auch vermuten das der Fehler bei uns liegt und es an der Konfiguration mangelt.

Was müsstet du wissen vom ILO?
Anbei mal ein Auszug aus dem Datastore auf welchem der TS liegt.

 

[Tompa]

Generell noch was zum Terminalserver.
Habe heute noch etwas draufgeschaut was so läuft.
Irgendwie lässt mich der Verdacht nicht los das es noch an gewissen Anzeigeeinstellungen hängt.

Wenn man sich die CPU Auslastung der einzelnen User mal ansieht und das mit dem Total vergleicht dann passt es nie.
Das ist nur eine Momentaufnahme aber auch Live ergeben die Einzelwerte nie das Total auch wenn man 5min drauf schaut wie sich die Werte ändern, beim Datenträger sieht man es noch eindeutiger.

 

[cwt]

Das, was der TM anzeigt, ist m. E. ein Indiz für den erwähnten I/O-Stall. 0 MB/s -> warten auf I/O.

Wenn Du (außerhab der Userzeiten) das System wirklich testen willst, versuche es (ebenfalls schon mal erwähnt) mit DiskSpd. CrystalDiskMark liefert keine Workload-Ergebnisse.

diskspd.exe -c10G -d180 -r -w40 -b4K -o64 -t8 -Sh -L testfile.dat

 

[Tompa]

Also ich habe mal den Test gemacht.
Einmal mit dem Esxi und einmal mit dem Proxmox System. (unter Vorbehalt der Vergleichbarkeit der beiden Systeme)
Ich bin da kein Profi im interpretieren der Daten aber vermute mal das beide nicht sonderlich berauschend sind. Wenn man die Zeiten ansieht dann sind diese ja himmelweit über den Limiten.
Jetzt aber mal unabhängig davon ob Consumer oder Enterprise SSD, so brutal schlecht können und dürfen die SSD's doch nicht sein.
So schlecht das man es beim Arbeiten auf dem Server effektiv merkt und das System stockt.
Das merkt man auch bereits wenn nur ein User angemeldet ist.

Was kann man denn zu den Speicher Einstellungen im Proxmox sagen, haben wir diese korrekt erstellt oder muss man da nochmals über die Bücher?
Treiber sind wie gesagt die zweiletzte Version der VirtIO Treiber drauf, im Geräte Manager sind keine Infos oder Fehler vorhanden.

Esxi

actual test time:       180.00s

thread count:           8



Socket | CPU |  Usage |  User  | Kernel |  Idle

-------------------------------------------------

      0|    0|  12.47%|   4.04%|   8.44%|  87.53%

      1|    1|  11.21%|   3.78%|   7.42%|  88.79%

      2|    2|  14.64%|   4.94%|   9.70%|  85.36%

      3|    3|  20.89%|   3.77%|  17.13%|  79.11%

-------------------------------------------------

         avg.|  14.80%|   4.13%|  10.67%|  85.20%



Total IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |       552128512 |       134797 |       2.93 |     748.87 |   87.761 |   280.129 | testfile.dat (10GiB)

     1 |       555446272 |       135607 |       2.94 |     753.37 |   86.084 |   257.809 | testfile.dat (10GiB)

     2 |       551378944 |       134614 |       2.92 |     747.85 |   86.807 |   254.334 | testfile.dat (10GiB)

     3 |       548323328 |       133868 |       2.91 |     743.71 |   87.204 |   235.400 | testfile.dat (10GiB)

     4 |       549568512 |       134172 |       2.91 |     745.40 |   88.157 |   399.271 | testfile.dat (10GiB)

     5 |       550715392 |       134452 |       2.92 |     746.95 |   87.950 |   543.375 | testfile.dat (10GiB)

     6 |       552116224 |       134794 |       2.93 |     748.85 |   85.737 |   165.448 | testfile.dat (10GiB)

     7 |       548392960 |       133885 |       2.91 |     743.80 |   86.332 |   165.295 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:        4408070144 |      1076189 |      23.35 |    5978.82 |   87.003 |   311.093



Read IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |       332267520 |        81120 |       1.76 |     450.67 |   81.418 |   268.096 | testfile.dat (10GiB)

     1 |       334585856 |        81686 |       1.77 |     453.81 |   79.430 |   224.924 | testfile.dat (10GiB)

     2 |       330162176 |        80606 |       1.75 |     447.81 |   79.884 |   211.438 | testfile.dat (10GiB)

     3 |       329175040 |        80365 |       1.74 |     446.47 |   80.743 |   205.454 | testfile.dat (10GiB)

     4 |       328794112 |        80272 |       1.74 |     445.95 |   84.639 |   431.167 | testfile.dat (10GiB)

     5 |       330317824 |        80644 |       1.75 |     448.02 |   82.456 |   533.426 | testfile.dat (10GiB)

     6 |       331759616 |        80996 |       1.76 |     449.98 |   78.604 |   139.987 | testfile.dat (10GiB)

     7 |       328441856 |        80186 |       1.74 |     445.48 |   79.535 |   141.683 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:        2645504000 |       645875 |      14.02 |    3588.19 |   80.834 |   299.739



Write IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |       219860992 |        53677 |       1.16 |     298.20 |   97.346 |   297.136 | testfile.dat (10GiB)

     1 |       220860416 |        53921 |       1.17 |     299.56 |   96.165 |   300.577 | testfile.dat (10GiB)

     2 |       221216768 |        54008 |       1.17 |     300.04 |   97.139 |   307.127 | testfile.dat (10GiB)

     3 |       219148288 |        53503 |       1.16 |     297.24 |   96.909 |   274.020 | testfile.dat (10GiB)

     4 |       220774400 |        53900 |       1.17 |     299.44 |   93.397 |   346.299 | testfile.dat (10GiB)

     5 |       220397568 |        53808 |       1.17 |     298.93 |   96.184 |   557.854 | testfile.dat (10GiB)

     6 |       220356608 |        53798 |       1.17 |     298.88 |   96.475 |   197.204 | testfile.dat (10GiB)

     7 |       219951104 |        53699 |       1.17 |     298.33 |   96.482 |   194.870 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:        1762566144 |       430314 |       9.34 |    2390.63 |   96.261 |   327.179



Total latency distribution:

  %-ile |  Read (ms) | Write (ms) | Total (ms)

----------------------------------------------

    min |     15.892 |     19.454 |     15.892

   25th |     30.245 |     36.077 |     31.997

   50th |     34.378 |     40.539 |     37.511

   75th |     48.174 |     55.807 |     51.988

   90th |    180.079 |    196.702 |    186.462

   95th |    265.352 |    297.569 |    279.047

   99th |    821.176 |   1050.319 |    896.558

3-nines |   1353.140 |   2105.288 |   1860.235

4-nines |  16819.549 |  16946.596 |  16911.980

5-nines |  27100.111 |  27286.682 |  27221.230

6-nines |  27587.242 |  27527.076 |  27527.076

7-nines |  27587.242 |  27527.076 |  27587.242

8-nines |  27587.242 |  27527.076 |  27587.242

9-nines |  27587.242 |  27527.076 |  27587.242

    max |  27587.242 |  27527.076 |  27587.242

Proxmox

actual test time:       180.00s

thread count:           8



CPU |  Usage |  User  | Kernel |  Idle

----------------------------------------

   0|  52.98%|  26.86%|  26.12%|  47.02%

   1|  54.12%|  27.24%|  26.88%|  45.88%

   2|  56.83%|  29.43%|  27.40%|  43.17%

   3|  61.41%|  33.85%|  27.55%|  38.59%

   4|  50.12%|  23.85%|  26.28%|  49.88%

   5|  53.60%|  27.96%|  25.64%|  46.40%

   6|  75.02%|  35.17%|  39.84%|  24.98%

   7|  66.09%|  35.23%|  30.86%|  33.91%

----------------------------------------

avg.|  58.77%|  29.95%|  28.82%|  41.23%



Total IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |        41299968 |        10083 |       0.22 |      56.02 | 1142.080 |  1633.188 | testfile.dat (10GiB)

     1 |        41230336 |        10066 |       0.22 |      55.92 | 1150.548 |  1758.071 | testfile.dat (10GiB)

     2 |        40976384 |        10004 |       0.22 |      55.58 | 1164.602 |  1920.972 | testfile.dat (10GiB)

     3 |        40566784 |         9904 |       0.21 |      55.02 | 1178.679 |  1951.415 | testfile.dat (10GiB)

     4 |        32006144 |         7814 |       0.17 |      43.41 | 1351.247 |  2290.434 | testfile.dat (10GiB)

     5 |        35086336 |         8566 |       0.19 |      47.59 | 1377.211 |  2405.737 | testfile.dat (10GiB)

     6 |        41259008 |        10073 |       0.22 |      55.96 | 1152.107 |  1870.831 | testfile.dat (10GiB)

     7 |        40108032 |         9792 |       0.21 |      54.40 | 1191.290 |  1940.033 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:         312532992 |        76302 |       1.66 |     423.90 | 1206.357 |  1969.135



Read IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |        24440832 |         5967 |       0.13 |      33.15 |  688.358 |  1194.540 | testfile.dat (10GiB)

     1 |        24772608 |         6048 |       0.13 |      33.60 |  696.158 |  1312.761 | testfile.dat (10GiB)

     2 |        24571904 |         5999 |       0.13 |      33.33 |  713.134 |  1338.154 | testfile.dat (10GiB)

     3 |        24399872 |         5957 |       0.13 |      33.09 |  736.579 |  1418.821 | testfile.dat (10GiB)

     4 |        19447808 |         4748 |       0.10 |      26.38 |  923.868 |  2155.225 | testfile.dat (10GiB)

     5 |        20942848 |         5113 |       0.11 |      28.41 |  918.433 |  2108.866 | testfile.dat (10GiB)

     6 |        24825856 |         6061 |       0.13 |      33.67 |  690.064 |  1289.053 | testfile.dat (10GiB)

     7 |        23900160 |         5835 |       0.13 |      32.42 |  726.867 |  1435.193 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:         187301888 |        45728 |       0.99 |     254.04 |  754.240 |  1543.322



Write IO

thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | LatStdDev |  file

-----------------------------------------------------------------------------------------------------

     0 |        16859136 |         4116 |       0.09 |      22.87 | 1799.845 |  1932.458 | testfile.dat (10GiB)

     1 |        16457728 |         4018 |       0.09 |      22.32 | 1834.509 |  2090.593 | testfile.dat (10GiB)

     2 |        16404480 |         4005 |       0.09 |      22.25 | 1840.847 |  2402.646 | testfile.dat (10GiB)

     3 |        16166912 |         3947 |       0.09 |      21.93 | 1845.918 |  2403.513 | testfile.dat (10GiB)

     4 |        12558336 |         3066 |       0.07 |      17.03 | 2013.085 |  2335.820 | testfile.dat (10GiB)

     5 |        14143488 |         3453 |       0.07 |      19.18 | 2056.543 |  2645.560 | testfile.dat (10GiB)

     6 |        16433152 |         4012 |       0.09 |      22.29 | 1850.124 |  2338.268 | testfile.dat (10GiB)

     7 |        16207872 |         3957 |       0.09 |      21.98 | 1876.129 |  2342.929 | testfile.dat (10GiB)

-----------------------------------------------------------------------------------------------------

total:         125231104 |        30574 |       0.66 |     169.86 | 1882.566 |  2313.327



Total latency distribution:

  %-ile |  Read (ms) | Write (ms) | Total (ms)

----------------------------------------------

    min |      1.321 |     43.230 |      1.321

   25th |    460.423 |   1318.074 |    498.943

   50th |    526.735 |   1379.683 |    606.028

   75th |    590.775 |   1423.308 |   1369.048

   90th |    631.771 |   1501.754 |   1438.794

   95th |    682.872 |   9182.841 |   2574.146

   99th |   8579.126 |   9510.670 |   9459.920

3-nines |  19336.984 |  20478.594 |  19385.656

4-nines |  21547.951 |  35726.133 |  35215.973

5-nines |  21828.357 |  35924.520 |  35924.520

6-nines |  21828.357 |  35924.520 |  35924.520

7-nines |  21828.357 |  35924.520 |  35924.520

8-nines |  21828.357 |  35924.520 |  35924.520

9-nines |  21828.357 |  35924.520 |  35924.520

    max |  21828.357 |  35924.520 |  35924.520

[/CODE]

 

[UdoB]

Wenn du deine Testergebnisse in [code]...[/code]-Blöcke fasst, könnte ich das einfacher parsen, weil man dann die Spalten erkennen kann. Du kannst den Beitrag sicher editieren.

Beispielfragment:

%-ile | Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
min | 1.321 | 43.230 | 1.321

Gegenüber

 %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
   min |      1.321 |     43.230 |      1.321