TASM SLG Tier 10% - 90% Allocation Rules

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

On the Enterprise platforms, Teradata Active System Management (TASM) workload management offers a priority level called the SLG Tier, composed of five levels. Workloads that have a service level goal (SLG) or that are special for some reason can be placed in one of the SLG Tiers.  Workloads in the SLG Tier get access to resources ahead of workload placed in Timeshare, which is lower in the priority hierarchy.


Workloads assigned to SLG Tiers have a richer set of workload options and require different setup techniques than workloads placed on other levels of the priority hierarchy, such as Timeshare. This posting describes a not-well-understood characteristic of SLG Tiers that limit the maximum and minimum resource allocations that workloads on such a tier will receive.


Upper Limit on Combined SLG Tier Allocations

Based on Linux SLES 11 operating system priority structure, the Teradata priority scheduler uses a tiered approach to priority definitions that user queries utilize. Workloads, that represent different categories of work, are placed on different levels in this hierarchy, using already-established "tiers". The higher priority work is placed higher in the priority hierarchy, and the lower priority work lower in the hierarchy.


One of the differences with workloads assigned to one of the five SLG Tiers is that they must be given an allocation percent. That allocation percent represents the percent of resources that will be offered to the workload from among the resources that flow into that tier from the tier above.


If you have more than one workload on an SLG Tier, the combination of the individual allocations is not allowed to exceed 90%. That upper limit ensures that a given SLG Tier will only be able to consume up to 90% of the resources that flow into that tier from above it in the priority hierarchy. At least 10% of resources to flow into an SLG tier will flow to the tiers below. That way workloads in the lower tiers will never starve. If you have only a single workload on an SLG Tier, it will not be allowed to have an allocation greater than 90%. This is enforced by the Viewpoint Workload Designer portlet.


Lower Limit on Combined SLG Tier Allocations

In addition to an upper limit of 90%, combined allocations of all the workloads on an SLG Tier also come with a lower limit. Combined workloads on an SLG Tier will always be allocated at least 10% of the resources that flow into the tier.


Workload Designer does not enforce or even represent this lower limit, but it is supported by priority scheduler behind the scenes. For example, if you have two workloads on SLG Tier 1 with an allocation of 2% and 3% respectively, Workload Designer will register them as having allocations of 2% and 3%, as you might expect. But at run time those workload allocations will be converted to 4% and 6% automatically, to ensure that a minimum of 10% of the resources that flow into that tier will be allocated to workloads assigned there. Those workloads with low allocations may not be able to consume that additional level of resources, but it is made available to them, and if they can use it, they will be allowed to.


If there is only a single workload on SLG Tier 1 with an allocation of 1%, to take another example, that workload will (behind the scenes) be offered 10% of the resources that flow into that tier. In an earlier blog posting I suggested that SLG Tier 1 is a reasonable place to add a penalty box workload with a low allocation percent, as a place to contain very high-consuming queries. That may be a less than satisfactory suggestion unless there are several other workloads on the same SLG Tier, where the allocations in combination equal or exceed 10%. If only a single 1% workload exists on SLG Tier 1, or the other workloads are idle, you should assume the 1% workload will be allowed to consume up to 10% of resources that flow into SLG Tier 1.


So far, we have been talking about penalty boxes based solely on workload allocations. Regardless of what the allocation percent given to a workload is, a workload can also be restricted by means of a hard limit. With a hard limit defined at 2%, even if the workload is being allocated 10% it will be capped at 2% of the platform resources. The hard limit will take precedence over the allocation percent. Only SQL Tier workloads have the option of carrying a hard limit.


In Teradata Database 16.20 there will be enhancement to how hard limits are enforced, which will take any uncertainty involved with setting a very low hard limit. I will be posting information on that enhancement at a later date, describing how it will allow you to use SLG Tier workload hard limits more effectively and creatively for penalty boxes or other types of workloads.   



SLG Tier workloads allow you to set allocation percentages, as a method of directing resources away from the less important work, and to the more important work. Workloads placed on an SLG Tier have, in combination, an upper and a lower limit on their combined allocations.


Workloads placed on an SLG Tier cannot have a combined allocation that exceeds 90%. And while the workloads on an SLG Tier can be defined with a combined allocation that is less than 10%, priority scheduler will always allocate at least 10% to all workloads on an SLG Tier when they are active. This makes SLG Tier workloads less reliable as a penalty box today.