VMware SmartAssurance SMARTS | Webservice-Gateway (Java process) associated with DCF consumes high amount of CPU
search cancel

VMware SmartAssurance SMARTS | Webservice-Gateway (Java process) associated with DCF consumes high amount of CPU

book

Article ID: 323814

calendar_today

Updated On:

Products

VMware VMware Smart Assurance

Issue/Introduction

The purpose of this article is to address a known issue with DCF - Webserice Gateway conuming higher amounts of memory

Symptoms:

Webservice-Gateway (Java process) associated with DCF consumes high amount of CPU

References from top command output:

Tasks: 240 total, 1 running, 239 sleeping, 0 stopped, 0 zombie
%Cpu(s): 99.8 us, 0.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 12118248 total, 150016 free, 6807444 used, 5160788 buff/cache
KiB Swap: 4194300 total, 3540676 free, 653624 used. 4927304 avail Mem
PID     USER  PR  NI  VIRT    RES   SHR   S  %CPU   %MEM  TIME+     COMMAND
123864  apg   20  0  7136232  1.0g  10408 S  398.3  8.5   88366:33  java

Process Details:

apg 123864 1 99 Jan10 ? 61-08:40:13 /opt/InCharge/DCF/Java/Sun-JRE/11.0u5/bin/java -javaagent:/opt/InCharge/DCF/bin/.runtime/service/1.13u2/apg-bootstrap-agent.jar -Djava.util.logging.config.file=conf/logging.properties -Djava.util.logging.manager=com.watch4net.apg.logging.jul.ClassLoaderLogManager -Dcom.watch4net.webservice.server.ssl.sslEnabledProtocols=TLSv1.2 -Dcom.watch4net.webservice.server.ssl.ciphers=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 -cp /opt/InCharge/DCF/bin/.runtime/service/1.13u2/apg-service-bootstrap.jar:lib/bootstrap.jar:/opt/InCharge/DCF/Java/Sun-JRE/11.0u5/lib/tools.jar:lib/apg-logging-jul.jar:lib/apg-logging-slf4j.jar:lib/jersey-container-jdk-http-2.26.jar:lib/jersey-media-multipart-2.26.jar:lib/mimepull-1.9.7.jar:lib/yasson-1.0.1.jar:lib/javax.ws.rs-api-2.1.jar:lib/hk2-api-2.5.0-b42.jar:lib/hk2-locator-2.5.0-b42.jar:lib/hk2-utils-2.5.0-b42.jar:lib/javassist-3.22.0-CR2.jar:lib/javax.annotation-api-1.2.jar:lib/javax.inject-1.jar:lib/javax.inject-2.5.0-b42.jar:lib/javax.json-1.1.jar:lib/javax.json-api-1.1.jar:lib/javax.json.bind-api-1.0.jar:lib/javax.servlet-api-3.0.1.jar:lib/jaxb-api-2.2.7.jar:lib/validation-api-1.1.0.Final.jar:lib/jersey-client.jar:lib/jersey-common.jar:lib/jersey-container-servlet-core.jar:lib/jersey-container-servlet.jar:lib/jersey-hk2.jar:lib/jersey-media-jaxb.jar:lib/jersey-media-json-binding.jar:lib/jersey-media-sse.jar:lib/jersey-server.jar com.watch4net.apg.module.plugin.service.Bootstrap com.watch4net.apg.webservice.proxy.Bootstrap main


Environment

VMware Smart Assurance - SMARTS

Cause

This issue is classified as known issue in JDK bug while using the https mode

Resolution



Workaround:

Background

1) According to the VMWare Smart Assurance DCF design, while communicating to DCF's webservice-gateway, the SSL handshake/authentication will be attempted first, and password-based authentication will be used if SSL authentication fails.

2) However, as we are covering this issue from the performance perspective, the CPU cycles are still engaged every time this webservice gateway attempts connection via SSL authentication for HTTPS based connectivity,

3) In order to correctly terminate each exchange, the output stream must be closed, even if no response body is being sent. However according to reference JDK bug, there seems to be an issue with SSLStreams.doClosure method. 

Workaround

On the DCF Hosted Server

To to disable the HTTPS and run the gateway in HTTP mode and avoid further CPU growth please follow the below:

  • Backup the existing <DCF_Install_Dir>/Tools/Webservice-Gateway/Default/conf/module.properties file
  • Once the backup has been saved, edit this file and perform the change as following:

Before:

com.watch4net.webservice.server.url=https://0.0.0.0:8443/

After:

com.watch4net.webservice.server.url=http://0.0.0.0:8080/
  • Restart the webservice-gateway service using : <DCF_Install_Dir>/bin/manage-modules.sh service restart webservice-gateway

On the AMPM domain which is to discover the ACI devices

Open the Polling & Thresholds settings for the AMPM Domain à Device Access Tab à DataCollector Access Group à DataCollector Access Setting

  • Set the AccessProtocol as HTTP
  • Set the PortNumber as 8080
  • Apply and Reconfigure the AMPM Domain

Polling&Threshold_DataCollector_Access_Setting_HTTP


Additional Information

Please subscribe to this article to be informed when updates are published.
 

Change Log:

  • 25-May-2022 - Added Polling & Threshold Reference Settings for change from HTTPS to HTTP

 


Powered by Wolken Software