DC VM Kopiergeschwindigkeit geringer als im ESXi Host

ah ok aber warum geht dann das normal kopieren auf der Festplatte nur langsam eben übers Netzwerk? Das ist das was nicht passt.
 
Nicht schlimm lieber einen Tipp als gar keinen. Habe iperf noch nicht machen können aber hab etwas anderes gefunden.
Am Anfang stand unter IPv4FailureReason WFPCompatibility daraufhin hatte ich mal NetOfflodglobal deaktivert aber es wurde nichts schneller.

remote-server-lansgames-NW.png

Beim DB geht es ja schnell aber ich weiß nicht wie ich das NoFailure in die Reason bekomme.

db.png

Obwohl der DC auch diese Einstellungen besitzt und trotzdem langsam geht aber das denke ich dann hat Falk Recht wegen Domaincontroller.

dc.png

Habt ihr da schon mal unter IPv4FailureReason auf NoFailure stellen können? Ich will heute Nachmittag mal den Virenscanner deinstallieren und prüfen ob da was dazwischen gehauen hat. IPerf dann auch noch laufen lassen.
 
Last edited:
Hallo Falk,
auch wenn ich nicht immer deiner Meinung bin (DC File) möchte ich mich recht herzlich bedanken! Du scheinst ja hier zu wohnen und hilfst vielen hier!
Davon lebt das Forum. Also danke nochmal!!!
Ich denke schon dass es das NW ist da internes kopieren und die anderen Server eben das auch schnell arbeiten. Virenscanner Ausschlüsse haben nichts gebracht und ich habe auch keine erhöhte CPU Last beim kopieren. Ich teste das nachher unter Mittag da arbeitet keiner auf dem Servern.
Weißt du vielleicht warum die VMware vmnext NIC Treiber im Windows nur 1 GB anzeigen als im ESXi das sind es ja 10?
Denn mit denen wollte ich probieren und dort ging es auch nicht.
Habe von https://www.catalog.update.microsoft.com/Search.aspx?q=vmware die Treiber vnet genommen.
Auf allen Servern sind auch die Treiber und Tools der virtio-win 0.1.262 iso drauf.
Das liegt daran, dass nur ein VMXNET3 emuliert wird und der scheint dann wohl nicht zu 100% gleich zu sein. Ich nutze den eh nie unter Proxmox, weil der Native Virtio ist immer schneller und erzeugt weniger Last eine eine Emulation eines properitären Produkts.

Hast du denn mal mit iperf gestestet?
Ich chließe immer gern eine Komponenente nach der anderen aus und mit iperf kannst du das Netzwerk perfekt testen.
 
Unter Proxmox mit Windows immer den virtio Treiber. Nur dann gibt es nahezu fullspeed.
 
Das ist mir ja klar, wollte mit einem anderen NIC mit 10 GB mal testen, nun gut was sich heraus gestellt hat die VM ist generell langsam, starten von einem Programm als Test 6-10 Sekunden, früher 2-3. Hatte Virenscanner runter, writeback an aber alles ohne Erfolg. Es muss an der VM liegen. CPU Last nicht wirklich da. Ich finde einfach den Flaschenhals nicht. Sieht alles unauffällig aus.
 
Last edited:
Was für Platten sind im Proxmox? Wie voll ist der Thin Pool. Gibt es Fehlermeldungen im Windows DC selber (Windows Protokolle). Sind die ganzen Vmware Treiber runter.
 
Also wenn wir hier weiterkommen wollen, müssen wir strukturiert eine Fehlerquelle nach der anderen ausschließen.
Hast du denn jetzt schon mal mit iperf gemessen? Dann wissen wir ob es am Netzwerk liegt.
 
Entschuldigung ging einfach nicht früher.

Zur besseren Übersicht ich habe alle Informationen txt Dateien in ein Archiv gepackt. Dort befinden sich, HDD Test, Netz Test und Infos zum System Hardware und Software.
 

Attachments

  • Übersicht.zip
    8.9 KB · Views: 3
Hi, die Diskwerte scheinen plausibel, aber die iperf Messungen sind extrem auffällig. So schwankende Werte habe ich noch nie gesehen, entweder ist dein Netzwerk extrem ausgelastet oder die CPU zu sehr überbucht. Alternativ könnte auch ein Kabel oder Port defekt sein, was zu viele Resends führt und deshalb schwankt, aber das sollte in den Statistiken im Switch auffallen.
 
Danke Dir Falk,
Ich hatte mehr die Disk in Verdacht da es nur Samsung (S-ATA) sind?
Das Netz in dem sich die Server befinden ist ein rein virtuelles, das geht nicht über einen physischen Switch zu einem anderen Server.
CPU überbucht glaube ich nicht komme auf 76 von 96....
Aber wer weiß, mir will es einfach nicht in den Kopf wie ein Netz in 10 G virtuellen Netz nicht performant dann läuft. Ist doch ein virtueller Switch.

Bildschirmfoto vom 2024-11-20 10-46-07.png
 
Last edited:
Du hast keine 96 Cores, sondern 48 Cores mit 96 Threads, aber wenn du nur 76 virtuelle Cores nutzt, sollte das kein Problem sein.
Das ganze sieht ja nach einem Server aus, ist das ein Single oder Dual Sockel Server? Bei Dual socket sollte man niemals mehr Cores einer VM geben, als eine physikalische CPU hat. Wenn die VMs alle kleiner sind gibt es keinen Grund für langsame CPU.
Etwas Tuning was durchaus helfen kann, die C-States deaktivieren, dann taktet die CPU nicht mehr runter.

Das ganze erklärt trotzdem nicht die Schlechte Netzwerkperformance. Wenn das ganze in einem Host abläuft ohne Traffic über einen externen Switch zu schicken, sollten auf einer normalen vmbr ca. 35-40 GBit möglich sein.
 
Es ist ein Dual Sockel und keine VM hat so viel Kerne und sind auch weit weg davon. Die Server VM's sind alle in einem VLAN und wie schon beschrieben auf einer Linux bridge. Von daher muss wie bei den Messungen kein Traffic nach "draußen" und da wundert mich es eben das die Performance so schlecht ist.
Ich kann ja auf die letzte 8.2.9 installieren, den C-States dann mal im BIOS, wird erst Freitag Nachmittag etwas. Wo kann ich im Netzwerk noch nach schauen oder sozusagen ein reset machen und alles neu einrichten. Oder relevante Dateien, modprobe usw. vergleichen? Hatte mal was wegen durchreichen in eine VM eingestellt.
 
Wenn du mal optionen modifiziert hast, bitte einmal rückgängig machen zum testen.
 
Ohne dein Setup im Detail zu kennen habe ich jetzt keine Idee wo das herkommen könnte.
 
Hallo Kollege(n) ;-)

Es könnte auch an Microsofts vermurkstem TCP-Stack liegen. Die Probleme diesbezüglich gingen schon mit 2016 los und haben ihren Höhepunkt in 2022 - in 2025 vllt auch noch. Dazu hat Alexander Fuchs (MysticFox - Betreiber eines Systemhauses) im administrator.de Forum
https://administrator.de/tutorial/w...g-wieder-desuboptimieren-kann-5529700198.html etwas geschrieben.

Wichtig: Das Script von Alex nicht einfach auf einem Server ausführen - es ist eher für Clients gedacht!

Das erklärt zwar nicht warum das gerade nach dem Umzug zuschlägt, aber denkbar ist es.

Vllt ist ein erster Schritt - wenn du mutig bist beim DC - auch einfach ein TCP-Reset auf den beiden Servern per
netsh interface tcp reset
in einer administrativen cmd.

Gruß Nico
 
  • Like
Reactions: boisbleu

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!