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?
WAPT 1.5 and CPU
Forum Rules
Community Forum Rules
* English support on www.reddit.com/r/wapt
* French community support is available on this forum
* Please prefix the topic title with [RESOLVED] if it is resolved.
* Please do not edit a topic that is tagged [RESOLVED]. Open a new topic referencing the old one.
* Specify the installed WAPT version, full version, and build number (2.2.1.11957 / 2.2.2.12337 / etc.) as well as the Enterprise/Discovery edition.
* Versions 1.8.2 and earlier are no longer supported. The only questions accepted regarding version 1.8.2 are related to upgrading to a supported version (2.1, 2.2, etc.).
* Specify the server OS (Linux/Windows) and version (Debian Buster/Bullseye - CentOS 7 - Windows Server 2012/2016/2019).
* Specify the OS of the administration/package creation machine and the machine with the problematic agent, if applicable (Windows 7/10/11/Debian 11/etc.).
* Avoid asking multiple questions when opening a topic, otherwise it may be ignored. If there are multiple topics, open separate topics, preferably one after the other and not all at the same time (i.e., do not spam the forum).
* Include code snippets, screenshots, and other images directly in the post. Links to Pastebin, Bitly, and other third-party sites will be systematically removed.
* As with any community forum, support is provided voluntarily by members. If you require commercial support, you can contact Tranquil IT's sales department at 02.40.97.57.55
Community Forum Rules
* English support on www.reddit.com/r/wapt
* French community support is available on this forum
* Please prefix the topic title with [RESOLVED] if it is resolved.
* Please do not edit a topic that is tagged [RESOLVED]. Open a new topic referencing the old one.
* Specify the installed WAPT version, full version, and build number (2.2.1.11957 / 2.2.2.12337 / etc.) as well as the Enterprise/Discovery edition.
* Versions 1.8.2 and earlier are no longer supported. The only questions accepted regarding version 1.8.2 are related to upgrading to a supported version (2.1, 2.2, etc.).
* Specify the server OS (Linux/Windows) and version (Debian Buster/Bullseye - CentOS 7 - Windows Server 2012/2016/2019).
* Specify the OS of the administration/package creation machine and the machine with the problematic agent, if applicable (Windows 7/10/11/Debian 11/etc.).
* Avoid asking multiple questions when opening a topic, otherwise it may be ignored. If there are multiple topics, open separate topics, preferably one after the other and not all at the same time (i.e., do not spam the forum).
* Include code snippets, screenshots, and other images directly in the post. Links to Pastebin, Bitly, and other third-party sites will be systematically removed.
* As with any community forum, support is provided voluntarily by members. If you require commercial support, you can contact Tranquil IT's sales department at 02.40.97.57.55
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'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`
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`
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.
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.
Tranquil IT
