I did some basic performance analysis on the Java process and it appears the high CPU usage stems from the NIOSocketInputStream class which is part of the new secure KVM VNC feature released with ACS 4.18.
In the mean time, I've sized up the Console Proxy VM compute offering with more CPUs (1 vCPU for each potential connection) as each connection gobbles up an entire core's worth of CPU. -Leo > On 02/20/2024 4:51 PM MST Leo Leung <l...@steamr.com> wrote: > > > Just a quick update: > > - I see 100% CPU on the console proxy's java process if one or more VNC > session is in use, even if nothing is happening in the session (such as a > blank screen). Is this normal? > - The persistent 100% CPU appears to be triggered when I try to VNC to the > console proxy itself. Connecting the console proxy to itself somehow causes > the VNC connection to persist until I run 'systemctl restart cloud' on the > console proxy and immediately disconnect from the console. Since the VNC > connection happens to the underlying KVM process on the hypervisor, I'm not > quite sure why this is even a problem. > > Is this a potential bug with the cloud/proxy service? > > -Leo > > > > On 02/20/2024 4:16 PM MST Leo Leung <l...@steamr.com> wrote: > > > > > > Hello everyone, > > > > I am running CloudStack 4.18 and 4.19 in two separate environments and > > notice that in both environments, the Console Proxy SystemVM is pretty much > > pegging its single CPU. Logging in to the SystemVM, top reports the java > > process that handles the VNC connections is constantly using ~100% CPU. > > This behaviour happens even on a cleanly provisioned console proxy (after > > deleting/recreating it) with only a 4-5 established VNC connections (as > > reported by netstat -ntp). > > > > Is this normal? Does anyone else experience this behaviour? Should I assign > > a larger console proxy compute offering? > > > > Thank-you in advance. > > -Leo
