0 - 7 of 7 tags for priority scheduler

Think about the priority part of workload management for a minute.

The settings that the administrator makes when defining priorities for different workloads are on the surface--things like workload allocation percentages and access level assignments.  They are easy to see.  Below the surface are “global weights”, which starting in Teradata Database 14.10 indicate to you the actual percentage of platform resources your workload will receive, based on its allocation.

But they do more than translate your settings to an expected resource share.  Global weights are used by the database to order the queues for several internal entities.  For example, the AMP worker task (AWT) message queue is now ordered by global weight in SLES 11. 

So it’s time you spent a few minutes taking a closer look at what global weights are, how the SLES 11 priority scheduler calculates them, and how you can influence them.

Hi,
Consider the following Priority Schedular settings.
Resource Parition     CPU Limit         RP-Weight        Allocation Group       AG-Weight
===========    =======       =======      ==========        =======
RP0                         100%              20                     AG01                         30

The SLES 11 priority scheduler implements priorities and assigns resources to workloads based on a tree structure.   The priority administrator defines workloads in Viewpoint Workload Designer and places the workloads on one of several different available levels in this hierarchy. On some levels the admin assigns an allocation percent to the workloads, on other levels not.

How does the administrator influence who gets what?  How does tier level and the presence of other workloads are on the same tier impact what resources are actually allocated?  What happens when some workloads are idle and others are not?

This posting gives you a simple explanation of how resources are shared in SLES 11 priority scheduler and what happens when one or more workloads are unable to consume what they have been allocated.

If you are using Teradata on one of the 1xxx or 2xxx platforms, be aware that query demotions are automatically built into your workload management scheme.   Because I’ve had a few questions about what these so-called "query milestones" are and how they actually work, I’d like to explain this functionality and discuss its trade-offs. 

If you are planning on using Priority Scheduler CPU limits to restrict the amount of CPU available to the system after a hardware upgrade, there are two questions you will need to answer up front.

A Teradata user can be associated with multiple Account Ids and even on login account ids can be provided, resulting in a Account String to be associated with the running session.

Maybe you want to ensure that your sandbox applications never use more than 2% of the total platform CPU. No problem! Put a CPU limit of 2% on them. Or maybe you’ve got some resource-intensive background work you want to ensure stays in the background. CPU limits are there for you.