Reserving AMP worker tasks (AWT) for tactical applications is a technique to protect business-critical, short queries, when the platform is experiencing AMP worker task exhaustion. If you are thinking about reserving AWTs, there are two different settings for which you will be required to provide values. This posting discusses what these two settings are and how to be smart about setting them.
By default, each AMP has 80 AMP worker tasks (AWT) to service all work messages that arrive on the AMP. If the system is very busy, all the AWTs could be in use at the time a new message that requires an AWT arrives. In that case, the message waits in a message queue until an AWT frees up. Usually this is a short delay, but even a short delay can be costly for a tactical query, when the response time expectation is 1 or 2 seconds or less.
For that reason, there is an option for tactical workloads that allows you to set up a special reserve pool of AWTs exclusively for tactical queries. In order to take advantage of the new reserved pool, the workload or the allocation group must have been flagged as expedited by the administrator. If you are using TASM, then the expedited status is automatically given to a workload that has a tactical enforcement priority. Once a workload has been marked as expedited, all queries that run under its control will use a different, higher message work type and can draw AWTs from the new reserved pools, if a reserve count greater than zero has been specified.
Notice I said “reserved pools” above, as there is more than one reserved pool set up as a result of your selecting a reserve count greater than zero.
Some short background. Reserve pools of AWTS are defined for specific work types. Eight work types automatically have their own reserve pools built at system startup. For example, all new, user-initiated work messages (representing query steps coming from the dispatcher) are categorized as MsgWorkNew (aka MsgWork00) work type. MsgWorkNew has its own reserve pool of 3.
When you select a number greater than zero at the Reserved AWT prompt, that becomes the number of AWTs that will be moved into the first two of the three new reserve pools that support expedited queries. The first pool, for MsgWorkEight work type messages, accommodates new messages coming from the dispatcher for all expedited queries. It is equivalent to MsgWorkNew which is the work type used by non-expedited new messages. The second pool, for MsgWorkNine work type messages, accommodates spawned work from MsgWorkEight AWTs. Both MsgWorkEight and MsgWorkNine are the same size, reflecting whatever reserved count you specified.
The third pool, for MsgWorkTen work type message, is not used very often, and is intended for spawned-spawned expedited work messages. MsgWorkTen reserves are always kept at two AWTs, no matter how high the reserve count you select.
There are two settings to be aware of when it comes to reserving AWTs. If you are using TASM, you will see two prompts at the bottom of the Priority Distribution Screen that apply to reserving AWTs. They follow the “System Values” heading and the "CPU limit" prompt. They look like this:
The first parameter, Reserved AWTs, is the number of AMP worker tasks that will be placed in the new reserve pools for MsgWorkEight and MsgWorkNine.
The second parameter involved in reserving AWTs is called either AWT Limit or Max Expedited AWTs (in more current releases). What it represents is the maximum number of messages that will be allowed to get a MsgWorkEight type of AWT at any point in time. If you set AWT Limit to 50, then if you were to have 50 expedited messages representing new work from the dispatcher that are running in MsgWorkEight, then the 51st such message would be placed in the delay queue. That setting is an upper limit of how many messages of the MsgWorkEight work type are allowed to run concurrently. It acts sort of like a throttle for new expedited messages.
AWT Limit (or Max Expedited AWTs) enforces identical functionality to what has always existed in MsgWorkNew, the more standard work type for new work, which has a hard limit of 50 on how many messages it can run. This limit ensures that not too many new work messages get started, because if they all need to spawn work at some point, if there are more than 50 there would be inadequate AWTs available for the spawned work. (Technically 3 AWTs would always be available because MsgWorkNew has its own reserve pool of 3, but that would be inadequate to service 50 new messages, all with spawned work.)
In point of fact, you can only specify a reserve count of 20 AWTs, so you will run out of reserved AWTs before you will hit the default limit of 50 concurrent active messages on MsgWorkEight AWTs. However, expedited queries will not necessarily be delayed if you run out of reserves. If you do exceed your reserve count, the 21st MsgWorkEight message would have to try to get an AWT from the unreserved pool, if any are available there, since all the AWTs in the special reserve pool had been taken. The unassigned pool is able to service any type of work request, even if queries running in that work type have exceeded its reserve count.
The reserve pools are intended to service tactical work only. Usually this is small portion of the overall work running on a Teradata system. In order to understand how many AWTs will be supporting the new reserves, when you select a reserve count, double that number (for MsgWorkEight and MsgWorkNine pools) then add 2 (for MsgWorkTen). That is the number of AWTs that will be taken out of the unassigned pool of AWTs .
Because tactical reserves comes out of the unassigned pool, you will need to balance the needs of your tactical work against the needs of the other active work. A good starting point is to find out what the peak demand for AWTs is for the tactical work. Look at the WorkTypeMax08 numbers in the ResUsageSAWT table. If you have given the workload an enforcement priority of tactical, then it will already be expedited and will be using MsgWorkEight work type. So all of its activity will show up in WorkTypeInuse08 and WorkTypeMax08 fields. Consider making your reserve count equal to the usual high usage numbers for WorkTypeMax08.
Precision is not required when setting the limit parameter. You just want to make sure it is not too low so it will lead to MsgWorkEight messages being queued when only a few are active. For example, you wouldn't want to set the limit at 5 or 6, or probably anything below 20. Its not a bad idea to set it the same as MsgWorkNew, at 50, since the theory behind that is to prevent new work from flooding the system. But also keep in mind that while there may not be any real harm in doing so, there is also no value in setting it too high, over 80 for example, as its unlikely you would have that many available AWTs to support that level of concurrency for MsgWorkEight anyway. Bottom line, setting the limit on MsgWorkEight AWTs anywhere between 30 and 60 is probably reasonable. If you're not sure how to set it, make it the same as the MsgWorkNew limit, at 50.
There are actually 3 actions that will need to be taken when reserving AWTs, so let’s take a final look at what they are and what they do:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.