Oshi cause permanent WMI requests from XAP processes that are leading to a high CPU consumption
Description
All XAP processes (GSA, GSC, GSM) are permanently querying (every 10 sec) themselves over the local WMI interface to gather their own command line parameters.
As we spawn 20 XAP processes per VM, these general inefficient WMI requests are causing quite some stress to the CPU > resulting in 2 WMI requests / second.
Reproduction:
Enable WMI trace logging (see https://docs.microsoft.com/en-us/windows/win32/wmisdk/tracing-wmi-activity)
Spawn a GSA
Wait for ~30 seconds after GSA has spawned
Disable WMI trace logging, filter for event Id 11 and check event log entries
The following WMI request is originating from the GSA (processID 10256), querying his own cmd line parameters every 10 seconds:
Workaround
Acceptance Test
Verified manually
Activity
Solution:
The problematic call is in OshiJVMStatisticsProbe.java in line 60:
The method "getProcess()" reads all possible values of the process from differents sources, including the comand line via WMI. This information is not used in the XAP code base.
With OSHI lib 4.2.0 there is an option to "skip slow fields" during this process, by setting the "slowField" parameter of "getProcess()" to "false". This gets rid of all WMI and Windows security calls, and makes the calls a lot faster.
In OshiGaugeUtils.java is a second usage of the affected getProcess() method call.
We patched for now the xap-common and xap-datagrid versions ourselve. Please include this fix, or an upgrade to the improved API of OSHI 5.x.x in the upcoming releases.
Attached the full patch we are currently working with.
FRQ can’t upgrade to 15.5.1. Can we backport the fix (upgrade Oshi to 5.2.5) to 15.0? Karl is asking for that.
