CPU Hard Limits Metrics in ResUsage

The best minds from Teradata, our partners, and customers blog about relevant topics and features.
Teradata Employee

 Back in 14.10, some new fields related to Capacity on Demand (COD) and other types of hard limits were quietly added to ResUsage tables. You might be interested in these fields today, because they report how long queries were delayed due to hard limit enforcement. This can give you insights into whether a hard limit, like WM COD is ever being reached, and its actual impact on activity on the platform when it is reached.


This ResUsage information reports the impact of CPU throttling due to a hard limit, because that is the resource controlled by the operating system. "Throttling" in this case refers to the time in milliseconds that a TASM object stopped allocating CPU to active work under its control due to the hard limit percentage being reached.


Two ResUsage table display this throttling information: ResUsageSPS (the priority scheduler workload table) and ResUsageSPMA (the node table). Here are those fields as they appear in the SPS table, along with their definitions:



Each row reported in the SPS table represents one workload on one node for one logging interval. As you can see, the first two fields track virtual partition hard limit impact, by count and by time. The last two fields track workload level hard limit impact. The Time fields represent an accumulation of time across the logging interval where either the virtual partition or the workload itself prevented work from running due to enforcement of a hard limit.


  • The Count: The count is the number of times throttling is initiated within the logging interval. Throttling will occur at most once per hard limit enforcement interval and only when the defined hard limit percent is reached during an enforcement interval.
  • The Time: To total duration of throttling activity during the logging interval. During this throttling time any number of queries have been throttled. Individual query delay times are not accumulated in this metrics, only the time the workload, or the virtual partition, was actively throttling all of its work.


With current software, (any release before 16.20 Feature Update), only expect to see values in these fields if the corresponding hard limit type is enabled, and work running under the hard limit has reached the defined limit in usage.


For example, you will only get virtual throttle statistics if you have a defined a virtual partition limit and work running under the virtual partition is getting throttled. You only get CPUThrottle stats if you have a defined SLG Tier workload defined with a hard limit and work is running under that workload and is getting throttled.


Here is an example of ResUsageSPS table output illustrating those hard limit columns. This system had hard limits on both the workload and the virtual partition which that workload belonged to:




If you only have WM COD enabled on a system and no other hard limits, you will not get any of these statistics in the SPS table. Throttling is only reported in the SPS table for objects, such as workloads and virtual partitions, that have hard limits defined.


Consequently, if you have only WM COD has a hard limit and no virtual partition or workload hard limits, you will need to look at the ResUsage SPMA table. The SPMA table carries only one set of these CPU throttle fields, both related to WM COD.




If you are using hard limits at any level: WM COD, virtual partition, or workload, ResUsage tables can give you information about how frequently, and to what degree, work is being held back due to the presence of the hard limit. This can be helpful in making workload management evaluations and tuning decisions, and it can help you keep work on your platform running in a smooth and balanced way.