high CPU usage

richard-vd

New Member
My Safari browser (version 13.1.1 (15609.2.9.1.2) on macOS 10.15.5) sends HTTPS traffic that causes permanently high CPU usage on the server, until I restart WCS. It looks like it happens when the HTTPS connections are closed after timeout. I just go to https://<WCS_IP>:8444/ and around 30 seconds later the CPU usage of WCS is ~300%. It adds up, If I repeat this then all my server's CPU time is eaten up by this.

WCS is the latest version (5.2.695), running on Debian 10 (Buster). The issue does not happen on Amazon EC2.

High CPU usage of WCS shown in top with 'show threads' (WCS is not actively doing anything):
Code:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND      
13221 root      20   0 3014100 221592  34432 R  86.7   5.5   1:19.05 HTTPS-pool-4-th     
13212 root      20   0 3014100 221592  34432 R  86.4   5.5   0:55.28 HTTPS-pool-4-th     
13214 root      20   0 3014100 221592  34432 R  86.4   5.5   0:55.51 HTTPS-pool-4-th     
13215 root      20   0 3014100 221592  34432 R  86.0   5.5   0:55.22 HTTPS-pool-4-th
The connections are not fully closed, they still show as CLOSE_WAIT in netstat:
Code:
# netstat -an | grep 8444
tcp6       0      0 :::8444                 :::*                    LISTEN     
tcp6       1      0 WCS_IP:8444       x.x.x.x:42848     CLOSE_WAIT 
tcp6       1      0 WCS_IP:8444       x.x.x.x:27059     CLOSE_WAIT 
tcp6       1      0 WCS_IP:8444       x.x.x.x:23769     CLOSE_WAIT 
tcp6       0      0 WCS_IP:8444       x.x.x.x:2813      CLOSE_WAIT
On the macOS side, these connections show as FIN_WAIT_2 in netstat:
Code:
% netstat -an | grep 8444
tcp4       0      0  x.x.x.x.56006     WCS_IP.8444      FIN_WAIT_2 
tcp4       0      0  x.x.x.x.56005     WCS_IP.8444      FIN_WAIT_2 
tcp4       0      0  x.x.x.x.56004     WCS_IP.8444      FIN_WAIT_2 
tcp4       0      0  x.x.x.x.56003     WCS_IP.8444      FIN_WAIT_2
 

richard-vd

New Member
I think the underlying problem is with keepalive. It seems Safari is trying to keep the connection alive in a way that is confusing Web Call Server. Using Chrome the connection is kept alive correctly but using Safari the connection is either dropped (in case WCS is running on Java 8) or hangs forever (in case WCS is running on Java 11, using all CPU).
 
Last edited:

Max

Administrator
Staff member
Good day.
This is netty library issue on Java 11. This library is used by WCS for all networking, not just HTTP. The recommended Java versions are 8, 12 or 14. If there's no required JDK version in repositories, please install it manually as described here (the example for JDK 12 installation).
 
Top