KBI 310332 High CPU/Resource Usage In Argent AT


Argent AT — All Versions


7 Jan 2013


This article describes how to fine-tune Argent AT when monitoring causes high CPU or resource spikes for prolonged periods of time

Similar symptoms may include slowdown or delays of tasks (e.g. alerting)

Customers may also see numerous (30+) Argent monitoring processes at any given time, which may result in the overconsumption of non-interactive desktop heap

Technical Background

Argent AT provides two methods of executing tasks — this is configured on a per-Relator basis.

A new process can be spawned for each task, or a shared process can be used when executing the task.

In Argent AT, there are implications to consider when using either method:

Spawn New Monitor Engine Process

For each task, a new process is spawned. This allows tasks to execute independently, and in some cases concurrency e.g. (in parallel — such as vCenter, which only allows one connection per process)

However, this also increases the resource usage of creating new processes, and creating new initial connections to a remote server or application

Use Shared Monitor Engine Process Pool

For each task, a shared process pool is re-used. This re-uses open connections to the remote server which significantly reduces the load.

Less processes are spawned, but if a particular task fails and crashes the process, it affects other tasks as well.

Argent AT assigns three shared process pools by default. You can specify the exact process pool to use (Pool #1, Pool #2, Pool #3), or you can use the {Dynamic} option, which dynamically allocates the task to the next freed up Pool.

In other words, under the default settings, and when {Dynamic} is used with shared process pools – up to three simultaneous tasks can be executed at one time – the rest will be queued.


Changing to Use Shared Monitor Engine Process In Pool will always significantly save on resources.

If the default of three process pools is not enough, you can increase the total number of shared process pools by going to Administration, Supervising Engine, and changing the Shared Monitor Engine Process Pool Size.

Example: From 3 to 15.

This simply means that a maximum of 15 shared process pools will be spawned instead of the default of 3

After making this change, you can see that this has taken effect by going back to your Relator.

You’ll see the number of Pools have increased to what you specified: