8 tags for Workload management

 

Last month I talked about things that don’t honor a CPU limit, and explained what a CPU limit is. This month I’d like to look at CPU limits from a slightly different perspective—What happens when you define CPU limits at multiple levels? For example, you may already have a system level CPU limit on your platform, but now you’d like to use CPU limits on one or two of your resource partitions (RP) as well. Yes, you can do this. Read along with me while I explain to you what you can expect.

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.

Teradata is very pleased to announce the official release of Teradata Viewpoint 13.02 effective January 8th, 2010!

Here are some details regarding this very exciting release. This is the first release of Teradata Active System Management (TASM) portlets, specifically the Workload Health and Workload Monitor portlets. These portlets provide TASM management, monitoring, and reporting functionality that was previously only offered through a TASM screen in Teradata Manager. See below for more information on these new TASM portlets.

2 0

We all know the benefits of identifying and fixing badly performing workloads. Many sites use the common method of identifying the top n highest consuming or skewed queries (often the same queries) and fixing those.

10 15

Chances are that if you’re into workload management at all, your using at least one throttle. Maybe you are using more. On the other hand, maybe you’re just thinking about it. Object Throttles (as opposed to Workload Throttles) allow you stray from the straight and narrow, because they offer you an array of options and can be used creative combinations. This makes it possible for you to get in over your head when your throttles overlap or conflict. If you are not able to keep your throttles simple, this article is intended to preview what are getting yourself into.

The question of what Estimated Processing Time actually is comes up a lot. For example, the DBQLogTbl table carries an “EstProcTime” Value. If you are EXPLAIN-savy, then you’ve bumped up against “Estimated Time” numbers in almost every step of every query plan you’ve ever looked at. You TASM users frequently rely on “Estimated Processing Time” as a classification criteria to manage the priority that a query will enjoy. Some think Estimated Processing Time is an estimate of clock seconds, and others believe it represents CPU seconds.

I was asked recently about how much memory is used by each request that is held in the delay queue used by throttles. What I dug up is a little “thing of interest,” a small efficiency built into the Teradata database. I like discovering small efficiencies. Small efficiencies, like pennies, may be miniscule in and of themselves, but they can and do add up to larger savings, particularly as a system grows and stretches its muscle.

Yeah, I know. All you need is another “thing to remember to do” following your upcoming hardware upgrade. As if your “must do” list wasn’t long enough already.

Well, consider what I’m giving you as a “soft” list…Its a few things worth checking after an upgrade, but the sky won’t fall in if you don’t get to it right way. So relax, take a deep breath, and ponder my post-expansion soft to-do list at your leisure.