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.


Hi Carrie,



Suppose if i have 4 Workloads with 1% each in SLG TIER-1 so that means at the backend each Workload will get 2-3% each so that total allocation sums up to 10%? If the original combination of allocation in SLG tier goes above 10% then it is fine? Is it valid for SLG TIER-1 or across all Tiers?

Teradata Employee

You are correct. The total minimum allocation made to any SLG Tier is 10% of the resources that flow into the tier from the tier above. If that minimum results in more resources being allocated to an SLG Tier, additional resource will be shared proportionately among all active workloads on the tier based on their allocation percent.  If you have 10 WDs defined on SLG Tier 1 but only one is active, that WD will be offered at a minimum 10% of the resources that flow into the tier.  This is true for all SLG Tiers.  However, that 10% minimum amount may be quite a bit less on a lower SLG Tier than a higher SLG Tier, because it is based on the resource that comes from the tier above, rather than being based on 100% of the system resource. 


Thanks, -Carrie


Thanks Carrie.


Is this also true when resources flow Upward, suppose if i have a seperate Virtual Partition worth of 10% and my penalty box workload sitting in SLG TIER 1 with 2% allocation and only demoted Queries get into that workload and there are other workloads with direct classification in Timeshare which are already active and occupying close to 9% of VP, still these SLG workload will get 10% default by preempting already active ones??


Or the above scenario will be valid for One CPU cycle and from next CPU cycle it will be like SLG Tier-1 getting 10% of total share and so on and so forth??





Thanks Carrie for this Blog !!


My question is for penalty workload.

As mentioned in blog that the hard limit will take precedence over the allocation percent, If we define penalty Workload ( Let say 1 %) with hard limit in SLG Tier 1 then It will not take more then defined 1% but in conclusion you said that "This makes SLG Tier workloads less reliable as a penalty box today."

If we can limit the allocation with hard limit then putting Penalty WD in SLG Tier 1 should be ok as it will not take 10 % even this is only workload active in SLG Tier.  So having hard limit on workload still making it as less reliable ?





Teradata Employee



The 10% allocation to an SLG Tier that I mentioned as the minimum allocation is 10% of what is flowing into that tier, not an absolute 10% of all available resources. So if you had a VP with a 10% allocation, SLG Tier 1 would at a minimum get 1% of the total platform resources, not 10%.   If penalty box WD has a 2% allocation and it is the only thing running on that SLG Tier, it could get 1% of the total resources if you had a VP with 10% allocation.


In that case work running within VP2 that are using 9% would still get their 9% if they can use it, so there would be no preemption required.


The operating system recalculates what it gives to each workload and each task in real time. As soon as a higher priority piece of work enters the system, it will be given the resources it is entitled to. There is no delay involved. This is described in more detail in the Priority Scheduler orange book Chapter 2 in the section titled “Deciding Which Task Gets CPU Next”.


Thanks, -Carrie

Teradata Employee



You are correct that a hard limit will always take precedence over how the operating system would naturally allocation resources. My comment about SLG Tier workloads being less reliable as a penalty box due to the 10% minimum allocation given to an SLG Tier assumed that no hard limits were involved.  


Hard limits, at whatever percent you set them are enforced accurately by the SLES 11 priority scheduler.  However, placing a hard limit in the low single-digit percentages is not a recommended practice today. In some cases such a hard limit may be acceptable, but in-house testing has shown that very low WD hard limits come with a risk of impacting other active work running at the same time.  


Thanks, -Carrie


Thanks Carrie !


Also the same allocation rules remain vaild if Resource flow from bottom to top i.e. 90 % with Timeshare & 10 % with SLG ?