Engine Utilization (Tick %)

Reports the percentage of time the Adaptive Server kernel is busy executing tasks on each Adaptive Server engine (rather than time spent idle) using an internal measurement (the “ticks”). The output is grouped according to thread pools. ” Server Summary” shows the total time for all pools.

“Engine Utilization (Tick %)” can help you decide whether there are too many or too few Adaptive Server engines.

The values reported on the “Engine Utilization (Tick %)” report may differ from the CPU usage values reported by operating system tools. When Adaptive Server has no tasks to process, it enters a loop, looking for work before going to sleep. The alter thread pool ... idle timeout parameter controls the amount of time, in microseconds, Adaptive Server engines spend looping as they look for a runnable task before yielding the CPU.

To reduce the time that Adaptive Server spends checking for runnable tasks, lower the value for the idle timeout thread pool parameter. However, decreasing the value for idle timeout can increase latency, decreasing performance.

When sp_sysmon samples the counters (by default, every 100 milliseconds), each engine indicates what it is currently doing. sp_sysmon reports how busy engines are, distinguishing between user and system tasks:

For example, if executing a task, the engine reports "CPU Busy"; or, if idling, the engine reports "Idle". Engines are counted as "I/O Busy" if Adaptive Server has any I/O outstanding and the engine is idle. If there is one I/O outstanding and three engines sitting idle, each engine is counted as "I/O Busy".

By checking sp_sysmon output for problems and tuning to alleviate contention, response time can remain high even when the engines report they are busy 80 to 90% of the time. If values are consistently very high (more than 90%), it is likely that response time and throughput could benefit from an additional engine.

The “Engine Utilization (Tick %)” values are averaged over the sample interval, so very high averages indicate that engines may be 100% busy during part of the interval. If the server experiences high CPU utilization, check for spinlock contention. In-memory table scans also increase CPU usage, which you can decrease by tuning queries appropriately.

When engine utilization is extremely high, the housekeeper wash task writes few or no pages to disk (since it runs only during idle CPU cycles.) This means that a checkpoint finds many pages that need to be written to disk, and the checkpoint process, a large batch job, or a database dump is likely to send CPU usage to 100% for a period of time, causing a perceptible decrease in response time.

If “Engine Utilization (Tick %)” percentages are consistently high, and you want to improve response time and throughput by adding Adaptive Server engines, check for increased resource contention in other areas after adding each engine.

In an environment where Adaptive Server is serving a large number of users, performance is usually fairly evenly distributed across engines. However, when there are more engines than tasks, you may see some engines with a large percentage of utilization, and other engines may be idle.

For example:

Engine Utilization (Tick %)      User Busy   System Busy    I/O Busy     Idle
   -------------------------  ------------  ------------  ----------  -------
   ThreadPool : Marketing_pool
    Engine 3                        78.0 %         4.5 %       3.4 %   18.0 %

   ThreadPool : syb_default_pool
    Engine 0                         8.7 %          .8 %       1.3 %   94.8 %
    Engine 1                        87.0 %         5.2 %       3.5 %   19.4 %
    Engine 2                        65.7 %         3.7 %       3.7 %   12.8 %

In an SMP environment, tasks have soft affinity to engines. Without other activity (such as lock contention) that might place a task in the global run queue, the task continues to run on the same engine.