Work Load Management

WLM Dynamic and Static Configuration Properties

 The WLM configuration properties are either dynamic or static.

 If you change any of the dynamic properties, you don’t need to reboot your cluster for the
changes to take effect. If you add or remove query queues or change any of the static
properties,
 You must restart your cluster before any WLM parameter changes, including changes to
dynamic properties, take effect.

The following WLM properties are static:

 User groups
 User group wildcard
 Query groups
 Query group wildcard

The following WLM properties are dynamic:

 Concurrency
 Percent of memory to use
 Timeout
 Any modification in rules, adding or removing rules is also dynamic changes.
 Enable short query acceleration (SQA)
 Maximum run time for short queries

Defining Query Queues:

When users run queries in Amazon Redshift, the queries are routed to query queues. Each query
queue contains a number of query slots.
Each queue is allocated a portion of the cluster's available memory. A queue's memory is
divided among the queue's query slots.

You can also use the wlm_query_slot_count parameter, which is separate from the WLM
properties, to temporarily enable queries to use more memory by allocating multiple slots.

Query queues are defined in the WLM configuration.

The WLM configuration is an editable parameter (wlm_json_configuration) in a parameter
group, which can be associated with one or more clusters. You can configure WLM by using the
Amazon Redshift console, the AWS CLI, Amazon Redshift API, or one of the AWS SDKs.
You can add additional query queues to the default WLM configuration, up to a total of eight
user queues.

Configure the following parameters for each query queue:

1. Concurrency level:
 Each queue can be configured to run up to 50 queries concurrently.
 The maximum total concurrency level for all user-defined queues is 50.
 By default, WLM queues have a concurrency level of 5.As a best practice, recommend a
concurrency level of 15 or lower.
 The limit includes the default queue, but doesn't include the reserved Superuser queue.
 At run time, you can temporarily override the amount of memory assigned to a query by
setting the wlm_query_slot_count parameter to specify the number of slots allocated to
the query.
 JSON property: query_concurrency
If a specific query needs more memory than is allocated to a single query slot, you can
increase the available memory by increasing the wlm_query_slot_count parameter.
Syntax:

set wlm_query_slot_count to 10;

After the query run just reset the wlm_query_slot_count parameter by below syntax:

Reset wlm_query_slot_count;

Note: Always assign the less number of wlm_query_slot_count to value of

concurrency level assign to that queue.

Recommended points while assigning concurrency level to queue:

 Create a separate queue and give higher concurrency level and allocate the less memory
and assign the smaller query to this queue.
 If you have multiple queries that each access data on a single slice, set up a separate
WLM queue to execute those queries concurrently. Amazon Redshift will assign
concurrent queries to separate slices, which allows multiple queries to execute in
parallel on multiple slices.
2. User groups :
 You can assign a set of user groups to a queue by specifying each user group name or by
using wildcards.
 When a member of a listed user group runs a query, that query runs in the
corresponding queue.
 There is no set limit on the number of user groups that can be assigned to a queue.
 JSON property: user_group
  Below is the syntax to create the user group :

Create group group_name with user username1,username2

Example:

Create group admin with user vivek, suresh

Delete the group name:

Drop group group_name;

Adding and Deleting the user from user group:

Adding user : Alter group group_name add user user_name1,user_name2;

Removing user: Alter group group_name drop user user_name1,user_name2;

Renaming group name: Alter group old_group_name rename to new_group_name;

3. Query groups:
 You can assign a set of query groups to a queue by specifying each query group name or
by using wildcards. A query group is simply a label.
 At run time, you can assign the query group label to a series of queries.
 There is no set limit to the number of query groups that can be assigned to a queue.
 JSON property: query_group
 Syntax: set query_group to 'label_name'.

Example: Set query_group to ‘Big_query’

 Label_name “Big_query” must be included into the wlm parameter group while creating
a new queue.
4. WLM memory percent to use:
 To specify the amount of available memory that is allocated to a query.
 By default, each user-defined queue is allocated an equal portion of the memory that is
available for user-defined queries.
 The superuser queue has its own allocated memory and cannot be modified.
 Any unallocated memory is managed by Amazon Redshift and can be temporarily given
to a queue if the queue requests additional memory for processing.
 JSON property: memory_percent_to_use
5. WLM timeout :
 To limit the amount of time that queries in a given WLM queue are permitted to use,
you can set the WLM timeout value for each queue.
 The timeout parameter specifies the amount of time, in milliseconds.
 The timeout is based on query execution time and doesn't include time spent waiting in
a queue.
  WLM timeout doesn’t apply to a query that has reached the returning state. There are
13 states of query. To view the states of the query refer the below table:
STV_WLM_QUERY_STATE.
 JSON property: max_execution_time

6. Enable short query acceleration:

 Short query acceleration (SQA) prioritizes selected short-running queries ahead of
longer-running queries. SQA executes short-running queries in a dedicated space, so
that SQA queries aren't forced to wait in queues behind longer queries. With SQA,
short-running queries begin executing more quickly and users see results sooner.
 Amazon Redshift uses a machine learning algorithm to analyze each eligible query and
predict the query's execution time. If the query's predicted execution time is less than
the defined SQA maximum run time, then SQA separates the query from the WLM
queues and schedules it for priority execution.
 To enable SQA in the AWS console, edit the WLM configuration for a parameter group
and choose Enable short query acceleration. When you enable SQA, your total WLM
query slot count, or concurrency, across all user-defined queues must be 15 or fewer. If
you enable SQA using the AWS CLI or the Amazon Redshift API, the slot count limitation
is not enforced.
 To enable SQA, specify true. The default is false.
JSON property: short_query_queue
7. Maximum run time for short queries:
 When you enable SQA, you can specify a maximum run time for short queries between
1 and 20 seconds, in milliseconds. The default value is 5000.
 JSON property: max_execution_time

Creating Rules in a Queue by using JSON format.

You can have up to eight rules per queue, and the total limit for all queues is eight rules.

Rule syntax in JSON format:

rules

rule_name

predicate

metric_name

operator

value
}

Action

Example:

"rules": [

"rule_name": "rule_1",

"predicate": [

"metric_name": "query_cpu_time",

"operator": ">",

"value": 100000

},

"metric_name": "query_blocks_read",

"operator": ">",

"value": 1000

],

"action": "hop"

For each rule, you specify the following properties:

 Rule_name –

Rule names must be unique within WLM configuration. Rule names can be up to 32
alphanumeric characters or underscores, and can't contain spaces or quotation marks.
You can have up to eight rules per queue, and the total limit for all queues is eight rules.

 Predicate – You can have up to three predicates per rule. For each predicate, specify the
following properties.
 Metric_name –
 operator – Operations are =, <, and >.
  value – The threshold value for the specified metric that triggers an action.
 Action – Each rule is associated with one action.

Valid actions are:

 log
 hop
 abort
Note : If more than one rule applied on 1 queue then rule execution will be run first that will decide by
the action of the rule.

The Rule which have the highest priority will be considered first.

WLM evaluates metrics every 10 seconds.

If more than one rule is triggered during the same period, WLM initiates the most severe action—abort,
then hop, then log.

Highest priority: Abort

Lowest priority : Log

Note: A user-defined function (UDF) or any query that writes to the database cannot be rerouted and
is simply canceled. Such queries include data manipulation language (DML) statements, data definition
language (DDL) statements, and commands that change the database, such as VACUUM.

WLM System Tables and Views:

You can view the status of queries, queues, and service classes by using WLM-specific system tables.
Query the following system tables to do the following:

 View which queries are being tracked and what resources are allocated by the workload
manager.
 See which queue a query has been assigned to.
 View the status of a query that is currently being tracked by the workload manager.

Table Name Table Description

STL_WLM_ERROR Contains a log of WLM-related error events.
STL_WLM_QUERY Lists queries that are being tracked by WLM
STV_WLM_CLASSIFICATION_CONFIG Shows the current classification rules for WLM.
STV_WLM_QUERY_QUEUE_STATE Records the current state of the query queues.
STV_WLM_QUERY_STATE Provides a snapshot of the current state of queries
that are being tracked by WLM.
STV_WLM_QUERY_TASK_STATE Contains the current state of query tasks.
STV_WLM_SERVICE_CLASS_CONFIG Records the service class configurations for WLM.
It gives the info about which are groups and query
groups are associated with the which queue and
also associated with the which service class
STV_WLM_SERVICE_CLASS_STATE Contains the current state of the service classes.
Useful tables to monitor the metrics of any query.
1> SVL_QUERY_METRICS

2> STL_QUERY_METRICS

3> STL_WLM_RULE_ACTION
 WLM Implementation Result
AWS has recently introduced SQA (Short Query Acceleration). This feature is also added to the
WLM implementation. SQA is also enabled in the Dev cluster. Below are the details

Cluster Name Parameter Group Name

ti-use1-infra-cfn-dev-asdw-phase-1-
ti-use1-infra-cfn-dev-asdw asdwredshiftclusterparametergroup

If we want to check whether SQA enabled through the Aqua Data Studio need to run below query

select * from stv_wlm_service_class_config where service_class = 14;

If SQA is enabled then the above query will give below result
target_q
target_n eviction_ query_w uery_wor max_exe user_gro query_gr
queueing_strateg num_que um_quer threshol orking_m king_me min_step cution_ti up_wild_ oup_wild
service_class y ry_tasks y_tasks evictable d em m _mem name me card _card
Short
query
14 FIFO Queue Policy 6 6 true 5000000 710 710 5 queue 5000 false false

The resultant JSON command and query generation was also modified

aws redshift modify-cluster-parameter-group --parameter-group-name ti-use1-infra-cfn-dev-asdw-

phase-1-asdwredshiftclusterparametergroup --parameters
'[{"ParameterName":"wlm_json_configuration","ParameterValue":"[ { \"query_group\" :
[ ], \"user_group\" : [ \"wlm_etl_nightly_group\" ], \"query_group_wild_card\" :
0, \"user_group_wild_card\" : 0, \"query_concurrency\" : 4, \"max_execution_time\" :
0, \"memory_percent_to_use\" : 4},{ \"query_group\" : [ ], \"user_group\" :
[ \"wlm_mstr_aa_group\" ], \"query_group_wild_card\" : 0, \"user_group_wild_card\" :
0, \"query_concurrency\" : 5, \"max_execution_time\" : 1800000, \"memory_percent_to_use\" : 22},{
\"query_group\" : [ ], \"user_group\" : [ \"wlm_mstr_mni_group\" ], \"query_group_wild_card\" :
0, \"user_group_wild_card\" : 0, \"query_concurrency\" : 2, \"max_execution_time\" :
600000, \"memory_percent_to_use\" : 4},{ \"query_group\" : [ ], \"user_group\" :
[ \"wlm_mstr_imym_group\" ], \"query_group_wild_card\" : 0, \"user_group_wild_card\" :
0, \"query_concurrency\" : 2, \"max_execution_time\" : 1800000, \"memory_percent_to_use\" : 9},
{ \"query_group\" : [ ], \"user_group\" : [ \"wlm_pentaho_etl_group\" ], \"query_group_wild_card\" :
0, \"user_group_wild_card\" : 0, \"query_concurrency\" : 8, \"max_execution_time\" :
0, \"memory_percent_to_use\" : 52},{ \"query_group\" : [ ], \"user_group\" :
[ \"wlm_mstr_well_group\" ], \"query_group_wild_card\" : 0, \"user_group_wild_card\" :
0, \"query_concurrency\" : 5, \"max_execution_time\" : 0, \"memory_percent_to_use\" : 5},
{ \"query_group\" : [ ], \"user_group\" : [ ], \"query_group_wild_card\" :
0, \"user_group_wild_card\" : 0, \"query_concurrency\" : 2, \"max_execution_time\" :
0, \"memory_percent_to_use\" : 4},{ \"short_query_queue\": true, \"max_execution_time\":
5000}]","ApplyType":"dynamic"}]'

The highlighted part is required to enable SQA through CLI command.

Monitoring SQA:
The following query shows the number of queries that went through each query queue (service class),
along with average execution time, the number of queries with wait time at the 90th percentile, and the
average wait time. SQA queries use service class 14.

select final_state, service_class, count(*), avg(total_exec_time), percentile_cont(0.9) within group

order by total_queue_time), avg(total_queue_time) from stl_wlm_query where userid >= 100 group
by 1,2 order by 2,1;

percentile_con
final_state service_class count avg t avg
115276
Completed 5 1311 5 0 1438
806467
Completed 7 588 8 0 0
411233
Completed 8 291 5 0 0
247941
Completed 10 72089 7 0 175468
164158
Completed 11 157 6 0 47349
Completed 12 3810 642729 0 0
Completed 14 551 532873 4490657 693225
500036
Evicted 14 21 2 0 0

Till now 551 queries has been come to SQA queue and 21 queries has been evicted due to time out
issue.

To find which queries were picked up by SQA and completed successfully, run the following query.
select a.queue_start_time, a.total_exec_time, label, trim(querytxt) from stl_wlm_query a, stl_query b

where a.query = b.query and a.service_class = 14 and a.final_state = 'Completed' order by b.query
desc limit 5;

To find queries that were picked up by SQA but timed out, run the following query.

select a.queue_start_time, a.total_exec_time, label, trim(querytxt) from stl_wlm_query a, stl_query b

where a.query = b.query and a.service_class = 14 and a.final_state = 'Evicted' order by b.query desc
limit 5;

Configuration Table and Pentaho Job Implementation:

Below configuration tables and query are used to generate the CLI JSON command to modify the
wlm_json_configuration parameter as well.

Configuration Tables:

1. Temp_schema.info_ETL_WLM_Queue_config
2. Temp_schema.info_WLM_SQA_config

DDL script:

Info_etl_queue_table script.sql

SQL Statement to generate the CLI JSON command:

Json_query_original_
V2.sql

Sample Output of the query:

output.txt

I have developed the Pentaho Jobs to execute the JSON configuration.

WLM.kjb
 Prerequisite.kjb (To
check some pre
requisite condition
before
implementing the
change)

WLM_Query.ktr (Transformation to generate the CLI JSON Command)

All these jobs are parameterized. We need to pass the Project name i.e. Dev, Prod, MNI, WELL and
Process_queue i.e. PreETL and PostETL, so that it will generate the CLI JSON command.