Ruhiges IT-Forum

Hallo,
ich betreibe eine Debian 9 VM mit einem einzelnen CPU-Kern und 2 GB RAM.
Mit WAPT 1.3 und 70 Maschinen gab es keine Probleme, aber seit dem Upgrade auf 1.5 erreicht die CPU-Auslastung ein- oder mehrmals täglich 100 % und der Server friert ein. Ich muss ihn dann neu starten.
Welche Hardwareanforderungen gelten (insbesondere bei einer Erweiterung auf mehr als 300 Maschinen)? Oder liegt es an einer fehlerhaften Konfiguration?

Das ist seltsam, dieses Problem ist uns nicht bekannt. Möchten Sie uns mehr darüber erzählen?

Ich weiß nicht, was ich noch sagen soll.

Ich teste auf genau 66 Maschinen mit Windows 7 Pro.

Der Server ist eine Debian 9 Basic VM ohne Benutzeroberfläche oder andere Dienste, nur für WAPT.
Die Konsole läuft auf einem Windows 10 Pro-Rechner.

Erster Versuch mit Version 1.3: kein Problem.
Nach dem Update von Server und Agenten auf Version 1.5 funktionierte es nach manueller Konfiguration und Neuinstallation der Agenten endlich … allerdings mit regelmäßigen Serverabstürzen, die einen Neustart erfordern, da eine Anmeldung unmöglich ist. Danach startet der Server normal neu, bis zum nächsten Absturz (sehr unregelmäßig).

Auf dem ESX-Host liegt die CPU-Auslastung der VMs bei jedem Problem bei 100 %. Der ESX-Host ist hinsichtlich CPU und RAM für 20 VMs mit 4 GB RAM und 100 GB Festplattenspeicher ausgelegt.

Ich habe das Problem erneut untersucht und zufällig ein identisches Problem gefunden!

https://serverfault.com/questions/85909 ... ver-freeze
https://bugs.debian.org/cgi-bin/bugrepo ... bug=864642

Anscheinend liegt das Problem an der VMware VMXnet3-Karte, wenn ein bestimmtes Netzwerknutzungsmuster vorliegt.
Bei mir funktionierte es mit wapt Version 1.3, aber nicht mit 1.5 – und das, obwohl ich mehr als 10 Client-Rechner hatte!

Liegt es vielleicht am WebSocket-Modus?

Die einfachste Lösung ist also der Wechsel zu einer E1000e-Karte.

Alternativ kann man (bei jedem Systemstart) über rc.local Folgendes ausführen:
`ethtool -K ens192 gro off` `
ethtool -K ens192 lro off`

Das Problem wurde nach dreitägigen Tests mit 66 Maschinen bestätigt... und zwar ohne dass der Wapt-Server eingefroren ist!

Ich selbst habe auf der VM auf eine E1000e-Karte umgerüstet.

Die Aktivierung von Offloading-Funktionen auf virtuellen Netzwerkadaptern erscheint mir generell nicht sinnvoll.
Insbesondere Large Receive Offloading (LRO) soll die Optimierung großer Datenströme auf die Hardware des Netzwerkadapters auslagern. Auf den ersten Blick wirkt dies jedoch widersinnig, da der Netzwerkadapter virtuell ist.
Dieses Problem ist unabhängig von WAPT, wird aber im WebSocket-Betriebsmodus möglicherweise deutlicher.

In allen von uns bereitgestellten virtuellen Windows-Maschinen (auf einem Xen-Hypervisor) deaktivieren wir systematisch Offloading-Funktionen; dies verbessert die Leistung. Merkwürdigerweise deaktivieren die „optimierten“ Netzwerktreiber von Xen diese Funktion nicht standardmäßig.