[SOLVED] Performanceprobleme, NIC Settings zur Performancesteigerung

maxprox

maxprox

Renowned Member
Proxmox Subscriber
Aug 23, 2011
423
57
93
Germany - Nordhessen
fair-comp.de
Hallo,

EDIT: falls das jemand interessiert, würde ich schnell zu Post #16 springen ;-)

Problem:
Eine Medizinsoftware, die auf einem neue aufgesetzten Windows 2019 Std. Server läuft, macht Performanceprobleme.
Die Software wird per Verknüpfung auf den Windows 10 Clients morgens gestartet und ist den ganzen Tag offen.
Werden jetzt neue Patientendaten aufgerufen, kommt es zu einigen Sekunden Verzögerung, die es vor dem Neuaufsetzen nicht gab.
Vorher lief die Software direkt auf einer Windows 2008 R2 VM unter dem selben Proxmox wie jetzt.

Unser gegenwärtiges Setup ist folgendermaßen:
3 VMs unter Proxmox 6.x mit aktuellem no-subscription Kernel
- Debian10/Samba 4 Domaincontroller => nur DC
- Debian10/Samba 4 Fileserver auf dem sämtliche Freigaben realisiert sind
- Windows 2019 Std. Server auf den eingebundenen Freigaben des Samba FS läuft die Windows Medizinsoftware (namens Dampsoft)

Auf den Windows 10 Clients laufen lediglich Verknüpfungen zur Netzwerkversion dieser Software.
(Die Samba Freigaben, welche direkt in den Win10 Clients eingebunden sind, laufen alle gut.)

Durch einen Supportmitarbeiter dieser Medizinsoftware, die komplett auf dem Windowsserver läuft, sind wir darauf aufmerksam gemacht worden, dass es gewisse Einstellungen der Netzwerkkarten-Treiber gibt, die zur Performance Verbesserung führen sollen.

Vorsicht, falls jemand das nachvollziehen möchte: bei jeder Änderung, startet bei Windows der Netzwerktreiber neu und unterbricht somit kurz die Netzverbindung....!

engl. <=> deutsch:
Large-Send-Offload V2 <=> Abladung großer Übertragung V2
Receive Segment Coalescing (RSC) <=> Empfangen von Segmentkoaleszenz (RSC)

Beides soll von default "enabled" auf "disabled" abgeschaltet werden. (Sowohl bei IPv4 als auch bei IPv6)


Kann mir dazu jemand was sagen?
Hat jemand Erfahrung mit solchen Einstellungen?
Hat schon jemand das auf Linux VMsumgesetzt? Wie habt ihr das bei Linuxsystemen gemacht?
(siehe auch:
https://docs.gz.ro/tuning-network-cards-on-linux.html
https://www.intel.de/content/www/de...005783/network-and-i-o/ethernet-products.html)

Die übergeordnete Frage ist natürlich, ob wir das grundsätzliche Setup so abändern,
dass die Windows Software direkt auf der Windows Server VM liegt und nicht mehr in der eingebundenen Samba Freigabe...?

Bin für Hinweise, Erfahrungen Dankbar
Grüße,
maxprox
 
Last edited:
Welche "Netzwerkkarte" ist für den Server 2019 eingestellt?

Ich denke nicht, dass derartige Tweaks in der VM helfen, da die "NIC" via tun-device an der jeweiligen Bridge hängt.
Evtl. kann an dem tun-device geschraubt werden?

Wie sieht es den mit den i/o Werten bei dem Server und dem Host aus?
Evtl. liegt aus auch am Storage, so dass die Verzögerung durch langsamen Datenbankzugriff aufs Storage und nicht durch die Netzanbindung kommt?
 
gmed said:
Welche "Netzwerkkarte" ist für den Server 2019 eingestellt?
Click to expand...
Hallo gmed,

Danke für die Hilfe!
Alle beteiligten Server VMs hängen per virtIO am vmbr0, bei Windows sind die aktuelen stable Treiber installiert, Version am Ende mit x.171
Code: 
net0: virtio=6E:23:B4:A9:99:1A,bridge=vmbr0

Ich denke nicht, dass derartige Tweaks in der VM helfen, da die "NIC" via tun-device an der jeweiligen Bridge hängt.
Evtl. kann an dem tun-device geschraubt werden?
Click to expand...
Meinst du damit direkt auf dem Proxmox die vmbr0 eingestellt per ethtool?
Wobei ich weder auf der Linux (Debian 10) VM noch auf dem Proxmox entsprechende Eigenschaften finde, zu den beiden oben beschriebenen.
Es gibt weder Large-Send-Offload noch irgendwas mit Coalescing

Wie sieht es den mit den i/o Werten bei dem Server und dem Host aus?
Evtl. liegt aus auch am Storage, so dass die Verzögerung durch langsamen Datenbankzugriff aufs Storage und nicht durch die Netzanbindung kommt?
Click to expand...

Ja so eine Vermutung liegt nahe, wir setzten auf ZFS mit ausreichend RAM (64 GB für die drei VMs) und einem Raid10 SATA Serverplatten. Zu beachten ist ja die mickrige Anzahl von Zugriffen: max. greifen drei bis vier Leute gleichzeitig auf die Datenbank zu.
Performancemessung habe ich noch keine gemacht. Aber: wir haben weder die Hardware, noch das Proxmox bei der Umstellung geändert. Beides ist erst knapp vor drei Jahren neu gemacht. Unter dem bisherigen Windows 2008R2, konnten dabei aufgrund der Foundation Version lediglich 8 GB RAM verwendet werden, Die Beschränkung haben wir auch nicht mehr. Vernetzung war und ist ebenfalls gut....

Übrigens gab es im alten funktionierenden Setup auch keinerlei Netzwerk-Treiber-Einstellungen
Ausserdem hatte ich den Eindruck, dass es mit dieser Software unter aktuellen Windows 2019 Servern und vor allem Win10 Clients insg. Prerformance Probleme gibt....(?)


Grüße,
maxprox
 
Last edited:
maxprox said:
Hallo,

Problem:
Eine Medizinsoftware, die auf einem neue aufgesetzten Windows 2019 Std. Server läuft, macht Performanceprobleme.
Die Software wird per Verknüpfung auf den Windows 10 Clients morgens gestartet und ist den ganzen Tag offen.
Werden jetzt neue Patientendaten aufgerufen, kommt es zu einigen Sekunden Verzögerung, die es vor dem Neuaufsetzen nicht gab.
Vorher lief die Software direkt auf einer Windows 2008 R2 VM unter dem selben Proxmox wie jetzt.

Unser gegenwärtiges Setup ist folgendermaßen:
3 VMs unter Proxmox 6.x mit aktuellem no-subscription Kernel
- Debian10/Samba 4 Domaincontroller => nur DC
- Debian10/Samba 4 Fileserver auf dem sämtliche Freigaben realisiert sind
- Windows 2019 Std. Server auf den eingebundenen Freigaben des Samba FS läuft die Windows Medizinsoftware (namens Dampsoft)

Auf den Windows 10 Clients laufen lediglich Verknüpfungen zur Netzwerkversion dieser Software.
(Die Samba Freigaben, welche direkt in den Win10 Clients eingebunden sind, laufen alle gut.)

Durch einen Supportmitarbeiter dieser Medizinsoftware, die komplett auf dem Windowsserver läuft, sind wir darauf aufmerksam gemacht worden, dass es gewisse Einstellungen der Netzwerkkarten-Treiber gibt, die zur Performance Verbesserung führen sollen.

Vorsicht, falls jemand das nachvollziehen möchte: bei jeder Änderung, startet bei Windows der Netzwerktreiber neu und unterbricht somit kurz die Netzverbindung....!

engl. <=> deutsch:
Large-Send-Offload V2 <=> Abladung großer Übertragung V2
Receive Segment Coalescing (RSC) <=> Empfangen von Segmentkoaleszenz (RSC)

Beides soll von default "enabled" auf "disabled" abgeschaltet werden. (Sowohl bei IPv4 als auch bei IPv6)


Kann mir dazu jemand was sagen?
Hat jemand Erfahrung mit solchen Einstellungen?
Hat schon jemand das auf Linux VMsumgesetzt? Wie habt ihr das bei Linuxsystemen gemacht?
(siehe auch:
https://docs.gz.ro/tuning-network-cards-on-linux.html
https://www.intel.de/content/www/de...005783/network-and-i-o/ethernet-products.html)

Die übergeordnete Frage ist natürlich, ob wir das grundsätzliche Setup so abändern,
dass die Windows Software direkt auf der Windows Server VM liegt und nicht mehr in der eingebundenen Samba Freigabe...?

Bin für Hinweise, Erfahrungen Dankbar
Grüße,
maxprox
Click to expand...

Hallo,

ja es sollten alle Offloading Einstellungen auf disabled stehen. Nur so habe ich ein stabiles Windows 2016 als Terminalserver hinbekommen.
Wir haben auch Zahnärtze als Kunden. Dort läuft allerdings Charly.

Grüße
mac
 
Hallo mac.linux.free,

ahh - und okay, kannst du mir bitte sagen, wo ihr welche Einstellung vorgenommen habt?
Also nur in den Treibereinstellungen der Window Server VM?
Auch irgendwas auf dem Proxmox Host?
Und habt die die gleichen Einstellungen auch auf den Windows 10 Clients disabled?
Code: 
IPv4 Checksum Offload - Disable
IPv4 TSO Offload - Disable
Large Send Offload v2 (IPv4) - Disable
Large Send Offload v2 (IPv6) - Disable
Offload IP Options - Disable
Offload tagged traffic - Disable
Offload TCP Options - Disable
## oder bei unserem VirtIO: 
Offload Rx Checksum  - Disable
Offload Tx Checksum  - Disable
Offload Rx LSO - Disable
## EDIT Ende
Receive Side Scaling - Enable (bei mehr als einem Core)
Recv Segment Coalescing (IPv4) - Disable
Recv Segment Coealescing (IPv6) - Disable
TCP Checksum Offload (IPv4) - Disable
TCP Checksum Offload (IPv6) - Disable
UDP Checksum Offload (IPv4) - Disable
UDP Checksum Offload (IPv6) - Disable
Quelle: Performanceprobleme mit Windows 2012
kannst du mir bitte sagen, welche von denen ihr auf welchen Maschinen angefasst habt?

Grüße,
maxprox
 
Last edited:
  • Like
Reactions: itNGO and gmed
maxprox said:
Hallo mac.linux.free,

ahh - und okay, kannst du mir bitte sagen, wo ihr welche Einstellung vorgenommen habt?
Also nur in den Treibereinstellungen der Window Server VM?
Auch irgendwas auf dem Proxmox Host?
Und habt die die gleichen Einstellungen auch auf den Windows 10 Clients disabled?
Code: 
IPv4 Checksum Offload - Disable
IPv4 TSO Offload - Disable
Large Send Offload v2 (IPv4) - Disable
Large Send Offload v2 (IPv6) - Disable
Offload IP Options - Disable
Offload tagged traffic - Disable
Offload TCP Options - Disable
## oder bei unserem VirtIO: 
Offload Rx Checksum  - Disable
Offload Tx Checksum  - Disable
Offload Rx LSO - Disable
## EDIT Ende
Receive Side Scaling - Enable (bei mehr als einem Core)
Recv Segment Coalescing (IPv4) - Disable
Recv Segment Coealescing (IPv6) - Disable
TCP Checksum Offload (IPv4) - Disable
TCP Checksum Offload (IPv6) - Disable
UDP Checksum Offload (IPv4) - Disable
UDP Checksum Offload (IPv6) - Disable
Quelle: Performanceprobleme mit Windows 2012
kannst du mir bitte sagen, welche von denen ihr auf welchen Maschinen angefasst habt?

Grüße,
maxprox
Click to expand...

Hi,

genau so. Aber nur auf dem Windows Server der virtuell ist. Auf dem Host ist nichts spezielles eingestellt. Ebenso auf den Clients wurde nichts spezielles eingestellt. Ihr kommt nicht zufällig aus der Stuttgarter Gegend?

Grüße,
mac
 
mac.linux.free said:
Falls die tweaks nicht helfen sollten, gehe einfach auf e1000 als virtuelle NIC.
Click to expand...
Ja, das ist auf jeden Fall einen Idee,
Ich habe das jetzt alles mit "Offload" deaktiviert, obwohl ich nur überflogen habe was die Eingeschaften bewirken, denke aber auch, dass sie bei VMs eh nicht so relevant sind wie bei Hardware NICs, denn wie Intel schreibt, können deren Hard- und Firmeware manches besser als das Betriebssystem und die CPU, und da wir hier vorn virtuellen Devices sprechen sieht eh alles noch mal komplizierter aus....
Also hilft für mich nur: ausprobieren.
Wenn ich was raus finde melde ich mich, spätestens morgen wird sich die Praxis melden ;-)
Danke euch!
 
Ergebnis mit Einschränkung:
zunächst die Einschränkung:
Gestern Mittag als ich vom Support den Tipp mit dem Deaktivieren der "Offload" Einstellung bekam, hat der selbe Mensch eine Option in der Medizin Software Dampsoft raus genommen, die sofort synchron Patientenbilder mit läd.
Dies hatte auf jeden Fall sofort keine Auswirkung - JEDOCH wurden auch keine Systeme neu gestartet. Das geschah erst gleichzeitig zum heutigen Test (über Nacht):

Auf jeden Fall, läuft die Software (Dampsoft) jetzt -wie erhofft- eher noch schneller als zuvor und nicht mehr langsamer, als mit dem alten Windows. Was voraussichtlich an den Netzwerktreibereinstellungen lag. Oben dargestellte Eigenschaften mit "Offload" wurden von default "enabled" auf "disabled" abgeschaltet.

Von all den Schilderungen aus der Praxis, halte ich diese Bildernachladegeschichte für diese Performanceprobleme für unerheblich.
Falls es noch weitere Infos zu diesen Einstellungen gäbe, wäre ich sehr dankbar, da ich noch einige weitere vergleichbare Installationen habe.
Da stellt sich mir jetzt schon die Frage, ob ich das generell auf Windows Server VMs mit VirtIO NIC so testen sollte?
Zumal mir auch nicht klar ist, welche positiven Auswirkungen diese Einstellungen insbesondere in einem virtuellen Device haben sollen.

Grüße,
maxprox
 
Last edited:
Hallo Markus,

ja in der Tat, ist mir das etwas zu alt, XP und 2003, is nu schon 'en bisschen rumm ;-)

Aber wenn selbst Bitdefender von disablen dieser Eigenschaft schreibt, muss es ja eine nicht zu unterschätzende Stellschraube sein:
https://www.bitdefender.de/support/...rformance-und-geschwindigkeitsfehler-459.html

Was ich zusätzlich noch nicht durchschaue, sind die Auswirkungen dieser Einstellungen "Virtual Device" vs "physical NIC von zB Intel"
Intel schreibt ja dass sie diese Eingenschaften über ihre optimierte Firm- und Hardware besser abbilden können, als Betriebssystem und CPU und/oder somit auch die CPU entlassten. Und beides haben wir ja in einer virtuellen Umgebung gar nicht, bzw. es kann ja eh nur irgendwie emuliert werden. Dann stellt sich natürlich die Frage, warum die Eigenschaften überhaupt in den VirtIO Treiber eingebaut sind .... Hmmm?

Grüße,
maxprox
 
Last edited:
maxprox said:
Hallo Markus,

ja in der Tat, ist mir das etwas zu alt, XP und 2003, is nu schon 'en bisschen rumm ;-)

Aber wenn selbst Bitdefender von disablen dieser Eigenschaft schreibt, muss es ja eine nicht zu unterschätzende Stellschraube sein:
https://www.bitdefender.de/support/...rformance-und-geschwindigkeitsfehler-459.html

Was ich zusätzlich noch nicht durchschaue, sind die Auswirkungen dieser Einstellungen "Virtual Device" vs "physical NIC von zB Intel"
Intel schreibt ja dass sie diese Eingenschaften über ihre optimierte Firm- und Hardware besser abbilden können, als Betriebssystem und CPU und/oder somit auch die CPU entlassten. Und beides haben wir ja in einer virtuellen Umgebung gar nicht, bzw. es kann ja eh nur irgendwie emuliert werden. Dann stellt sich natürlich die Frage, warum die Eigenschaften überhaupt in den VirtIO Treiber eingebaut sind .... Hmmm?

Grüße,
maxprox
Click to expand...
Hi zusammen,
ja, ich habe diese "Tipps" auch schon haufenweise gefunden.
Aber eher im Zusammenhang mit vmware, oder?
Ob sich jetzt virtio und offloading, etc generell ausschließen, oder ob das eben doch auch von der darunterliegenden Hardware abhängig ist, erschließt sich mir leider auch nicht ganz.
Ich lasse mich da aber gerne erhellen ;)

Läuft denn Deine Anwendung jetzt durchgängig besser?

Schöne Grüße

Markus
 
maxprox said:
Hi,
ja, solange ich von der Praxis nichts gegenteiliges mitbekomme - und das würden die sofort tun - läuft das jetzt wie es soll.

Grüße
maxprox
Click to expand...
Nein, erst ein zwei Wochen später bekam ich genervt die Rückmeldung, dass bestimmte Zugriffe immer noch viel zu langsam läuft und viel langsamer als unter der alten Umgebung mit den alten Serverinstallationen.
Ich habe mit dem wirklich bemühten und hilfreichen Support von Dampsoft noch einiges ausprobiert, alles ohne Erfolg.
Workaround:
Wir haben den Samba 4 Fileserver komplett abgeschaltet und alles auf sowieso schon vorhandenen Windows 2019 Server übertragen, der seit dem als File- und Applikationsserver läuft. Seit dem läuft das erst wie es soll.
Aber die Ursache / Lösung könnte sein:
Jetzt wo wir gerade wieder dabei sind, wieder Artzpraxis, neue Server inkl. Samba 4 AD-DC und Fileserver + Wind. 2019 usw.
lese ich mir das Samba 4 Buch von Stefan Kania noch mal an den benötigten Stellen durch.
Und genau bei der von uns zuletzt häufig verwendeten und von Kania empfohlenen Freigabeoption
Code: 
hide unreadable = yes
lese ich jetzt den Hinweis:
"Bei der Verwendung von hide unreadable = yes kan es zu längeren Wartezeiten für die user kommen, wenn die Verzeichnistiefe sehr groß ist und viele Dateien sich in vielen Verzeichnissen befinden. Das System muss dann erst bei allen Dateien und Verzeichnissen die Rechte prüfen ....."
Bingo, eine kurze Recherche zeigt schnell dass bei Problemposts im Netz oft genau dieser Parameter verwendet wurde, oft ohne dann den Zusammenhang bzw. die Lösung zu finden.
Leider habe ich jetzt nicht die Zeit u. Möglichkeit das genau zu testen, noch ein genauen Vergleich mit und ohne diesen Parameter. Zumindest passt das zu meinem Zenario, denn die performance Probleme konnten zumindest auf das Einlesen genau des Verzeichnisses zurückverfolgt werden, in dem die Masse an kleinen Dateien (mehrere 10.000) lagen...
Ich lasse diesen Parameter aber zukünftig weg und baue Freigaben without
Code: 
hide unreadable = yes

Wenn dazu wer was konkretes weis bitte her damit!
Grüße,
 
Last edited:
Also ich kann das nicht nachvollziehen. Wir haben nur Samba 4.12.3 Server im Einsatz (LXC auf ZFS) mit Multichannel und SMB3 bin ich schon auf 10Gbit intern gekommen und das von Windows 10 aus.
 
klar so ist es am einfachsten die rechte zu verteilen...wichtig dabei ist das es über den univention domain controlle per gruppen berechtigt ist
 
okay (das mit den Gruppen ist bekannt). Wie schon gesagt, habe ich diesen Parameter nicht selbst im Vergleich getestet, konnte nur feststellen, dass zB jeder Aufruf dieses Verzeichnisses mit ich glaube etwas über 20.000 Dateien, immer mindestens sehr zäh war zB im Windows Explorer, bis du hoch und runter scrollen konntest, immer wenn das Medizinporg. mit best. Funktionen darauf zugreifen sollte dauerte das grob zwischen 10 u. 60 Sekunden.
Wir haben ein 8 Thread Xeon Xeon CPU E3-1240 v6 @ 3.70GHz, und ein ZFS Raid 10 zwar auf Enterprise Platten, aber "nur" 3,5" 7.500UPM SATA.
Ich kann nur sagen, dass bei uns die NIC Einstellung allein nicht so viel gebracht haben, wie gewünscht. Haben Jetzt Samba 4 DC (ohne Freigaben, reiner DC). Rest alles über W2K19 Std. Server. Bleibt nur noch Samba File-Server zeugs übrig .... als Verursacher
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back