Archives of the TeradataForum

Message Posted: Thu, 21 May 2015 @ 20:51:23 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Sridhar,

As you've said, you have fewer options on an Appliance than you do with full TASM on an EDW platform, but there are still some options you have.

But I'm curious, why do you want to limit them to 50% of the CPU? Is there a business need? (ie dev and qual only paid for x% of the box) or are you just concerned with DEV 'using up all the resources'.

Assuming it's the latter:

1) CPU can't be saved or stored up - why not let low priority work run when there is no higher priority work demand on the platform

2) trust that the fair share scheduler works. Higher priority work will be offered resources ahead of this 'low' priority work. Remember that resources within timeshare are given in a 8:4:2:1 ratio. Every TOP request gets offered 8 times the resources of LOW, High gets offered 4 times that of LOW and MEDIUM gets offered 2 times that of LOW

3) you do need to limit the amount of concurrent LOW work you allow to run through throttle. This needs to be done for 2 reasons:

3.1) You don't want to consume too many of your AWTs (and potentially exhaust AWTS) with low priority work

3.2) The nature of how the ratio works, remember that every HIGH gets offered 4x the resources of what every LOW gets, if there are 10 LOW running and only 1 HIGH, cummulatively, LOW would be offered more system resources (if that is a concern to you)

4) because you're on an appliance, you don't have the option of exceptions (to abort over-consumers for example). You could develop your own process that polls every x minutes and would issue an abort query for any LOW work that had consumsed more than a preset amount of CPU.

Ruth

	<Prev	Next>		<<First	<Prev	Next>	Last>>