Archives of the TeradataForum
Message Posted: Wed, 08 Nov 2000 @ 20:42:56 GMT
I'm not sure what you mean by the consumption threshhold. If you are referring to the milestone limit which allows you to change the allocation group associated with a performance group based on CPU usage, we have not used that here. However, I'm not really sure taht's what you want to do.
Based on your other email, it sounded more like you wanted to modify the Priority Scheduler scheme based on the time of day. For example, from 6 AM to 6 PM, users get the majority of system resources and batch is limited. From 6 PM to 6 AM, the reverse would be true. In order to accomplish this, you probably need three Resource Partitions; One for Default (system) work, one for user work, and one for batch work. The reason is that the Default partition is where system work is performed and it should always have the highest weighting of any work on the system.
From there, you would probably want to redefine the Priority Scheduler scheme twice a day to switch back and forth between weighting user performance groups higher or weighing batch performance groups higher.
Another alternative would be to put users and batch in the same partition and simply assign them to different performance groups within the partition. However, this limits the level of differentiation you can make between types of users or types of batch.
In order to truely constrain batch processing during the day or user processing at night, you should strongly consider the use of the relative policy, or possibly the absolute policy. These very effectively limit cpu usage. However, there is also the possibility of idle (wasted) CPU in this scenario, so you need to think through how you are going to configure your Priority Scheduler schemes.
The most important thing you need to determine your workloads and decide how you want the workloads to behave during a given processing window. In most cases, Priority Scheduler will help you make the system behave the way you want.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|