15.00 - Allocation Groups - Teradata Database

Teradata Database Utilities

Product
Teradata Database
Release Number
15.00
Content Type
Configuration
Publication ID
B035-1102-015K
Language
English (United States)
Last Update
2018-09-25

Allocation Groups

An Allocation Group establishes how resources are allocated to tasks (threads). It defines the following:

  • A method for disbursing resources among sessions active within that Allocation Group
  • An attribute that optionally expedites work requests for sessions controlled by the Allocation Group
  • A weight
  • Optionally, a CPU limit
  • In a single Resource Partition, multiple Performance Periods belonging to different Performance Groups can reference the same Allocation Group, as shown in the following figure.

    An Allocation Group cannot be referenced by Performance Groups from more than one Resource Partition.

    Allocation Group Parameters

    The following table describes the parameters of an Allocation Group.

     

    Parameter

    Description

    Allocation Group ID

    Any number from 0 to 199 inclusive.

    Expedite Attribute

    Optional parameter that indicates that work requests are to be expedited through the AWT invocation procedures. If present, it appears as X.

    For more information, see “Expedite Attribute” on page 716.

    Allocation Group Weight

    A positive integer value used to compute the proportion of resources each task should receive. This weight is converted to a relative weight, taking into account all other active allocation groups within the same Resource Partition.

    For more information, see “Allocation Group Weight” on page 717

    Limit

    Optional parameter that is an integer from1 through 100. Specifies the limit on the total CPU usage by sessions controlled by the Allocation Group.

    Associating Allocation Groups to Performance Groups

    Recommendations:

  • Start simple with a one-to-one relationship between Performance Groups and Performance Periods/Allocation Groups.
  • Establish reasonable contrast between weights of Allocation Groups in the same Resource Partition, but avoid extreme differences. For example, use 2:1, 3:1, and 4:1 ratios between weights, rather than 12:1 or 20:1.
  • If strong priority differences are required, establish relative weights for different priority Allocation Groups so that the contrast between them is a factor of two or more. For example, consider relative weights of 5%, 20% and 50%, rather than 15%, 18% and 20%.

    Expedite Attribute

    You can specify an Expedite Attribute for an Allocation Group to indicate that work requests for sessions controlled by the Allocation Group are to be expedited through the AMP worker task (AWT) invocation procedures. Work requests controlled by the Allocation Group are favored over non-expedited work requests controlled by other Allocation Groups during the invocation procedure in two ways:

  • Expedited work requests receive increased priority in the work request input queue when all AMP worker tasks are in use. They bypass normal work requests in the input queue and have quicker access to an AWT.
  • Expedited work requests have access to a special pool of reserved AWTs that have been dedicated for this expedited work by the Teradata Database system administrator.
  • Caution:

    Teradata recommends that only Allocation Groups supporting short, response-sensitive work, such as single-AMP operations, be expedited. Work performed in this mode will have some impact on resources available to non-expedited work. Use this option judiciously.

    For more information on reserved AWT pool, see “AMP Worker Task (AWT) Reservations and Limits” on page 720.

    Allocation Group Weight

    Allocation group weights are values used to compute the proportion of resources each task will be offered. The relative weight of an Allocation Group is the ratio of its weight divided by the sum of the weights of all active Allocation Groups within the same Resource Partition multiplied by the relative weight of the Resource Partition.

    Determining Allocation Group Relative Weight

    Suppose each Performance Group of a Resource Partition is linked to one Allocation Group. The weights of these Allocation Groups are as follows:

  • Allocation Group 1 = 5
  • Allocation Group 2 = 10
  • Allocation Group 3 = 20
  • Allocation Group 4 = 40
  • Suppose that only Allocation Groups 1, 2, and 3 are active.

    To determine the weight for each of these active Allocation Groups, do the following:

    1 Add the individual respective weights of the three active Performance Groups (5 + 10 + 20) for a sum of 35.

    2 Divide the weight (5, 10, and 20) of each Performance Group by the sum of 35.

    The relative weight for each Allocation Group, relative to its Resource Partition, is as follows:

  • Allocation Group 1 = 14% (5/35)
  • Allocation Group 2 = 28% (10/35)
  • Allocation Group 3 = 57% (20/35)
  • 3 If the relative weight of the Resource Partition is 50%, multiply the relative weight for each Allocation Group by .50 to determine the relative weight for each Allocation Group.

    The final Allocation Group weights are as follows:

    If the relative weight of the Resource Partition is 50%, multiply the relative weight for each Allocation Group by .50 to determine the relative weight for each Allocation Group.

  • Allocation Group 1 = 7% (.14 x .50)
  • Allocation Group 2 = 14% (.28 x .50)
  • Allocation Group 3 = 28% (.57 x .50)
  • The following example shows how Priority Scheduler handles Resource Partitions and associated Performance Groups.

    Suppose you have three active Resource Partitions with the following weightings:

  • Default = 20
  • Tactical = 60
  • Standard = 20
  • The Standard Resource Partition consists of the following:

     

    Performance Group

    Allocation Group Weight

    Type of Work

    D

    5

    For demotions

    P2

    10

    Med/low priorities

    P1

    40

    High priorities

    B

    20

    Batch loads and reports

    To determine the resources allocated to med/low priority users, do the following:

    1 Add the assigned weights of all active Resource Partitions:

    20 + 60 + 20 = 100

    2 Find the percentage of resources allocated to the Standard Resource Partition by dividing the weight of the Standard Resource Partition (20) by the sum of the active Resource Partitions (100):

    20/100 = 20%

    3 Add the assigned weights (5, 10, 40, and 20) of the active Allocation Groups within the Standard Resource Partition:

    5 + 10 + 40 + 20 = 75

    4 Find the percentage of the Standard Resource Partition allocation that the med/low priority users can expect by dividing the P2 group weight (10) by the sum of the active Performance Groups (75):

    10/75 = 13%

    5 Multiply the percentage of resources (20%) allocated to the Standard Resource Partition by the percentage (13%) of the Standard Resource Partition allocation that the med/low priority users can expect:

    20% x 13% = 2%

    With all Resource Partitions and all Performance Groups in the Teradata Database system active, the relative weight of the Allocation Group for med/low priority users is 2%. The relative weight of the Allocation Group for batch load and report users is 5%. In this example, the batch load and report users will have more than twice as much access to resources than the med/low priorities.

    Query Response Time and Allocation Groups

    The consistency of response times within a given Allocation Group depends on the following:

  • The number of users active at the same time within the Allocation Group
  • The nature of the queries (such as data skew, complexity of the work submitted, and how long the queries take to complete)
  • The average query response time grows as active users in the same Allocation Group increase.

    The following table shows how the number of users in Performance Group H (and its associated Allocation Group) affects query response time of all queries in that Allocation Group.

     

    IF the number of active users in a Performance Group/Allocation Group pair is...

    THEN the average query response time might be...

    1

    7 seconds.

    5

    11 seconds.

    10

    19 seconds.

    20

    38 seconds.