VirtIO Disk Usage CPU Spikes

[ItsHaze]

Ich habe folgendes Problem,
sobald die Disk 2-3% hat spiked die CPU auf 100% und macht jede Arbeit praktisch zunichte, da dass ganze eine GPU VM ist und die Frames auf praktisch 0 gehen für 1-3 Sekunden.

Ich bin schon ne ganze weile am Googlen usw. und bin jetzt auf was gestoßen was ich aber in Proxmox nicht finde, es handelt sich um IOThreads.
Wüsste jemand wo genau die zu finden sind um das ganze zu aktivieren und einzustellen.

Das Problem liegt wohl daran das alle IO Virtual Sachen e.g. Disk und Netzwerk Adapter, vom Standart Emulator Thread gebrauch machen was bei 1er VM kein Problem wäre aber ab 3-4 wohl zu genau diesen Problemen führt.

Wenn da jemand etwas mehr hintersteigt als ich wäre ich sehr dankbar für ein paar Denkanstöße wo ich dannach suchen muss.


Host:

AMD Ryzen Threadripper 2950X
256 GB Ram
NVIDIA Tesla M10


EDIT: Es ist nicht der Netzwerk Adapter sondern die Disk, Disk auf 1-3% usage und zack cpu sagt 100%.

Video Beispiel: https://www.youtube.com/watch?v=oq7rXLSGKH8

 

[Falk R.]

Wie ist der Host ausgestattet und wie sieht denn die Konfiguration der VM aus?

 

[Neobin]

was ich aber in Proxmox nicht finde, es handelt sich um IOThreads.
Wüsste jemand wo genau die zu finden sind um das ganze zu aktivieren und einzustellen.

Den Storage-Controller der VM auf "VirtIO SCSI single" umstellen und bei den vDisks "IO Thread" aktivieren/anhaken: [1].

Ist seit PVE 7.3 auch der Standard für neu erstellte VMs:

In the web interface, new VMs default to iothread enabled and VirtIO SCSI-Single selected as SCSI controller (if supported by the guest OS)

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_7.3

[1] https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_hard_disk

 

[ItsHaze]

Den Storage-Controller der VM auf "VirtIO SCSI single" umstellen und bei den vDisks "IO Thread" aktivieren/anhaken: [1].

Ist seit PVE 7.3 auch der Standard für neu erstellte VMs:

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_7.3

[1] https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_hard_disk

Ich danke schonmal es hat "etwas" geholfen ist wohl wirklich die Disk, CPU spiked immernoch zwar nichtmehr auf 100% aber immernoch zu hoch so das Performance drastisch einbricht.

https://bugzilla.kernel.org/show_bug.cgi?id=199727

Werde morgen mal NVMe daneben probieren und schauen ob das dass ganze komplett behebt.

 

[Neobin]

Für potentielle weitere Hilfe, solltest du schon mehr Infos bereitstellen; siehe den Post von @Falk R.. Insbesondere auch in Bezug auf den Storage und dessen Aufbau.

 

[Falk R.]

Ohne eine Konfiguration gesehen zu haben, vermute ich mal CPU Typ kvm64 statt host.
Außerdem könnte es auch an CPU Überbuchung liegen. Ist aber alles reines Raten ohne Informationen.

 

[ItsHaze]

Ohne eine Konfiguration gesehen zu haben, vermute ich mal CPU Typ kvm64 statt host.
Außerdem könnte es auch an CPU Überbuchung liegen. Ist aber alles reines Raten ohne Informationen.

CPU Typ ist auf Host, hab mal nen paar Infos geadded wenn du mehr brauchst sag einfach bescheid bin grad eher so der zwischen händler

Gibt es die Möglichkeit die IOThreads auf nen CPU Core zu pinnen?
e.g. VM 1 & 2 bekommen Core "1" für die IOThreads usw.

 

[Falk R.]

Für mich wäre interessant wie viele virtuelle Cores auf wieviel physikalische verteilt werden.

 

[Falk R.]

Was auch gut bremsen kann: aktivierte C-States im BIOS.

 

[ItsHaze]

Für mich wäre interessant wie viele virtuelle Cores auf wieviel physikalische verteilt werden.

4 Virtuelle Pro Physik, C-States sind aus

 

[Falk R.]

bei vielen 1-2 Core VMs ist das kein Problem, wenn du viele 8 Core+ VMs hast, bekommst du sehr lange Warteschlangen.

 

[Neobin]

Immer noch kein Wort zum verwendeten Storage...

• Wie schaut es bei anderen VMs aus?
• Wie schaut es bei dieser VM ohne PCIe-Passthrough aus?
• Wie schaut der IO-Delay auf dem PVE-Host aus zum Zeitpunkt des Problems?
• Wurde schon mal ein anderer Storage (für diese VM) getestet?
• Läuft Sicherheitssoftware jeglicher Art (speziell irgendwelche Scanner) in der VM?
• ...

 

[ItsHaze]

bei vielen 1-2 Core VMs ist das kein Problem, wenn du viele 8 Core+ VMs hast, bekommst du sehr lange Warteschlangen.

VMs haben alle 4 Cores, gibt es ne möglichkeit den IOThreads nen Core zu pinnen?

 

[Falk R.]

Vergiss das pinnen, der CPU Scheduler ist immer besser als manueller Eingriff.
Beantworte mal die Fragen von @Neobin, dass hilft uns beim eingrenzen.

 

[ItsHaze]

Immer noch kein Wort zum verwendeten Storage...

• Wie schaut es bei anderen VMs aus?
• Wie schaut es bei dieser VM ohne PCIe-Passthrough aus?
• Wie schaut der IO-Delay auf dem PVE-Host aus zum Zeitpunkt des Problems?
• Wurde schon mal ein anderer Storage (für diese VM) getestet?
• Läuft Sicherheitssoftware jeglicher Art (speziell irgendwelche Scanner) in der VM?
• ...

Wie schaut es bei anderen VMs aus? - Gleich

Wie schaut es bei dieser VM ohne PCIe-Passthrough aus? - Gleich

Wie schaut der IO-Delay auf dem PVE-Host aus zum Zeitpunkt des Problems? <1 MS

Wurde schon mal ein anderer Storage (für diese VM) getestet? - Nein

Läuft Sicherheitssoftware jeglicher Art (speziell irgendwelche Scanner) in der VM? - Nein

Zur storage unten pics

 

[Falk R.]

Mal getestet wenn weniger VMs laufen?

 

[ItsHaze]

Mal getestet wenn weniger VMs laufen?

Passiert genau das selbe.

 

[Falk R.]

@Stoiko Ivanov
Ich vermute hier gibt es eine Verbindung zum Thread https://forum.proxmox.com/threads/s...n-for-qcow2-on-zfs-with-5-15-39-2-pve.123639/

Ich habe das Problem mit einem Kumpel auf Discord gelöst. Diese CPU Belastung und der zusätzliche Write Traffic sind verschwunden nachdem atime auf dem ZFS deaktiviert wurde. Anscheinend erzeugt ZFS zu viele Access Informationen und erzeugt damit massive writes und somit auch CPU Last. Hier wird aber kein qcow genutzt.