Archives of the TeradataForum
Message Posted: Fri, 25 Apr 2003 @ 13:03:43 GMT
I think Priority Scheduler could help you out here.
One option is to set milestone limits based on usage. In V2R5, milestone limits are at the Query level, which is probably what you really want. However, here is a possible V2R4 solution.
Let's say all of your queries run in Medium priority using the DEFault policy. You could create another performance group, called HOTAMP, that has an ABSolute policy. When a hot AMP query occurs, you could move the query to the NOTAMP performance group. What would happen is that the offending query would be limited by the amount of CPU specified in allocation group associated with the HOTAMP performance group. The affect would be that the offending query's impact on the rest of the system would be minimized. Of course, the query would take a lot longer to finish than otherwise and it would hold on to its system resources during the entire query step across all of the AMPs (i.e. spool, AWTs, etc.), but it would allow other, more well behaved queries to get more access to CPU cycles.
With V2R5, the query level milestone limits give you a little more flexibility because you can let a query initially run at a "normal" priority and then have the priority change (perhaps using an ABS allocation group) after the query reaches a CPU threshold limit. Interestingly, PSF works at the node level, not the system level. That means that, for a 10 node system, you are really running 10 independent PSF processes. The result is that the hot AMP query would reach it's milestone limit on one node while still running in "normal" priority on the other nodes. The other implication is that, once the query reaches the milestone limit on one node, the entire query is affected for the remainder of execution.
Having said all that, I think you can achieve just about any desired result you want using a combination of Priority Scheduler and a custom written PM/API program. Just a SMOP (Small Matter of Programming!)
Hope this helps!
Thomas F. Stanek
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|