Performanceproblem SSD
- Thread starter TErxleben
- Start date
wenn du socket=1 setzt, zwingst du den scheduler die VM auf eine Physikalische CPU (die wo der Ram von der VM liegt).
Das ist nicht ganz verkehrt.
Wenn alle VMs 4 vCPUs haben dann ist das ganze vernachlässigbar, musst nur auf CPU Pressure achten. Wenn du aber verschieden viele VCPUs in den VMs hast, kann die Situation entstehen wo eine pCPU 17 con 20 Kernen belegt hat und eine VM mit 4vCPUs (1socket) kommt an, die landet dann in der Warteschlange, auch wenn die zweite CPU eventuell auch noch 2Kerne frei hätte. Das ganze verschlimmert sich um so mehr vCPUs pro VM vergeben werden. Wenn dann CPU Monster VMS mit 20 oder mehr vCPUs vorkommen, muss man extrem mit der Überbuchung aufpassen.
Wenn eine Dicke VM in der Warteschlange steht, landen alle nachfolgenden kleinen VMs dahinter in der Warteschlange, auch wenn noch CPU Kerne frei wären. CPU Virtualisierung ist ein Komplexes Thema, wo auch einige Enterprise Kunden immer wieder beim Sizing kämpfen.
Das ist nicht ganz verkehrt.
Wenn alle VMs 4 vCPUs haben dann ist das ganze vernachlässigbar, musst nur auf CPU Pressure achten. Wenn du aber verschieden viele VCPUs in den VMs hast, kann die Situation entstehen wo eine pCPU 17 con 20 Kernen belegt hat und eine VM mit 4vCPUs (1socket) kommt an, die landet dann in der Warteschlange, auch wenn die zweite CPU eventuell auch noch 2Kerne frei hätte. Das ganze verschlimmert sich um so mehr vCPUs pro VM vergeben werden. Wenn dann CPU Monster VMS mit 20 oder mehr vCPUs vorkommen, muss man extrem mit der Überbuchung aufpassen.
Wenn eine Dicke VM in der Warteschlange steht, landen alle nachfolgenden kleinen VMs dahinter in der Warteschlange, auch wenn noch CPU Kerne frei wären. CPU Virtualisierung ist ein Komplexes Thema, wo auch einige Enterprise Kunden immer wieder beim Sizing kämpfen.
Überlasse das lieber dem PVE. Ich habe Kunden mit dicken SQL VMs und vNUMA. Das Thema ist deutlich komplexer und lohnt nur bei ganz vielen vCPUs.
Zähl mal lieber deine vCPUs und guck wie das Verhältnis bei dir ist. Und vorsicht, HT ist kein echter Kern. Bei einer 10 Core CPU darfst du mit HT nicht 20 Cores sondern maximal mit 16 rechnen.
Zähl mal lieber deine vCPUs und guck wie das Verhältnis bei dir ist. Und vorsicht, HT ist kein echter Kern. Bei einer 10 Core CPU darfst du mit HT nicht 20 Cores sondern maximal mit 16 rechnen.
Hi SkyDiver,
es handelt sich um 10VMs jeweils mit einem socket und 4cores konfiguriert. Der Proxmoxserver verfügt über zwei sockets a 20cores (Xeon(R) CPU E5-2660 v3 @ 2.60GHz und 128GB RAM). Ein htop auf dem Eisen zeigt bummeliges Treiben auf allen 40 Kernen. Speicherauslastung ist auch moderat. Ein Neustart erfordert 1h ehe die VMs wieder adäquat reagieren. Kann auch nicht an dusseligen Win10-updates liegen, da diese vor dem letzten Test manuell gemacht wurden und nichts mehr in der Pipeline hing.
es handelt sich um 10VMs jeweils mit einem socket und 4cores konfiguriert. Der Proxmoxserver verfügt über zwei sockets a 20cores (Xeon(R) CPU E5-2660 v3 @ 2.60GHz und 128GB RAM). Ein htop auf dem Eisen zeigt bummeliges Treiben auf allen 40 Kernen. Speicherauslastung ist auch moderat. Ein Neustart erfordert 1h ehe die VMs wieder adäquat reagieren. Kann auch nicht an dusseligen Win10-updates liegen, da diese vor dem letzten Test manuell gemacht wurden und nichts mehr in der Pipeline hing.
Last edited:
Siehe Intel Datenbank:
Aber unanhängig davon sollten 40 vCores bei 20 cores/40 threads ja noch voll in Ordnung sein, gerade wenn die Gäste meistens Idle sind.
Last edited:
Mag sein, daß ich den falschen Terminicus Technicus verwende, wie htop und Poxmoxes auch tun. In Proxmox kann ich nur Sockets und Cores zuweisen. In htop bekomme ich 40, laut deinen zitierten Herstellerangaben, eher Threads als cores angezeigt.
Wäre es denn nun schlau, alle VMs auf 1socket und 2cores/threads zu stellen? Oder gar auf 2sockets und 2cores/threads?
Bei den paar VMs dürfte das nicht das Problem sein. Wenn du dann so hohen io pressure hast, müsste jemand anderes das Bottleneck sein. Schon mal iotop installiert? Ich gucke damit immer wer wieviel Traffic macht.
Ist ja auch mein gedankliches Problem. Wenn du dir mein Eingangspost anschaust, siehst du die HW-Ausstattung. Irgendwie sollte die SSD-Leistung in meiner Welt 3-4fach höher liegen. Ein iotop liefert auch keine Ausreisser. Trotzdem braucht die Mühle elendig lange um nach einem Neustart wieder aus dem Kreuz zu kommen und beglückt Montags gerne um 10.00Uhr mit Schluckauf. Um 9.00Uhr funktioniert es noch erwartungsgemäß. Bis auf den "Start- und Montagsaufschluck" läuft die Kiste auch zufriedenstellend.
Last edited:
Dann guck mal um die Uhrzeit, wenn alle zur gleichen Zeit AV Updates installieren kann sowas auch kommen.
Habe mein vorheriges Posting editiert bevor Du geantwortet hast. Auf den win10-VMs ist lediglich der MS-Defender aktiv. Sollte diese SuperSW tatsächlich die Virtualisierungsumgebung in die Knie zwingen können? Bei Win7/XP hatte ich nie derartige Probleme.
Ich habe bei einem Kunden eine DB VM, welche seit einem Update regelmäßig irgendwelche Aufräumjobs durchführt, die das komplette Storage runterziehen.
Leider sind die Ursachen sehr vielfältig.
Leider sind die Ursachen sehr vielfältig.
Erstmal Danke für Deinen Input. Ich habe mir mal die Disk-IO der einzelnen VMs (9x Win10 clients, 1x Win10 client als SQL/Branchenserver, 1x XP, 1x Openmediavault debianbasiert) angeschaut und alle haben einen Peak zur gleichen Zeit. Kein crontab auf dem Proxmox zu dieser Zeit.
Irgendwie deutet alles darauf hin, daß die Win10-Clients alle recht gleichzeitig irgendwas "machen". Das führt natürlich anhängig dazu, daß der Openmediavault-Server auch stärker belastet wird.
Inzwischen glaube ich depremierterweise, es wäre besser mit fetterer HW aufs Problem zu schießen.
Hi,
ich hab das Posting zwar nur überflogen, bin aber mehrfach an diesen Samsung "wäre-gern-ne-Coole-SSD" Pro-Modellen hängengeblieben.... die haben in einem Server für VMs meiner Meinung nach einfach nichts zu suchen. Ausser vielleicht für zuhause zum Spielen.... Nimm was, das sich auch Datacenter-SSD nennen darf. Die haben intern einen ganz anderen Aufbau für Cache und meistens auch einige mehr GB an SLC-NAND für das durchschreiben. Je nach setting gibt Proxmox den SSDs nämlich das "direkt-schreib"-Kommando. Dann ist jede Consumer und Pseudo-PRO-SSD ziemlich schnell am Ende wenn die GBs kommen..... Das kann man mit einem RAID-Controller samt Puffer/Capacitator und Cache zwar etwas "kompensieren", aber richtig toll wird das dann auch nicht...
Ich vermute also der IO-Delay kommt sowohl von den SSDs, als auch ggf. von einer Überbuchung. Wichtig auch die Power-Settings für den Prozessor so einstellen, das der "IMMER" Vollgas fährt. Im Bios C1E etc abschalten und im Linux zum Beispiel mit tuned-adm das System auf VOLLGAS stellen.
Die Schaltzeiten selbst aktuellster Intel-CPUs sind leider immer noch unterirdisch aus den C-States. Wenn die Kerne also nur leichten LOAD fahren, verbringen die mehr Zeit mit schlafen und aufwachen als mit der Arbeit. Das bremst dann, auch und besonders IOPS.....
ich hab das Posting zwar nur überflogen, bin aber mehrfach an diesen Samsung "wäre-gern-ne-Coole-SSD" Pro-Modellen hängengeblieben.... die haben in einem Server für VMs meiner Meinung nach einfach nichts zu suchen. Ausser vielleicht für zuhause zum Spielen.... Nimm was, das sich auch Datacenter-SSD nennen darf. Die haben intern einen ganz anderen Aufbau für Cache und meistens auch einige mehr GB an SLC-NAND für das durchschreiben. Je nach setting gibt Proxmox den SSDs nämlich das "direkt-schreib"-Kommando. Dann ist jede Consumer und Pseudo-PRO-SSD ziemlich schnell am Ende wenn die GBs kommen..... Das kann man mit einem RAID-Controller samt Puffer/Capacitator und Cache zwar etwas "kompensieren", aber richtig toll wird das dann auch nicht...
Ich vermute also der IO-Delay kommt sowohl von den SSDs, als auch ggf. von einer Überbuchung. Wichtig auch die Power-Settings für den Prozessor so einstellen, das der "IMMER" Vollgas fährt. Im Bios C1E etc abschalten und im Linux zum Beispiel mit tuned-adm das System auf VOLLGAS stellen.
Die Schaltzeiten selbst aktuellster Intel-CPUs sind leider immer noch unterirdisch aus den C-States. Wenn die Kerne also nur leichten LOAD fahren, verbringen die mehr Zeit mit schlafen und aufwachen als mit der Arbeit. Das bremst dann, auch und besonders IOPS.....
Wenn du schon so weit bist, gib doch nicht auf. Jetzt nur noch zu der Zeit auf den Resourcenmanager schauen welcher Prozess die Last verursacht.
Folgende Beobachtungen/Gedanken möchte ich zum Besten geben:
1) Ein Backup der VMs erzeugt ca. 5% IO-Delay. Die einzelnen VMs sind nicht spürbar beeinträchtigt.
2) Ein Neustart des Servers mit bummelig 12 VMs führt zu 3-4h Ausfall. IO-Delay beim Start liegt bei 15-20% (gesehen, sofern man das Webfrontend erreichen kann). Irgendwann renkt es sich dann ein. Starten der VMs beim booten auf nein gestellt und der Server ist schnell verfügbar. Danach selektives Starten einzelner VMs funktioniert dann leidlich.
3) Gerade passiert: Eine Standard Win10 (21H2) neu gestartet. In NoVNC reagiert die VM extrem träge. In der VM kann man im Taskmanager 100% Datenträgerauslastung beobachten aber keinem "Bösewicht" zuordnen. Das schlägt auf den Server mit 15-20% IO-Delay durch. Komplettes System wird in Mitleidenschaft gezogen. Nach ca. 15min ist der Spuk vorbei und alles reagiert erwartungsgemäß.
4) Wir haben hier mindestens einen erheblich schwachbrüstigeren Server (auch v7.1.6), der sogar mehr VMs hostet. Der hatte noch nie solchen "Schluckauf". Auf diesem kann man in den einzelnen VMs im Gerätemanager allerdings den Standard-LSI-Controller finden. In den VMs des Prolembärens ist es jeweils der VIRTIO-Treiber.
5) Wie kann es sein, daß ein IO-Delay von schlapp 20% im Webfrontend zu einem unbenutzbaren System führt? Anzeige-/Rechenfehler?
Danke im voraus für Anregungen.
Last edited:
Ich habe es gerade nicht gefunden, wie sind denn die SSDs angebunden? Das ein I/O Delay von 20% die Kiste unbenutzbar macht ist nicht ganz ungewöhnlich. 100% wirst du nie sehen können, dann läuft gar nix mehr.
Sorry, aber nein. Ein IO-Delay von 20% darf die "Kiste" nicht unbenutzbar machen. Wenn ein Hypervisor sich per default so verhalten würde, wäre er komplett unbrauchbar. Lastspitzen können vorkommen, das muss der Balancer aber ausgleichen. Es darf langsam werden, aber nicht unbenutzbar.
Das gibt es unter HyperV nicht, unter VMWare nicht und auch nicht unter Proxmox. Solch ein verhalten hat eine Ursache. Wir haben hier im Tagesbetrieb Spitzen bei 22% IO-Delay auf einem ZFS RAID-10 mit Spindeln. Da Ruckelt nichts. Dann würden unsere Kunden uns auch mit entsprechendem "Feedback" steinigen. Ich vermute irgendeine "Komponente" meldet nicht zurück oder geht kurz in einen Deadlock. Das können die ConsumerSSDs sein, oder der onboard SATA-Controller. Das kann dann ein "Treiber-Verhalten" sein..... für Proxmox an sich ist das jedenfalls kein "nicht ungewöhnlich" sondern einfach falsch.
Das System sagt dir das 22% der "Denkzeit" mit warten auf IO zugebracht hat. Das ist nicht geil, aber auch nicht per se schlimm....
