This content is only relevant to systems using the SLES 10 priority scheduler.
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. But if you plan to use CPU limits as part of your workload management scheme, be aware that there are some database operations that simply won’t obey the limits. So let’s take a look at what those special cases are and why they’re allowed to violate the rules.
What is a CPU Limit?
CPU limits are an option within Priority Scheduler that limit how much CPU a given group of users can consume at any point in time. At the most granular level, CPU limits can be added to a Priority Scheduler Allocation Group. For a broader scope they can be applied to Resource Partitions. And under some conditions, such as after a hardware upgrade, a CPU limit may be applied to the entire system. The DBA controls where, when, and if, to use them. And they are easily changeable, day and night, for example.
A CPU limit does not hold back resources ahead of time for the work that falls under the control of the limit. It simply dictates how much CPU can be consumed by work running under its control at any point in time. If consumption should ever reach that level, Priority Scheduler slows down access to CPU for that work. It’s a ceiling, but it works like a thermostat. Only when resource usage indicates that the CPU limit has been exceeded will the limit cause Priority Scheduler to hold back CPU temporarily for the group.
This means that if the group under the control of a CPU limit is not consuming up to that limit, that group will not notice any slow down or have less CPU available for their processing.
Which Database Operations Ignore CPU Limits?
There are several types of operations within the database that do not honor CPU limits. This non-compliant behavior towards CPU limits is by intent, not by oversight. It’s how the database was designed to work. It’s a good thing.
1. The System Performance Group
The best example of a type of work that will not honor CPU limits is the work that is running in what is referred to as the System Performance Group (PG). The System PG is home to a special collection of very-high priority internal DBS operations that have been deemed important enough to always run at the highest possible priority on the platform. You can’t change the fixed priority of the System PG, neither can you place a CPU limit on it’s allocation group.
Because you cannot place a CPU limit on the System PG individually, work in the System PG not honoring CPU limits is only relevant if a CPU limit has been applied on the entire system. Generally, the System PG uses a small percentage of the total CPU, usually in the low/middle single digits. Anyone who monitors CPU usage either through schmon –m, Teradata Manager services, or ResUsageSPS can see what percent of CPU is being used by the System PG.
The critical database operations that run in the System PG include many short things such as dispatching, dictionary cache management, and error logging. At the other end of the scale, one type of work usually running in the System PG that can use a large amount of CPU is rollbacks and abort processing.
Rollbacks can run in the System PG, or at the user’s priority. It is important to note that rollbacks and abort processing will not honor a CPU limit, if one exists, no matter where they are executing. By default, rollbacks run in the System PG and would be immune to CPU limits along with the other work running at that special priority.
But when the DBS Control parameter RollbackPriority is changed from FALSE to TRUE, this forces rollbacks to run at the priority or the user who submitted the request which is now rolling back. And if that user’s Allocation Group includes a CPU limit, that CPU limit will be ignored by the rollback processing.
The thing to remember here is that when the rollback is running at user priority it will be allocated CPU at a lower priority, so it will likely get CPU less quickly than when it ran at the System PG. That is the advantage of changing the DBS Control setting to TRUE. However, even though the rollback will run slower, at the same time it will be able to violate a CPU limit, if one exists, as it runs to completion.
3. Other Cases
In the Teradata Database, some DBS work is deemed too important too interrupt, and needs to complete quickly once it begins. This category of operations that ignore CPU limits includes:
• Deadlock detection routines
• CHECK TABLE
• TABLE REBUILD
• Parts of an ALTER TABLE
ALTER TABLE may be issued more frequently than the other utilities mentioned above, because of the desire change the partitioning of a PPI table, or to add or change compression. For that reason, ALTER TABLE is of particular interest in this discussion.
ALTER TABLE is a data definition command that changes the underlying structure of a base table. Some of the work done by an ALTER TABLE will honor CPU limits, but a portion of the activity of an ALTER TABLE falls into the category of being too important to interrupt. The following graphic illustrates the CPU usage during the life of an ALTER TABLE command that is adding compression to an already-loaded table. In this example, the CPU limit that had been set was exceeded by the ALTER TABLE activity.
CPU limits provide an opportunity to manage the CPU consumption of specific groups of users. CPU limits are not for everyone. They have a very focused and specialized purpose, and need to be monitored regularly if they are used.
Understanding the cases where the CPU limit will be ignored is useful if you are thinking about applying CPU limits. As with any workload management option, it’s always a good idea to monitor the work under the control of any CPU limits that you have defined. And remember to use CPU limits selectively, as it is possible that some of the platform CPU may be wasted as a result.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.