この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
当エントリは先日投稿したシリーズ『『Amazon Redshiftのパフォーマンスチューニングテクニック Top 10』手順実践』の第8弾です。課題#8の『コミットキューのウエイト』について内容を見て行きたいと思います。
参照ブログエントリに記載されている様に、必要以上のコミットを実行している場合、そのアクションがクラスタの処理パフォーマンスに影響を与えている可能性があります。当該トピックではその問題について切り込んでいる内容となります。
Amazon Redshiftはトランザクション処理のクエリーよりも、分析クエリー用にデザインされています。相対的に見てCOMMITのコストは高く、必要以上にCOMMITを実行することは、コミットキューへのアクセスをウエイトさせることになります。
もしデータベースで必要以上にCOMMITを実行した場合、コミットキューでのウエイトが増加し始めます。これはcommit_stats.sql 管理スクリプトで確認することができます。このスクリプトは過去2日間での最長のキュー長と、クエリ時間を表示します。もしコミットキューをウエイトするクエリーがあった場合は、何度もCOMMITを実行しているセッション、例えばETLジョブで処理経過をロギングしたり、非効率的なをデータロード（次項も参照）を行っているといったセッションを探しあててください。
問題箇所を特定する為の第1手段として、以下のSQL文が用意されています。
上記SQL文を実行した際の結果がこちら。ただこれ、どのクエリが該当しているものなのか、若干分かり辛いですね...。(クエリのstartqueueの時間で特定するのかしら)
startqueue | node | queue_time | commit_time | queuelen
----------------------------+------+------------+-------------+----------
2016-08-26 23:32:08.376709 | -1 | 232 | 4775 | 1
2016-08-26 23:47:05.463922 | -1 | 66 | 0 | 1
2016-08-26 23:20:25.474934 | -1 | 1708 | 2289 | 0
2016-08-26 18:45:02.200407 | -1 | 1107 | 5477 | 0
2016-08-26 23:35:35.79235 | -1 | 720 | 3911 | 0
2016-08-26 22:46:37.453379 | -1 | 365 | 3433 | 0
2016-08-26 20:36:33.491195 | -1 | 304 | 1051 | 0
2016-08-27 02:00:34.688528 | -1 | 259 | 1228 | 0
2016-08-26 18:44:03.431261 | -1 | 97 | 5021 | 0
2016-08-27 09:23:42.488798 | -1 | 77 | 1114 | 0
2016-08-27 00:03:02.318625 | -1 | 72 | 1065 | 0
2016-08-26 23:47:11.521817 | -1 | 55 | 0 | 0
2016-08-26 23:32:33.598204 | -1 | 53 | 10628 | 0
2016-08-26 23:32:44.906723 | -1 | 50 | 2769 | 0
:コミットされるトランザクションID(STL_COMMIT_STATS.xid)を追加してみました。該当するクエリ群を参照させるのはSVL_STATEMENTTEXT辺りのxidで連結させて引っ張ってこれるのではと思います。
select
xid,
startqueue,
node,
datediff(ms,startqueue,startwork) as queue_time,
datediff(ms, startwork, endtime) as commit_time,
queuelen
from
stl_commit_stats
where
startqueue >= dateadd(day, -2, current_Date)
order by
queuelen desc,
queue_time desc;
xid | startqueue | node | queue_time | commit_time | queuelen
----------+----------------------------+------+------------+-------------+----------
0 | 2016-08-26 23:32:08.376709 | -1 | 232 | 4775 | 1
13790844 | 2016-08-26 23:47:05.463922 | -1 | 66 | 0 | 1
13790051 | 2016-08-26 23:20:25.474934 | -1 | 1708 | 2289 | 0
13786426 | 2016-08-26 18:45:02.200407 | -1 | 1107 | 5477 | 0
13790554 | 2016-08-26 23:35:35.79235 | -1 | 720 | 3911 | 0
13789577 | 2016-08-26 22:46:37.453379 | -1 | 365 | 3433 | 0
13788056 | 2016-08-26 20:36:33.491195 | -1 | 304 | 1051 | 0
13792443 | 2016-08-27 02:00:34.688528 | -1 | 259 | 1228 | 0
13786416 | 2016-08-26 18:44:03.431261 | -1 | 97 | 5021 | 0
13797228 | 2016-08-27 09:23:42.488798 | -1 | 77 | 1114 | 0
13791064 | 2016-08-27 00:03:02.318625 | -1 | 72 | 1065 | 0
13790848 | 2016-08-26 23:47:11.521817 | -1 | 55 | 0 | 0
13790473 | 2016-08-26 23:32:33.598204 | -1 | 53 | 10628 | 0
13790474 | 2016-08-26 23:32:44.906723 | -1 | 50 | 2769 | 0
13790616 | 2016-08-26 23:36:11.541912 | -1 | 50 | 5392 | 0
13790021 | 2016-08-26 23:18:09.685151 | -1 | 49 | 1331 | 0RedshiftのCommit周りの情報については、以下エントリにも踏み込んだ情報がまとめられていますので併せてご参照ください。
まとめ
以上、『Amazon Redshiftのパフォーマンスチューニングテクニック Top 10』トピック8つめ、"コミットキューのウエイト"に関する対処方法のご紹介でした。9つ目以降のトピックについても、こんな感じで読み解きつつ実践して行きたいと思います。
4
