Amazon Redshift に WLM タイムアウトを設定しているのですが、クエリはこの時間が過ぎても実行され続けます。なぜですか?

WLM タイムアウトは実行フェーズのクエリに対してのみ適用されます。WLM が、設定済みの時間制限内にクエリを終了させていないように思われる場合、通常それは、クエリが実行ステージ以外のステージで時間を費やしているためです。たとえば、クエリが解析と書き直しを待っている場合、ロックのために待機させられている場合、WLM キューでスポットを待っている場合、戻りステージでヒットしている場合、または別のキューにホップしている場合があり得ます。

STV_RECENTS を使用してクエリについての問い合わせを行った場合、starttime はクエリの実行が開始された時間ではなく、クエリがクラスターに入った時間になります。STV_RECENTS での結果で、クエリが Running 状態に入っていた場合、それはシステムではライブですが、STV_INFLIGHT で表示されるステータスに入るまでは、コンピューティングノードリソースを使用しません。クエリプランの詳細については、「クエリプランと実行ワークフロー」を参照してください。実行中のクエリのステータスを確認するには、STV_RECENTS の代わりに、次のように STV_INFLIGHT を使用します。

select * from STV_INFLIGHT where query = <queryid>;

クエリのステージについての詳細を確認するには、次のクエリを使用します。

select * from SVL_QUERY_REPORT where query = <queryid> ORDER BY segment, step, slice;

クエリの現在の実行状態を確認するには、次のクエリを使用します。

select * from STV_EXEC_STATE where query = <queryid> ORDER BY segment, step, slice;

クエリが WLM タイムアウト時間よりも長く実行されているように見える一般的な理由としては、次のようなものがあります。

クエリが「リターン」フェーズである

「リターン」フェーズには次の 2 種類があります。どちらのリターンフェーズになっているのかを確認するには、STV_EXEC_STATE を使用します。

  • コンピューティングノードからリーダーノードへ戻るところ
  • リーダーノードからクライアントに戻るところ

ロールバックの進行中

DML 操作 (insert、update、delete) が実施されたものの、操作でエラーが発生してロールバックが必要になった場合、その操作が終了可能な対象として表示されることはありません。すでにその操作のロールバックが進行中だからです。ロールバックは STV_EXEC_STATE を使用したクエリで確認できます。追加の情報は STL_UNDONE を使用したクエリで確認できます。

クエリが実行前のキューで多くの時間を費やしている

キューの中に入っている時間は、次のように、STV_WLM_QUERY_STATE を使用して確認できます。

select * from STV_WLM_QUERY_STATE where query = <queryid>;

クエリはロックのために待機させられている

クエリが STV_RECENTS では表示されるものの、STV_WLM_QUERY_STATE では表示されない場合、クエリはロックのために待機させられていて、まだキューには入っていない可能性があります。スタックしたプロセスが待機しているロックがあるかどうかを確認するには、次のようなクエリを使用します。

select * from SVV_TRANSACTIONS

where granted='f'

and pid in (select pid from STV_RECENTS where query = );

ブロックの原因となっているプロセスを識別するには、次のようなクエリを使用します。

select b.* from SVV_TRANSACTIONS b, SVV_TRANSACTIONS w

where b.granted='t'

and w.granted = 'f'

and b.txn_db = w.txn_db

and b.relation = w.relation

and w.pid in (select pid from STV_RECENTS where query = );

ブロックの原因となっている可能性のある pid (現在実行中のクエリなど) についての詳細を確認するには、次のようなクエリを実行します。

select * from STL_QUERY where pid = ;

select * from SVL_STATEMENTTEXT where pid = ;

スタックしたクエリを終了させる、またはブロックの原因となっている可能性のあるプロセスを終了させるには、次のようなクエリを実行します。

select pg_terminate_backend(pid);

クエリが別のキューにホップした

読み取りクエリが現在の WLM キューでのタイムアウト時間に達した、またはホップアクションを指定しているクエリモニタリングルールがある場合、クエリは実行のため次の WLM キューにプッシュされます。クエリがホップしたのかどうかを確認するには、クエリの実行中であれば STV_WLM_QUERY_STATE を使用します。クエリの実行完了後には、STL_WLM_QUERY を使用します。クエリが別のキューにホップするのを防ぐには、WLM キューでのアクションを中断させる WLM クエリモニタリングルールを設定します。クエリキューのホッピングの詳細については、「WLM クエリキューのホッピング」を参照してください。

ネットワークまたはファイアウォールの問題

Amazon Redshift サーバーで、自分のクライアントとの通信の問題が発生した場合、サーバーは上記の「クライアントへのリターン」状態でスタックしているのかもしれません。サーバーへのトラフィックをブロックする原因となっているネットワークコンポーネントとの競合がないかチェックしてください。これにはインバウンドのオンプレミスファイアウォールの設定、アウトバウンドのセキュリティグループのルール、またはアウトバウンドのネットワーク ACL ルールが含まれます。詳細については、「Amazon EC2 以外から接続する — ファイアウォールタイムアウトの問題」を参照してください。

クラスターに関連した問題

ハードウェアの問題など、クラスター自身に関連した問題も、まれではありますが、クエリがハングする原因となることがあります。Amazon Redshift コンソールでクラスターのステータスをチェックして、hardware-failure 状態になっていないか確認してください。クラスターがこの状態になっていて、シングルノードのクラスターである場合には、クラスターをスナップショットから復元してください。マルチノードのクラスターの場合、障害を起こしたノードは自動的に置き換えられます。


このページは役に立ちましたか? はい | いいえ

AWS サポートナリッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2017 年 04 月 11 日

更新: 2018 年 2 月 26 日