Understanding the Teradata priority scheduler and its role in resource allocation is essential for effectively managing and optimizing Teradata systems.
In Teradata systems, priority levels play a crucial role in managing system resources and ensuring the efficient execution of tasks. The priority hierarchy consists of different levels, each with its unique purpose and characteristics. In this article, we will explore the various levels of the Teradata priority hierarchy and their significance in workload management.
The priority hierarchy in Teradata consists of the following levels:
TDAT
User, System, Default
One or several virtual partitions (TIWM: always one)
A tactical workload tier (TIWM and TASM)
Between 0 and n SLG (Service Level Goal) workload tiers (TASM only)
One timeshare tier (TIWM and TASM)
At the top of the hierarchy, User, Default, and System levels follow TDAT. Teradata system tasks run on Default and System, while user-initiated tasks execute below the User level. Default and System tasks always satisfy their resource requirements before users receive resources, as they are responsible for executing critical system-related tasks.
The User level groups all tasks running on behalf of database users, excluding internal tasks. This separation ensures that critical system tasks receive adequate resources before user tasks, thereby maintaining system stability and performance.
System resources in Teradata Workload Management are allocated from the top of the hierarchy to the bottom. This simple yet effective approach follows the rule that the most critical workloads should be assigned to the top of the hierarchy while the least critical workloads are placed at the bottom.
Virtual Partitions, Tactical Workload Tiers, and SLG Workload Tiers
Below the User level, virtual partitions are used to manage resources among different workloads. Teradata Integrated Workload Management (TIWM) always has one virtual partition. However, in Teradata Active Workload Management (TASM), multiple (up to 10) virtual partitions can be defined.
Exploring Teradata Virtual Partitions
Teradata Virtual Partitions provide an efficient way to allocate system resources among various business units sharing a common Teradata system. This feature, available on Teradata systems running on SLES 11 or higher, is based on the concept of SLES11 priority hierarchies. In this article, we will delve into the concept of Teradata Virtual Partitions, their benefits, and how they function in workload management.
Virtual Partitions enable splitting the system resources at the highest level, allowing different business units to consume their allocated percentage of system resources independently. This feature is particularly useful in multi-tenant environments where multiple stakeholders share a single Teradata system.
It's important to note that the assigned share is not exclusively reserved for each virtual partition. If a virtual partition does not use all its assigned resources at a given time, other virtual partitions can take advantage of the available resources. This approach promotes efficient resource utilization across the system. Although it's possible to define a limit to prevent one virtual partition from using another's resources, this is generally not recommended, as it may hinder overall system efficiency.
While Teradata Integrated Workload Management (TIWM) does not support system splitting and implements exactly one virtual partition, Teradata Active Workload Management (TASM) allows this feature. To take advantage of Virtual Partitions, you will need to have TASM.
Assigning Workloads to Virtual Partitions
Each virtual partition can have several workloads assigned to it. By allocating workloads to specific virtual partitions, businesses can manage their resources independently, ensuring critical tasks receive the necessary resources while maintaining overall system performance. Each Virtual Partition has its priority hierarchy (Tactical Tier, SLG Tier, Timeshare Tier).
Teradata Virtual Partitions provide a robust solution for efficient resource allocation and management in shared Teradata systems.
Tactical Workload Tier
A tactical workload tier is designed for handling high-priority, short-running tasks. These tasks receive resources before lower-priority workloads to ensure timely execution.
Teradata Tactical Workload Tier is crucial in prioritizing tasks within the Teradata system. It offers several advantages, such as expedited and reserved AMP worker tasks, that help maintain optimal system performance.
The Tactical Workload Tier is located just below the virtual partition level in the Teradata priority hierarchy. Tasks assigned to this tier can consume as many resources as required, except for the 5% reserved for the "remaining" workload.
Tactical workloads can interrupt other tasks and take over the CPU quickly, while the interrupted tasks are resumed afterward.
However, assigning long-running and resource-intensive queries to tactical workloads could cut off workloads defined at lower hierarchy levels from resources. Therefore, assigning only "real" tactical requests, such as single-AMP or group-AMP operations, is essential to the tactical tier.
If recommended design approaches have been followed, most of the resources that flow into the tactical level will flow down to the below level. If you use TASM, the next level down will be SLG Tier 1. If you are using TIWM, it will be Timeshare.
Teradata has implemented a safety mechanism called Tactical Workload Exceptions to mitigate the risk of monopolizing resources by tactical workloads. This mechanism automatically transfers requests running on the tactical tier to a workload further down the hierarchy when a certain amount of CPU seconds have been consumed (adjustable).
Monitoring Tactical Workload Exceptions
It is crucial to monitor these exceptions regularly to identify requests that consistently cause exceptions. Such requests should be moved to lower workloads in the priority hierarchy to maintain optimal system performance and resource allocation.
The Teradata Tactical Workload Tier offers unique benefits that can significantly improve system performance and efficiency. By understanding its features and implementing best practices, organizations can harness the power of tactical workloads and avoid potential risks associated with resource allocation.
Regular monitoring of Tactical Workload Exceptions ensures that resources are allocated effectively, helping maintain optimal performance across the entire Teradata system.
The Service Level Goal Tier (SLG)
In TASM, SLG workload tiers can be defined, with each tier having specific performance objectives. SLG tiers help manage resources for different workloads and ensure they meet performance goals. Up to five SLG Tiers may be defined, although one, or maybe two, are likely to be adequate for most sites. Multiple workloads may be placed on each SLG Tier.
Teradata SLG tiers are vital in managing resources and maintaining efficient performance across the system. In this article, we will delve into the intricacies of the SLG tier in Teradata Workload Management with TASM and discuss its importance, functioning, and best practices for optimizing its use.
The Role of SLG Tiers in Teradata Workload Management
The SLG tiers are positioned below the tactical tier in Teradata Workload Management. Each SLG tier workload is assigned a relative weight, which determines the percentage of resources the workload can consume from the level above in the hierarchy. Additionally, the relative weight defines the top resource limit for the workload. An assigned allocation percent could provide more resources than a workload ever needs.
Unused resources allocated to one workload will be shared by the other user-defined workloads on that tier based on their percentages. What is offered to each is based on the ratio of their workload allocations.
Resource Allocation and Distribution in SLG Tiers
If not all workloads on an SLG tier can utilize their assigned resources, the remaining resources will be equally distributed among other workloads at the same SLG tier in need. Any leftover resources will be allocated to the "remaining" workload and passed down in the hierarchy.
In the below figure, at least 50% of the resources defined in the "remaining" workload will flow down to the SLG tier below tier 1, which could be another SLG level or the timeshare tier, depending on the system setup. If tier 1 cannot use 50% of its assigned resources (20% + 30%), all unused resources will be added to the 50% of the "remaining" workload.
Concurrency and Relative Weights
It is crucial to understand that relative weights allocate resources to workloads. For instance, if "Workload 1, Tier 1" can use up to 20% of the resources received by the previous tier, it does not imply 20% of the entire Teradata system's resources but the percentage of the resources that flow into the tier.
The active requests of a workload share the relative weight, which affects resource allocation for each task. If one query runs in workload 1 of SLG tier 1, it will consume all resources. But if 10 queries run in workload 1 of SLG tier 1, each query will only get 1/10 of the resources. Concurrency, therefore, has a huge impact in this case. But of course, unused resources from other workloads on tier 1 can be used additionally.
Relative weights are theoretical values representing the allocation of resources a workload would receive under the assumption that no tactical work is active, no work is running outside of the database, and all workloads are active and utilizing their entitled allocations. Such a scenario is improbable; relative weights are only abstract concepts. Nonetheless, they are a useful indicator of how resources will be physically distributed in your environment.
Best Practices for SLG Tiers
Limit the number of SLG tiers: Fewer SLG tiers ensure more stable runtime behavior for requests, as lower hierarchy levels depend on the resources "leftover" from higher levels.
The Teradata SLG Tier in Workload Management is pivotal in managing resources and ensuring system performance. Organizations can optimize resource allocation and maintain a high-performing Teradata system by understanding its functioning and implementing best practices.
Timeshare Tier
The timeshare tier is the lowest level in the priority hierarchy. Tasks within this tier share available resources based on their relative priority. This level is designed to handle workloads that do not require immediate resource allocation or have lower priority than tactical and SLG tiers.
The timeshare tier receives the remaining resources from the lowest SLG tier (or the tactical tier if using TIWM or not defining SLG tiers in TASM). Still, the priority scheduler ensures that a few resources always reach the timeshare tier.
Unlike the SLG tiers, the Timeshare tier implements a distinct resource allocation strategy for workloads defined as timeshare workloads.
The Timeshare tier has four resource allocation weights: Top, High, Medium, and Low. Fixed ratios are defined between these four levels, as opposed to the relative weights used in the SLG tiers:
Each request in a workload of group "Top" can consume eight times more than any request of a group "Low."
Each request in the group "High" workload can consume four times more than any request of the group "Low."
Each request in the group "Medium" workload can consume two times more than any request of the group "Low."
This rule is valid across all workloads defined on the Timeshare tier. While all requests of one workload on an SLG tier compete for the relative resources assigned to that workload, all timeshare requests of all defined workloads compete for the total resources entering the Timeshare tier.
If 5 queries run in Top, each will get 8 times the resource of a single query in Low. If there are 50 queries in Top, each will get 8 times the resource of a single query in Low. As each query in Timeshare Top will get 8 times the resource of any query running in Timeshare Low, it doesn't matter what the concurrency levels are: No matter how many queries are in Top Level, they will always run more efficiently than the queries in Low, and therefore it is recommended that you place workloads in Timeshare based on priority.
Here is an example of how resources are split in the timeshare tier for 4 High and 2 Low queries. The High Queries will always get more resources than the lower level queries:
4*4 + 2*1 = 18
Each High Query: 4/18 = 22,22% Each Low Query: 1/18 = 5,55%
Now we have 20 queries in the Top and 1 in Low, showing that even with a lot of High Queries still, Low Queries get fewer resources:20*4 + 1*1 = 81
Each High Query: 4/81 = 4,93% Each Low Query: 1/81 = 1,23%
There are two possibilities as soon as the remaining resources reach the Timeshare tier:
If the workload defined as timeshare consumes all remaining resources, 100% of the system resources are consumed and distributed.
If the timeshare workloads do not consume all remaining resources, they will be assigned to other workloads in need.
The backflow of resources to the lowest SLG tier from the timeshare tier will be offered to all active workloads on the tier, proportional to their allocations. However, this situation would only occur if Timeshare workloads could not consume the resources that flowed down to them.
All resources flow down to the base of the hierarchy first. Only if they cannot be used by the workloads at the base will they be available to other workloads to consume. Every resource is well-spent as long as someone can use it.
Understanding the Teradata priority levels and their role in workload management is essential for efficient resource allocation and task execution. By organizing tasks within the priority hierarchy, Teradata systems can ensure that critical tasks receive resources first and that user tasks are efficiently managed according to their priority and performance goals.
Differences in Priority Scheduler Hierarchies between TASM and TIWM
The figure below illustrates the differences between TASM and TIWM priority scheduler hierarchies, with the features only available in TASM highlighted in orange.
Understanding the differences between TASM and TIWM priority scheduler hierarchies is essential for making informed decisions about workload management in Teradata systems. TASM offers additional features, such as support for multiple virtual partitions and SLG workload tiers, making it a more advanced and flexible option for managing workloads and resource allocation.
Best Practices for Resource Allocation
In Teradata workload management, best practices for resource allocation involve strategically assigning workloads to various tiers and access levels. For tactical workloads, prioritize highly-tuned queries with low service level expectations and avoid assigning load utilities. Demote non-tactical queries when necessary and ensure adequate resource allocation for tactical workloads. For SLG tiers, assign high-priority workloads with response time expectations but avoid overloading SLG Tier 1 with non-tactical queries. Consider sibling sharing of unused resources for workloads with differing peak time windows.
For Timeshare workloads, allocate most platform resources to the appropriate access levels and prioritize high-priority non-tactical workloads in the Timeshare Top access level if SLG tiers are not used. Place low-priority workloads in Timeshare Low and maintain minimal concurrency.
Consider that the same query might perform better in the timeshare tier than in the SLG tier one level above. Here is an example: You assign 20% to the only workload in the SLG tier, which means 80% of the resources flow into the timeshare tier. Assuming no other workload is active, the query will perform 4 times faster in the timeshare tier than in the SLG tier. However, it is being executed lower in the hierarchy. To avoid such situations, you can classify most queries into the timeshare tier (increasing its concurrency level).