Tranquil IT Forum

Hello,
I have a Debian 9 VM with a single CPU core and 2GB of RAM.
With WAPT 1.3 and 70 machines, there were no problems, but since upgrading to 1.5, the CPU reaches 100% usage one or more times a day and freezes the server. I have to reboot.
What are the hardware requirements (especially if I expand to more than 300 machines)? Or is it a configuration issue?

That's odd, we're not familiar with this problem, would you like to tell us more?

I don't know what else to say.

I'm testing on exactly 66 machines running Windows 7 Pro.

The server is a Debian 9 Basic VM with no interface or other services, only for WAPT.
The console is on a Windows 10 Pro machine.

First try with version 1.3: no problem.
Updated the server and agents to version 1.5. After manually configuring and reinstalling the agents from scratch, it started working... but with regular server freezes requiring a reboot because it's impossible to log in. Then it restarts normally until the next freeze (very random).

On ESX, the VM's CPU usage is at 100% with each problem. The ESX host is sized in terms of CPU and RAM for 20 VMs with 4GB of RAM and 100GB of hard drive space.

I looked into it again and found an identical problem by chance!

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

It seems the problem is due to the VMware VMXnet3 card when there's a specific network usage pattern.
In my case, it worked with wapt version 1.3 but not with 1.5... when I had more than 10 client machines!

A consequence of WebSocket mode?

So the simplest solution is to switch to an E1000e card.

Otherwise (at each boot) via rc.local:
`ethtool -K ens192 gro off` `
ethtool -K ens192 lro off`

Problem confirmed after 3 days of testing with 66 machines... without the Wapt server freezing!

For my part, I switched to an E1000e card on the VM.

Enabling offloading features on virtual network adapters generally doesn't seem like a good idea to me.
In particular, Large Receive Offloading (LRO) is supposed to offload the optimization of large data streams to the network adapter's hardware, but at first glance, this doesn't make sense since the network adapter is virtual.
This problem is independent of WAPT, but perhaps the WebSockets operating mode makes it more apparent.

In all the Windows virtual machines we deploy (on a Xen hypervisor), we systematically disable offloading features; this improves performance. Oddly enough, the Xen "optimized" network drivers don't disable it by default.