Langsame 4k Performance in Windows 11 VM

J

Joe77

Member
Nov 18, 2022
26
6
8
Hallo,

meine Windows 11 VM auf der 2 Datenbanken laufen ist recht träge.

Kurze Vorgeschichte: Bis letztes Jahr hatte ich meinen Proxmox auf Consumer Hardware laufen (Intel i9 12600k, 128 GB Ram, Samsung Prosumer SSD). Einige Container und VMs drauf. Es lief soweit gut bis auf eine Windows 11 VM auf der 2 Datenbanken laufen (ecoDMS als Dokumentenmanagement und ein Lexware Server für Buchhaltung etc.). Hier war das Lexware immer sehr lansam.
Da ich viel über die ungeügende Leistung von Consumer SSD gelesen habe habe ich nun auf "richtige" Serverhardware gewechselt.

Hier die Eckdaten zum System:

Lenovo ThinkSystem SR630 V3, 1x Xeon Gold 6526Y, 128 GB Ram, 9350-8i Controller, 3x PM983 3,84TB NVMe plus eine SM 863 SSD für das Hostsystem. Die Festplatten habe ich ohne Hardwareraid als ZFS eingerichtet.

Voller Vorfreude habe ich alle VMs umgezogen. Die Linux VMs und Container laufen nach wie vor sehr gut und da kann ich keinen Unterschied merken. Leider kann ich auch beim Windows 11 Server keinen Unterschied feststellen. Das Lexware läuft auch auf der neuen Hardware sehr träge. Mit den CPU Einstellungen habe ich schon einiges probiert und gelernt dass die Einstellung "Host" für W11 nicht gut ist sondern "MAX" oder "x86-64-v4" auszuwählen ist. Jetzt habe ich mal die Festplattengeschwindigkeit mit Cristaldiskmak getestet und mir scheint die 4K Leistung sehr schlecht zu sein (Siehe Anhang).

Hat jemand von Euch eine Idee woran das liegen kann? Die CPU Last des Proxmox liegt bei unter 10% und das IO delay im 0,0X% Bereich. Muss ich dam am Controller noch was umstellen?


Gruß Jochen
 

Attachments

  • Festplattengeschwindigkeit.png
    Festplattengeschwindigkeit.png
    140 KB · Views: 18
Bei drei NVME fährst Du wahrscheinlich RAIDZ? Das ist mit die schlechteste Variante als VM storage. Gerade bei 4K sieht man den Unterschied zu mirror bzw striped mirror.

Lexware ist generell keine Raketensoftware. Beides zusammen mit 2 DB-Systemen innerhalb einer VM sorgt für zusätzliche Probleme. Falls die VM auf einem volblock (raw) liegt, macht auch die volblocksize viel aus.
 
Danke für die Antworten. Hier die Config:

Code: 
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;ide2
cores: 16
cpu: x86-64-v4
efidisk0: ZFS-NVMe:vm-201-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
machine: pc-q35-9.2+pve1
memory: 16384
meta: creation-qemu=9.0.2,ctime=1735753257
name: Lexware-Server25
net0: virtio=BC:24:11:CB:E1:ED,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: win11
scsi0: ZFS-NVMe:vm-201-disk-1,cache=writeback,discard=on,iothread=1,size=400G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=c480c1a0-d32c-4445-85fd-513121b9be08
sockets: 1
startup: order=5,up=30,down=30
tags: production
tpmstate0: ZFS-NVMe:vm-201-disk-2,size=4M,version=v2.0
usb0: host=2-6
vmgenid: 11072b5a-1b1e-4ca2-842f-1770f6a923b7

Das mit den VirtIO Treibern habe ich auch gelesen allerdings waren da die 285er schon drauf. Ich habe dann von Hand den VirtIO SCSI auf 271 zurückgestellt aber keine Performanceänderung festgestellt.

Gruß Jochen
 
Ja die NVMe dürften Onboard angeschlossen sein. Der Controller ist drin aber wie er an der Backplane angeschlossen ist habe ich nicht geprüft. Hier mal die Screenshots vom Storage:
 

Attachments

  • Storage.png
    Storage.png
    78.8 KB · Views: 15
  • ZFS.png
    ZFS.png
    58.2 KB · Views: 15
Ich würde zuerst 3 Dinge prüfen:

1. 16 Kerne sind zu viel. Testweise mit 8, 6 oder 4 probieren.
2. Checken, ob in Win11 die Kernisolierung aktiv ist (Windows-Sicherheit/Gerätesicherheit/Kern-Isolierung/Speicher-Integrität) und die mal deaktivieren
3. Im Virenscanner Ausnahmen für den Lexware Server und die Daten+Datenbanken einrichten
 
Danke für Deine Antwort,

Zu 1: Die Kerne kann ich heute Abend mal reduzieren. Ich hatte bis gestern 12 eingestellt und in der Hoffnung dass es schneller wird mal auf 16 erhöht. Leider keine Änderung.

Zu 2: Die Kernisolierung habe ich deaktiviert (hatte ich irgenwo schon mal gelesen und dann getestet als ich noch mit dem CPU Type "host" vom best Pratice gearbeitet hatte)

Zu 3: Im Defender habe ich die Ausnahmen bereits drin und testweise den PandaAD360 mal komplett deaktiert. Keine Änderung.
 
Hallo @Joe77,

die CrystalDiskMark-Werte bestätigen das Problem — die sequentiellen Werte sind hervorragend, aber 4K Q1T1 mit ~35/28 MB/s ist für drei PM983 NVMe im Verbund deutlich zu wenig. Die Ursache ist, wie @cwt schon angedeutet hat, das RAIDZ1. Bei RAIDZ1 muss jeder kleine Schreibvorgang als Full-Stripe-Write ausgeführt werden (Read-Modify-Write), was die Random-Write-Latenz massiv erhöht. Für Datenbank-Workloads wie Lexware, die hauptsächlich kleine zufällige Schreibvorgänge erzeugen, ist das die denkbar schlechteste ZFS-Topologie.

Prüfe zunächst die aktuelle Konfiguration:
Code: 
zpool get ashift ZFS-NVMe
zfs get volblocksize ZFS-NVMe/vm-201-disk-1
zfs get sync ZFS-NVMe

Falls volblocksize auf dem Default (8K oder 16K) steht, verschärft das das Problem bei 4K-Zugriffen zusätzlich. Ändern lässt sich das leider nur beim Erstellen des Volumes.

Empfehlung: Den Pool von RAIDZ1 auf Mirror umbauen (2 NVMe als Mirror, dritte als Hot-Spare oder zweiter Mirror-vdev). Bei einem Mirror hast du die volle IOPS-Leistung jeder einzelnen NVMe für Lesezugriffe und nur 2x Write-Amplification statt der RAIDZ1-Penalty. Die Disk-VM neu anlegen mit volblocksize=4k oder 8k:
Code: 
zfs create -V 400G -o volblocksize=4k ZFS-Mirror/vm-201-disk-1

Als schnellen Zwischentest ohne Umbau: Lege testweise ein zvol mit sync=disabled an und benchmark das. Falls die 4K-Werte dann deutlich besser sind, weißt du dass die sync-Writes der Flaschenhals sind — dann wäre ein dediziertes SLOG-Device (z.B. eine kleine Optane) eine Alternative zum kompletten Poolumbau.

Zusätzlich würde ich die zwei Datenbanken (ecoDMS + Lexware) auf getrennte VMs mit jeweils eigenen zvols aufteilen. Zwei DB-Systeme in einer VM konkurrieren um denselben I/O-Scheduler und Cache, was die Latenz weiter verschlechtert.
 
  • Like
Reactions: IsThisThingOn, news and boisbleu
OK die Blocksize steht auf 16k. Somit ungünstig.

Code: 
zpool get ashift ZFS-NVMe
NAME      PROPERTY  VALUE   SOURCE
ZFS-NVMe  ashift    12      local

zfs get volblocksize ZFS-NVMe/vm-201-disk-1
NAME                    PROPERTY      VALUE     SOURCE
ZFS-NVMe/vm-201-disk-1  volblocksize  16K       default

zfs get sync ZFS-NVMe
NAME      PROPERTY  VALUE     SOURCE
ZFS-NVMe  sync      standard  default

Ein Umbau auf Mirror würde bedeuten dass ich nur noch 3,8 TB zur Verfügung hätte. Dann wäre eine 4. Platte notwendig.

Mal sehen ob ich die System SSD intern irgenwo anders anschließen kann da ich nur 4 x 3,5" Schächte vorne habe.

Die Datenbanken auf 2 VMs laufen lassen ist soweit kein Problem aber das ecoDMS ist nur für 2-3 Dokumente am Tag. Das sollte den LexwareServer eigentlich nicht beeinträchtigen.
 
Last edited:
Jetzt habe ich mal für den Pool das sync deaktiviert. Die Random 4k Werte der VM haben sich dadurch quasi nicht verändert. Wird das erst nach einem Neustart übernommen?
 
4K volblocksize würde ich für die VM nicht nutzen, das bringt meistens nur overheadb bei Metadaten. Dann eher 8K oder 16K. Für PostGRES (ecoDMS) und Firebird/MSSQL (Lexware) wäre 8K "perfect aligned", bringt aber etwas mehr an Metadaten mit sich. Bei 16K führen 8K writes zu halbgeüllten Blöcken, man hätte aber weniger Fragmentierung.

Erste Amtshandlung: RAIDZ auflösen, Mirror erstellen. Wenn Du eine VM auf das neue Dataset/volblocksize umziehen möchtest, musst die VM restored werden. Ein Verschieben des virtuellen Datenträgers bringt nix.
 
Ich würde dir vom umstellen auf vollblocksize=4k abraten.
Bei RAIDZ1 mit ashift 12 (Default), würdest du nur 50% der Kapazität verwenden können.
RAIDZ ist tricky und etwas komplizierter zu verstehen. Da kommt Padding mit ins Spiel. Bei 16K vollblocksize kannst du die vollen 66% Kapazität nutzen (vereinfacht). Demnach ist das momentan für deine aktuelle Konfiguration sogar richtig. Falls dich das wirklich interessiert:
https://www.truenas.com/community/threads/the-problem-with-raidz.114529/

Das SLOG-Device ist nicht zu empfehlen. Du hast bereits NVMes, da hilft dir ein SLOG auch nicht mehr viel.
Das würde ggf. geringfügig für Sync-writes noch etwas helfen.

Wo ich @Bu66as zustimme:
Wenn du kannst, füge eine weitere NVMe hinzu und mach dir einen ZFS Pool mit 2x vDEVs á 2x NVMe im Spiegel.
Da musst du nich auf Padding oder Performanceprobleme aufpassen.
Nur mit Mirrors, könntest du vollblocksize=4k versuchen. Damit du das Volume nicht neu anlegen musst, erstell einfach ein neues und verwende dieses für die Datenbank.

Ich bezweifle allerdings, dass das extrem täge Verhalten am Storage liegt... Kannst du das Verhalten von Lexware wirklich auf IO Delays zurückführen?
Gibt es hier Statistiken / Logs von Lexware, welche dies belegen?
 
Last edited:
  • Like
Reactions: IsThisThingOn
Mit dem trägen Verhalten von Lexware bin ich eben am suchen. Es war nur meine Vermutung dass es am Storage liegt da die Random 4k Geschwindigkeit schlecht ist. Im Lexware gibt es einen Testbutton mit dem man die Latenz ermitteln kann. Diese liegt lokal auf der Maschine bei um die 2ms und bei den Clients die über das Netzwerk zugreifen bei 3,2ms. Laut FAQ bei Lexware sollte es lokal unter 1ms liegen damit es nicht träge wirkt.

Wenn ich mich per RDP auf der Maschine bewege kommt es mir auch langasm vor (Taskmanger / Explorer öffnen etc.) Aber das ist nur gefühlt und nicht gemessen.
 
@Joe77 versuch mal bitte den CPU Typ v3 bzw. v2-AES.
Ich hatte soeben einen anderen Thread, bei welchem v4 Probleme verursacht hat (auch anderweitig).
Speziell mit VBS (Virtual Based Security) gibt es hier wohl Probleme.

D

Thread 'CPU type `host` is significantly SLOWER than `x86-64-v2-AES`'

I am shocked to discover what seems absolutely counter-intuitive to me, but maybe someone can explain me?

I have a stock Win11 24H2 and I initially set it up with x86-64-v2-AES and it was zipping along as one would expect.

1734300836343.png

Then I realized there is a 'host' CPU type and since I have a 128 GB 72 Core Dual Xeon (Lenovo Thinkstation P710) Proxmox server, I figured I'd just allocate directly as "native" HAS to be better/faster than emulated (anything) right? Wrong.

What I didn't expect is that the VM is barely usable!? The CPUs ALL peg at 100% and eventually...
  • Like
J

[SOLVED] Thread 'Win Server 2k25 - QEMU Disk ultra slow'

Hi,

I have installed a Windows Server 2025, but the IO is misserably slow. I read, that I might have to update the Disk Drives Driver to be vio, but no VirtIO driver seems to work.
The host should not be the issue.

'Update Driver' for the disk tells me I already have the best driver selected.

Is there a way to fix this without a re-install?

Thx!!
Jan


1763386730126.png1763386701637.png1763386548672.png1763386581945.png
 
Mit den Prozessortypen habe ich schon vieles durchprobliert aber die Zeiten der Datenbankserverlatenz nicht notiert. Gefühlt war alles bis auf "Host" in etwa gleich schnell bzw. langsam.

msinfo sagt: Virtualisierungsbasierte Sicherheit: Nicht aktiviert

zum Vergelich zum Post oben habe ich auch mal winsat gestartet:

Code: 
winsat disk
Windows-Systembewertungstool
> Wird ausgeführt: Featureaufzählung ''
> Laufzeit 00:00:00.00
> Wird ausgeführt: Speicherbewertung '-ran -read -n 0'
> Laufzeit 00:00:00.59
> Wird ausgeführt: Speicherbewertung '-seq -read -n 0'
> Laufzeit 00:00:05.97
> Wird ausgeführt: Speicherbewertung '-seq -write -drive C:'
> Laufzeit 00:00:03.47
> Wird ausgeführt: Speicherbewertung '-flush -drive C: -seq'
> Laufzeit 00:00:01.38
> Wird ausgeführt: Speicherbewertung '-flush -drive C: -ran'
> Laufzeit 00:00:01.36
> Dshow-Videocodierzeit                        0.00000 s
> Dshow-Videodecodierzeit                      0.00000 s
> Media Foundation-Decodierzeit                0.00000 s
> Disk  Random 16.0 Read                       192.34 MB/s          7.7
> Disk  Sequential 64.0 Read                   1362.79 MB/s          8.7
> Disk  Sequential 64.0 Write                  803.92 MB/s          8.3
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.255 ms          8.5
> Latenz: 95. Perzentil                        0.395 ms          8.7
> Latenz: Maximum                              1.346 ms          8.9
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.264 ms          8.8
> Gesamtausführungszeit 00:00:13.09
 
Last edited:
  • Like
Reactions: boisbleu
Ich hab das mal auf meinem Homelab getestet: VM (Server 2022) liegt auf einer einzelnen SATA-SSD.

Code: 
C:\Users\Administrator>winsat disk
Windows-Systembewertungstool
> Disk  Random 16.0 Read                       831.29 MB/s          8.6
> Disk  Sequential 64.0 Read                   6700.92 MB/s          9.9
> Disk  Sequential 64.0 Write                  499.80 MB/s          8.1
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.225 ms          8.6
> Latenz: 95. Perzentil                        0.901 ms          8.4
> Latenz: Maximum                              3.323 ms          8.7
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.223 ms          8.9
> Gesamtausführungszeit 00:00:03.28

Und zum Vergleich ein Server 2025 auf einem Hardware-RAID 10 (hier wird natürlich gerade gearbeitet)

Code: 
C:\Users\administrator>winsat disk
Windows-Systembewertungstool
> Disk  Random 16.0 Read                       1101.75 MB/s          8.9
> Disk  Sequential 64.0 Read                   7006.95 MB/s          9.9
> Disk  Sequential 64.0 Write                  7124.38 MB/s          9.9
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.025 ms          8.9
> Latenz: 95. Perzentil                        0.059 ms          8.9
> Latenz: Maximum                              0.229 ms          8.9
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.028 ms          8.9
> Gesamtausführungszeit 00:00:01.88
 
Last edited:
Das sieht bei meiner VM deutlich zu lansam aus. Auf meinem Desktop PC der schon einige Jahre alt ist ist es auch deutlich schneller. Ich stelle mal den Prozessortyp auf V3 und teste. Wobei ich doch auf das Storage tippe.
 
Jetzt mal mit CPU Type V3:

Code: 
winsat disk
Windows-Systembewertungstool
> Wird ausgeführt: Featureaufzählung ''
> Laufzeit 00:00:00.00
> Wird ausgeführt: Speicherbewertung '-ran -read -n 0'
> Laufzeit 00:00:00.47
> Wird ausgeführt: Speicherbewertung '-seq -read -n 0'
> Laufzeit 00:00:03.39
> Wird ausgeführt: Speicherbewertung '-seq -write -drive C:'
> Laufzeit 00:00:02.77
> Wird ausgeführt: Speicherbewertung '-flush -drive C: -seq'
> Laufzeit 00:00:01.45
> Wird ausgeführt: Speicherbewertung '-flush -drive C: -ran'
> Laufzeit 00:00:01.41
> Dshow-Videocodierzeit                        0.00000 s
> Dshow-Videodecodierzeit                      0.00000 s
> Media Foundation-Decodierzeit                0.00000 s
> Disk  Random 16.0 Read                       179.35 MB/s          7.6
> Disk  Sequential 64.0 Read                   3854.19 MB/s          9.4
> Disk  Sequential 64.0 Write                  1200.82 MB/s          8.6
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.229 ms          8.5
> Latenz: 95. Perzentil                        0.486 ms          8.7
> Latenz: Maximum                              10.574 ms          7.9
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.261 ms          8.8
> Gesamtausführungszeit 00:00:09.72
 
You must log in or register to reply here.
Top Bottom
Back