チュートリアル: 手動ワークロード管理 (WLM) キューの設定
Amazon Redshift では、手動ワークロード管理 (WLM) キューを設定して、さまざまなタイプのクエリやユーザーにリソースを優先して割り当てることができます。手動 WLM キューを使用すると、特定のキューに対するメモリと同時実行設定を制御できるため、優先度の低いクエリがシステムを占有するのを防ぎながら、重要なワークロードが必要なリソースを確実に得ることができます。以下のセクションでは、ワークロード管理要件を満たすために Amazon Redshift で手動 WLM キューを作成および設定するプロセスについて説明します。
概要
Amazon Redshift では自動ワークロード管理 (WLM) を設定することをお勧めします。自動 WLM の詳細については、「ワークロード管理」を参照してください。ただし、複数の WLM キューを必要とする場合のために、このチュートリアルでは、Amazon Redshift で手動ワークロード管理 (WLM) を設定するプロセスについて説明します。手動 WLM を設定することで、クラスターのクエリパフォーマンスとリソース割り当てを改善できます。
Amazon Redshift はユーザークエリをキューにルーティングして処理します。WLM は、クエリがキューにルーティングされる方法を定義します。デフォルトで、Amazon Redshift にはクエリに使用できるキューが 2 つあります。1 つはスーパーユーザー用で、もう 1 つはユーザー用です。スーパーユーザーキューは設定ができず、一度に 1 つのクエリしか処理できません。このキューはトラブルシューティング目的のみに使用してください。ユーザーキューは最大 5 件のクエリを一度に処理できますが、必要に応じてキューの同時実行レベルを変更することで、この件数を設定できます。
データベースに対して数人のユーザーがクエリを実行する場合は、別の設定の方が効率的なことがあります。例えば、一部のユーザーが VACUUM のように大量のリソースを使う操作を実行する場合、レポートのようにリソースをあまり使わないクエリに対して悪影響が生じることがあります。このような場合は、キューを追加して、異なるワークロード用に設定することを検討してください。
予測時間: 75 分
推定コスト: 50 セント
前提条件
Amazon Redshift クラスター、サンプル TICKIT データベース、Amazon Redshift RSQL クライアントツールが必要です。これらをまだセットアップしていない場合は、「Amazon Redshift 入門ガイド」と「Amazon Redshift RSQL」を参照してください。
セクション
セクション 1: デフォルトキュー処理の動作の理解
手動 WLM の設定を開始する前に、Amazon Redshift におけるキュー処理のデフォルト動作を理解しておくと役に立ちます。このセクションでは、いくつかのシステムテーブルから情報を返すデータベースビューを 2 つ作成します。その後、いくつかのテストクエリを実行して、クエリがデフォルトでどのようにルーティングされるかを確認します。システムテーブルの詳細については、「システムテーブルとビューのリファレンス」を参照してください。
ステップ 1: WLM_QUEUE_STATE_VW ビューを作成する
このステップでは、WLM_QUEUE_STATE_VW というビューを作成します。このビューは、次のシステムテーブルから情報を返します。
チュートリアル全体でこのビューを使用して、WLM 設定の変更後にキューがどうなるかをモニタリングします。次の表は WLM_QUEUE_STATE_VW ビューが返すデータについて説明しています。
| 列 | 説明 |
|---|---|
| キュー | キューを表す行に関連付けられた番号。キュー番号によってデータベースでのキューの順序が決まります。 |
| description | 特定のユーザーグループでのみ使用できるか、特定のクエリグループでのみ使用できるか、またはあらゆるタイプのクエリで使用できるかを示す値。 |
| slots | キューに割り当てられたスロットの数。 |
| mem | キューに割り当てられているメモリの量 (スロットあたりの MB 単位)。 |
| max_execution_time | クエリの実行が許可されている時間。これを過ぎるとクエリは終了します。 |
| ユーザー_* | ユーザーグループに一致させるために、ワイルドカード文字の使用が WLM 設定で許可されるかどうかを示す値。 |
| query_* | クエリグループに一致させるために、ワイルドカード文字の使用が WLM 設定で許可されるかどうかを示す値。 |
| queued | キューで処理を待機中のクエリの数。 |
| executing | 現在実行中のクエリの数。 |
| executed | 実行されたクエリの数。 |
WLM_QUEUE_STATE_VW ビューを作成するには
-
Amazon Redshift RSQL を開き、TICKIT サンプルデータベースに接続します。このデータベースがない場合は、「前提条件」を参照してください。
-
次のクエリを実行して、WLM_QUEUE_STATE_VW ビューを作成します。
create view WLM_QUEUE_STATE_VW as select (config.service_class-5) as queue , trim (class.condition) as description , config.num_query_tasks as slots , config.query_working_mem as mem , config.max_execution_time as max_time , config.user_group_wild_card as "user_*" , config.query_group_wild_card as "query_*" , state.num_queued_queries queued , state.num_executing_queries executing , state.num_executed_queries executed from STV_WLM_CLASSIFICATION_CONFIG class, STV_WLM_SERVICE_CLASS_CONFIG config, STV_WLM_SERVICE_CLASS_STATE state where class.action_service_class = config.service_class and class.action_service_class = state.service_class and config.service_class > 4 order by config.service_class; -
次のクエリを実行して、ビューに含まれる情報を表示します。
select * from wlm_queue_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 1 | 160
ステップ 2: WLM_QUERY_STATE_VW ビューを作成する
このステップでは、WLM_QUERY_STATE_VW というビューを作成します。このビューは STV_WLM_QUERY_STATE システムテーブルから情報を返します。
チュートリアル全体でこのビューを使用して、実行中のクエリをモニタリングします。次の表は WLM_QUERY_STATE_VW ビューが返すデータについて説明しています。
| 列 | 説明 |
|---|---|
| query | クエリ ID。 |
| キュー | キューの数。 |
| slot_count | クエリに割り当てられたスロットの数。 |
| start_time | クエリが開始された時刻。 |
| state | 実行などのクエリの状態。 |
| queue_time | クエリがキューに入ってからの時間 (マイクロ秒)。 |
| exec_time | クエリが実行されている時間 (マイクロ秒)。 |
WLM_QUERY_STATE_VW ビューを作成するには
-
RSQL で次のクエリを実行して、WLM_QUERY_STATE_VW ビューを作成します。
create view WLM_QUERY_STATE_VW as select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time from stv_wlm_query_state; -
次のクエリを実行して、ビューに含まれる情報を表示します。
select * from wlm_query_state_vw;結果の例は次のとおりです。
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1249 | 1 | 1 | 2014-09-24 22:19:16 | Executing | 0 | 516
ステップ 3: テストクエリを実行する
このステップでは、RSQL で複数の接続からクエリを実行し、システムテーブルを確認して、クエリがどのようにルーティングされて処理されたかを判断します。
このステップでは、RSQL ウィンドウを 2 つ開いておく必要があります。
-
RSQL ウィンドウ 1 では、このチュートリアルで既に作成したビューを使用して、キューとクエリの状態をモニタリングするクエリを実行します。
-
RSQL ウィンドウ 2 では、RSQL ウィンドウ 1 に表示される結果を変更する実行時間が長いクエリを実行します。
テストクエリを実行するには
-
RSQL ウィンドウを 2 つ開きます。既にウィンドウを 1 つ開いている場合は、2 つ目のウィンドウを開くだけでかまいません。どちらの接続にも同じユーザーアカウントを使用できます。
-
RSQL ウィンドウ 1 で、次のクエリを実行します。
select * from wlm_query_state_vw;結果の例は次のとおりです。
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1258 | 1 | 1 | 2014-09-24 22:21:03 | Executing | 0 | 549このクエリは自己参照的な結果を返します。現在実行中のクエリはこのビューからの SELECT ステートメントです。このビューに対するクエリは少なくとも 1 つの結果を常に返します。次のステップで実行時間が長いクエリを開始した後に表示される結果とこの結果を比較します。
-
RSQL ウィンドウ 2 で、TICKIT サンプルデータベースからクエリを実行します。このクエリは約 1 分間実行されるため、その間に WLM_QUEUE_STATE_VW ビューと以前に作成した WLM_QUERY_STATE_VW ビューの結果を確認できます。場合によっては、クエリの実行時間が短くて両方のビューに対してクエリを実行できないことがあります。このような場合は、
l.listidでフィルターの値を増やし、実行時間を延長できます。注記
クエリの実行時間を短縮し、システムパフォーマンスを向上させるために、Amazon Redshift は特定の種類のクエリの結果をリーダーノード上のメモリにキャッシュします。結果のキャッシュが有効になると、その後のクエリはより高速に実行されます。クエリが高速で実行されることを防ぐには、現行のセッションで結果のキャッシュを無効にします。
現在のセッションに対する結果のキャッシュをオフにするには、以下にあるとおり、enable_result_cache_for_session パラメータを
offに設定します。set enable_result_cache_for_session to off;RSQL ウィンドウ 2 で、次のクエリを実行します。
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000; -
RSQL ウィンドウ 1 で、WLM_QUEUE_STATE_VW と WLM_QUERY_STATE_VW をクエリし、その結果を以前の結果と比較します。
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (querytype:any) | 5 | 836 | 0 | false | false | 0 | 2 | 163 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 1267 | 1 | 1 | 2014-09-24 22:22:30 | Executing | 0 | 684 1265 | 1 | 1 | 2014-09-24 22:22:36 | Executing | 0 | 4080859
以前のクエリとこのステップでの結果との間には次の違いがあることに注意してください。
-
現在は WLM_QUERY_STATE_VW に 2 行あります。1 つの結果は、このビューに対して SELECT 操作を実行する自己参照的クエリです。2 つ目の結果は、以前のステップの長時間実行されるクエリです。
-
WLM_QUEUE_STATE_VW の executing 列の値は、1 から 2 に増えました。この列エントリは、キューで 2 つのクエリが実行中であることを意味します。
-
executed 列の値は、キューのクエリを実行するたびに増加します。
WLM_QUEUE_STATE_VW ビューは、キューの全体像と各キューで処理中のクエリの数を把握するのに便利です。WLM_QUERY_STATE_VW ビューは、現在実行中の個々のクエリについてその詳細を把握するのに便利です。
セクション 2: WLM のクエリキュー設定の変更
キューのデフォルトの仕組みが理解できたため、次は手動 WLM を使用してクエリキューを設定する方法について説明します。このセクションでは、クラスターの新しいパラメータグループを作成して設定します。ユーザーキューを 2 つ追加で作成して、クエリのユーザーグループまたはクエリグループラベルに基づいてクエリを受け付けるように、これらのキューを設定します。この 2 つのキューのどちらにもルーティングされないクエリは、実行時にデフォルトキューにルーティングされます。
パラメータグループの手動 WLM 設定を作成するには
-
AWS Management Console にサインインして、https://console.aws.amazon.com/redshiftv2/
で Amazon Redshift コンソールを開きます。 -
ナビゲーションメニューで、[Configurations] (設定) を選択し、次に [Workload management] (ワークロード管理) を選択して [Workload management] (ワークロード管理) ページを表示します。
-
[作成] を選択して [パラメータグループの作成] ウィンドウを表示します。
-
[Parameter group name] (パラメータグループ名) と[Description] (説明)の両方で
WLMTutorialを入力し、[Create] (作成) をクリックしてパラメータグループを作成します。注記
[パラメータグループ名] は作成時にすべて小文字に変換されます。
-
[ワークロード管理] ページで、パラメータグループ
wlmtutorialを選択し、[パラメータ] と [ワークロード管理] のタブのある詳細ページを表示します。 -
[ワークロード管理] タブを開いていることを確認し、[Switch WLM mode (WLM モードの切り替え)] を選択して [Concurrency settings (同時実行設定)] ウィンドウを表示します。
-
[Manual WLM (手動 WLM)] を選択してから [保存] を選択し、手動 WLM に切り替えます。
-
[Edit workload queues (ワークロードキューの編集)] を選択します。
-
[キューの追加] を 2 度選択して、2 つのキューを追加します。現在 [キュー 1]、[キュー 2]、[デフォルトキュー] の 3つのキューがある状態です。
-
それぞれのキューの情報を次のように入力します。
-
[Queue 1] (キュー 1) では、[Memory (%)] (メモリ (%)) に
30、[Concurrency on main] (メインの同時実行性)に2、[Query groups] (クエリグループ) にtestを入力します。その他の設定はデフォルト値のままにしておきます。 -
[Queue 2] (キュー 2) では、[Memory (%)] (メモリ (%)) に
40、[Concurrency on main] (メインの同時実行性) に3、[User groups] (ユーザーグループ) にadminを入力します。その他の設定はデフォルト値のままにしておきます。 -
[デフォルトキュー] には変更を加えないでください。WLM は、未割り当てのメモリをデフォルトキューに割り当てます。
-
-
設定を保存するには [保存] を選択します。
次に、手動 WLM 設定を持つパラメータグループをクラスターに関連付けます。
パラメータグループをクラスターの手動 WLM 設定に関連付けるには
-
AWS Management Console にサインインして、https://console.aws.amazon.com/redshiftv2/
で Amazon Redshift コンソールを開きます。 -
ナビゲーションメニューから [Clusters] (クラスター) を選択し、次に [Clusters] (クラスター) を選択してクラスターのリストを表示します。
-
クラスターの詳細を表示するには、
exampleclusterなどのクラスターを選択します。次に、[Properties] (プロパティ) タブを選択して、そのクラスターのプロパティを表示します。 -
[Database configurations] (データベース構成) セクションで、[Edit] (編集)、[Edit parameter group] (パラメータグループの編集) を選択して、パラメータグループのウィンドウを表示します。
-
[Parameter groups] (パラメータグループ) で、以前に作成した
wlmtutorialパラメータグループを選択します。 -
[Save changes] (変更を保存) を選択して、パラメータグループを関連付けます。
クラスターは変更されたパラメータグループで変更されます。ただし、変更をデータベースにも適用するには、クラスターを再起動する必要があります。
-
クラスターを選択してから、[Actions] (アクション) の [Reboot] (再起動) を選択します。
クラスターが再起動されると、ステータスは [利用可能] に戻ります。
セクション 3: ユーザーグループとクエリグループに基づいてクエリをキューにルーティング
クラスターを新しいパラメータグループに関連付けて WLM を設定しました。次に、いくつかのクエリを実行して Amazon Redshift がどのようにクエリをキューにルーティングして処理するかを確認します。
ステップ 1: データベースのクエリキュー設定を表示する
まず、データベースに WLM が正常に設定されていることを確認します。
クエリキュー設定を表示するには
-
RSQL を開き、次のクエリを実行します。クエリは「ステップ 1: WLM_QUEUE_STATE_VW ビューを作成する」で作成した WLM_QUEUE_STATE_VW ビューを使用します。クラスターを再起動する前にセッションをデータベースに接続済みである場合は、再接続する必要があります。
select * from wlm_queue_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0この結果を、「ステップ 1: WLM_QUEUE_STATE_VW ビューを作成する」で受け取った結果と比較します。キューが 2 つ追加されていることがわかります。キュー 1 は test クエリグループのキューになり、キュー 2 は admin ユーザーグループのキューになっています。
キュー 3 はデフォルトキューになっています。リストの最後のキューは常にデフォルトキューです。これは、クエリでユーザーグループやクエリグループが指定されていない場合、デフォルトでクエリがルーティングされる先のキューです。
-
次のクエリを実行して、クエリがキュー 3 で実行されることを確認します。
select * from wlm_query_state_vw;結果の例は次のとおりです。
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2144 | 3 | 1 | 2014-09-24 23:49:59 | Executing | 0 | 550430
ステップ 2: クエリグループキューを使ってクエリを実行する
クエリグループキューを使ってクエリを実行するには
-
次のクエリを実行して、クエリを
testクエリグループにルーティングします。set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
他の RSQL ウィンドウから、次のクエリを実行します。
select * from wlm_query_state_vw;結果の例は次のとおりです。
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2168 | 1 | 1 | 2014-09-24 23:54:18 | Executing | 0 | 6343309 2170 | 3 | 1 | 2014-09-24 23:54:24 | Executing | 0 | 847クエリは、test クエリグループ (今はキュー 1) にルーティングされました。
-
キューの状態表示ですべてを選択します。
select * from wlm_queue_state_vw;次のような結果が表示されます。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 0 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 0 -
今度は、クエリグループをリセットして、実行時間が長いクエリを再び実行します。
reset query_group; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
ビューに対するクエリを実行して、結果を確認します。
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 2 | 5 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2186 | 3 | 1 | 2014-09-24 23:57:52 | Executing | 0 | 649 2184 | 3 | 1 | 2014-09-24 23:57:48 | Executing | 0 | 4137349結果として、クエリが今は再びキュー 3 で実行されています。
ステップ 3: データベースユーザーとグループを作成する
このキューでクエリを実行する前に、データベースにユーザーグループを作成して、このユーザーグループにユーザーを追加する必要があります。次に、新しいユーザーの認証情報を使って RSQL にログインして、クエリを実行します。データベースユーザーを作成するには、管理ユーザーのようなスーパーユーザーとしてクエリを実行する必要があります。
新しいデータベースユーザーとユーザーグループを作成するには
-
RSQL ウィンドウで次のコマンドを実行して、データベースに
adminwlmという名前の新しいデータベースユーザーを作成します。create user adminwlm createuser password '123Admin'; -
続いて、次のコマンドを実行して、新しいユーザーグループを作成し、新しい
adminwlmユーザーをそのユーザーグループに追加します。create group admin; alter group admin add user adminwlm;
ステップ 4: ユーザーグループキューを使ってクエリを実行する
次に、クエリを実行し、それをユーザーグループキューにルーティングします。これを行うのは、実行するクエリのタイプを処理するように設定されたキューにクエリをルーティングする場合です。
ユーザーグループキューを使ってクエリを実行するには
-
RSQL ウィンドウ 2 で、次のクエリを実行して、
adminwlmアカウントに切り替え、そのユーザーとしてクエリを実行します。set session authorization 'adminwlm'; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
RSQL ウィンドウ 1 で、次のクエリを実行して、クエリがルーティングされるクエリキューを確認します。
select * from wlm_query_state_vw; select * from wlm_queue_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 0 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 8 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2202 | 2 | 1 | 2014-09-25 00:01:38 | Executing | 0 | 4885796 2204 | 3 | 1 | 2014-09-25 00:01:43 | Executing | 0 | 650このクエリが実行されたキューはキュー 2 (
adminユーザーキュー) です。このユーザーとしてログインしてクエリを実行すると、別のクエリグループを指定しない限り、クエリは常にキュー 2 で実行されます。選択されるキューは、キューの割り当てルールによって異なります。詳細については、「WLM キュー割り当てルール」を参照してください。 -
次に、RSQL ウィンドウ 2.から次のクエリを実行します。
set query_group to test; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
RSQL ウィンドウ 1 で、次のクエリを実行して、クエリがルーティングされるクエリキューを確認します。
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 1 | 1 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 1 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 10 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2218 | 1 | 1 | 2014-09-25 00:04:30 | Executing | 0 | 4819666 2220 | 3 | 1 | 2014-09-25 00:04:35 | Executing | 0 | 685 -
処理が完了したら、クエリグループをリセットします。
reset query_group;
セクション 4: wlm_query_slot_count を使用してキューの同時実行レベルを一時的に変更
ときどき、特定のクエリのために一時的にリソースが余分に必要になることがあります。その場合は、wlm_query_slot_count 設定を使って、クエリキューでスロットが割り当てられる方法を一時的に変更することができます。スロットは、クエリを処理するために使用されるメモリと CPU の単位です。データベースで VACUUM 操作を実行する場合など、クラスターのリソースを大量に使用するクエリをたまに実行する場合に、スロット数を一時的に変更できます。
クエリのタイプによっては、ユーザーが wlm_query_slot_count を設定することが必要になる場合があります。そのような場合は、WLM 設定を調整し、クエリのニーズにより適したキューをユーザーに提供することを検討します。スロット数を使用して同時実行レベルを一時的に変更する方法の詳細については、「wlm_query_slot_count」を参照してください。
ステップ 1: wlm_query_slot_count を使用して同時実行レベルを一時的に変更する
このチュートリアルの目的に合わせて、実行時間が長い同じ SELECT クエリを実行します。そのクエリは adminwlm ユーザーとして実行し、wlm_query_slot_count を使ってクエリで使用可能なスロット数を増やします。
wlm_query_slot_count を使用して同時実行レベルを一時的に変更するには
-
クエリの制限を増やして、WLM_QUERY_STATE_VW ビューをクエリして結果を確認する時間を十分に確保します。
set wlm_query_slot_count to 3; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
ここで、管理者ユーザーを使用して WLM_QUERY_STATE_VW にクエリを実行し、クエリの動作を確認します。
select * from wlm_query_state_vw;結果の例は次のとおりです。
query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2240 | 2 | 1 | 2014-09-25 00:08:45 | Executing | 0 | 3731414 2242 | 3 | 1 | 2014-09-25 00:08:49 | Executing | 0 | 596クエリのスロット数が 3 であることがわかります。この数は、クエリが 3 つのスロットをすべて使ってクエリを処理していること、キューのリソースがすべてそのクエリに割り当てられていることを意味します。
-
今度は、次のクエリを実行します。
select * from WLM_QUEUE_STATE_VW;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 4 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 25wlm_query_slot_count 設定は、現在のセッションに対してのみ有効です。そのセッションが期限切れになった場合、または、別のユーザーがクエリを実行する場合は、WLM 設定が使用されます。
-
スロット数をリセットして、テストを再実行します。
reset wlm_query_slot_count; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 0 | 0 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 1 | 2 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 14 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+-----------+------------+----------- 2260 | 2 | 1 | 2014-09-25 00:12:11 | Executing | 0 | 4042618 2262 | 3 | 1 | 2014-09-25 00:12:15 | Executing | 0 | 680
ステップ 2: 別のセッションからクエリを実行する
次に、別のセッションからクエリを実行します。
別のセッションからクエリを実行するには
-
RSQL ウィンドウ 1 および 2 で、次を実行して、テストクエリグループを使用します。
set query_group to test; -
RSQL ウィンドウ 1 で、実行時間が長い次のクエリを実行します。
select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
RSQL ウィンドウ 1 で実行時間が長いクエリがまだ進行中の間に、以下を実行します。これらのコマンドは、キューのすべてのスロットを使用するようにスロット数を増やした後で、実行時間が長いクエリの実行を開始します。
set wlm_query_slot_count to 2; select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000; -
3 つ目の RSQL ウィンドウを開いて、ビューをクエリし、結果を確認します。
select * from wlm_queue_state_vw; select * from wlm_query_state_vw;結果の例は次のとおりです。
query | description | slots | mem | max_time | user_* | query_* | queued | executing | executed ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+---------- 0 | (super user) and (query group: superuser) | 1 | 357 | 0 | false | false | 0 | 0 | 0 1 | (query group: test) | 2 | 627 | 0 | false | false | 1 | 1 | 2 2 | (suser group: admin) | 3 | 557 | 0 | false | false | 0 | 0 | 3 3 | (querytype:any) | 5 | 250 | 0 | false | false | 0 | 1 | 18 query | queue | slot_count | start_time | state | queue_time | exec_time ------+-------+------------+---------------------+---------------+------------+----------- 2286 | 1 | 2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950 | 0 2282 | 1 | 1 | 2014-09-25 00:16:33 | Executing | 0 | 19335850 2288 | 3 | 1 | 2014-09-25 00:16:52 | Executing | 0 | 666最初のクエリではキュー 1 に割り当てられたスロットの 1 つを使用してクエリを実行していることに注意してください。さらに、キュー内で待機しているキューが 1 つあることにも注意してください (
queuedが1、stateがQueuedWaiting)。最初のクエリが完了すると、2 つ目のクエリの実行が開始されます。このように実行されるのは、両方のクエリがtestクエリグループにルーティングされていて、2 つ目のクエリは十分なスロット数が使用可能になるまで処理の開始を待機する必要があるためです。
セクション 5: リソースのクリーンアップ
クラスターが実行されている限り料金が発生し続けます。このチュートリアルを完了したら、Amazon Redshift 入門ガイドの「ステップ 8: 環境をリセットする」のステップに従って、環境を以前の状態に戻します。
WLM の詳細については、「ワークロード管理」を参照してください。
