Network Management

High CPU and memory usage by Job Engine (SWJobEngineSvc2) after upgrading to SolarWinds Platform 2025.1

This article provides information about an issue where SWJobEngineSvc2 and Job Engine Worker processes consume excessive CPU and memory after upgrading to SolarWinds Platform 2025.1. This can lead to system instability, polling failures, data gaps, and missed alerts.

First published date

3/12/2025 4:54 PM

Last published date

3/20/2025 6:50 PM

Overview

After upgrading to SolarWinds Platform 2025.1, you may experience the following:

  • SWJobEngineSvc2 and SWIS services consume excessive CPU and memory, leading to system crashes.
  • On restarting services, the issue of high CPU usage temporarily resolves but occurs again.
  • Polling completion is less than 100%.
  • SolarWinds services, particularly RabbitMQ and collector services, intermittently stop, causing data gaps and missed alerts.

The issue occurs randomly, typically within 5 to 9 hours after restarting the SolarWinds services. Logs indicate that Job Engine processes are spawning new SNMP jobs before previous jobs complete, resulting in thousands of threads accumulating, ultimately causing the Job Engine to become unresponsive.

This issue is closely related to the introduction of in-process workers. Unlike traditional worker processes that run jobs separately, in-process workers execute jobs directly within the Job Engine process. While this can improve efficiency in some cases, it also increases resource contention, making the system more susceptible to high CPU and memory usage when too many jobs are running simultaneously.

Product section

Network Performance Monitor

Cause

  • The introduction of in-process workers, executing jobs directly within the Job Engine process rather than in separate worker processes can contribute to high CPU and memory usage.
  • Additionally, specific SNMPv3 authentication and encryption settings (MD5 AES192, MD5 AES256, SHA1 AES192, and SHA1 AES256) may trigger the problem when polling times out.

Resolution

Recommended Resolution: Upgrade to 2025.1.1

A permanent fix for this issue has been implemented in SolarWinds Platform 2025.1.1. The service release is now available for download in the Customer Portal.

We highly recommend upgrading to 2025.1.1 to resolve this issue.

Alternative Workarounds

Important

The workaround explained in this article is applicable only if you are on SolarWinds 2025.1. If you are on an older version, then this does not apply to you.

 

If an immediate upgrade is not possible, apply the following workarounds sequentially:

Primary Workaround: Disable In-Process Workers to reduce load on the Job engine causing CPU load 

  1. Stop all SolarWinds Platform services.
  2. Navigate to C:\Program Files\SolarWinds\Orion\.
  3. Create a backup of the Job Engine configuration file SWJobEngineSvc2.exe.config outside the installation directory (e.g., Desktop or another folder outside C:\Program Files\SolarWinds\).
  4. Open the Job Engine configuration file SWJobEngineSvc2.exe.config.
  5. Search the file for “<jobEngineSettings_Full” and add to the end of the line:  inProcessWorkersEnabled="false"

Example:

<jobEngineSettings_Full maxWorkerProcess="20" maxJobThreadsPerWorkerProcess="100" maxJobThreadsPerWorkerProcess64="500" jobExecutionRetention="01:00:00" jobExecutionEnabled="false" thresholdStreamByteThreshold="131072" maxWorkerProcessLogFileAge="5.00:00:00" maxHungJobs="1" jobHungTimeout="00:00:30" workerMonitoringPeriod="00:00:01.0000000" jobErrorSuppressionInterval="01:00:00" jobErrorSuppressionCleanupInterval="00:05:00" enableSqliteSelfRepairLogic="true" inProcessWorkersEnabled="false">

 

  1. Save the file and restart all SolarWinds Platform services.

 

If the issue persists, try the steps below.

 

Secondary Workaround: Adjust SNMP v3 Settings to switch to SNMP v2 which does not use encryption

  1. Identify nodes using SNMP v3 with the following authentication/encryption combinations:
    • MD5 AES192
    • MD5 AES256
    • SHA1 AES192
    • SHA1 AES256
  2. Change affected nodes to use different authentication/encryption combinations or switch to SNMP v2.
  3. Ensure that no nodes retain the problematic configurations, as even a single node can trigger the issue.

 

Note:

If you are still encountering issues, please open a support case for further assistance.