Amazon Redshift での VACUUM のパフォーマンスに関する問題をトラブルシューティングするにはどうすればよいですか?

簡単な説明

VACUUM はリソースを大量に消費する操作で、以下によりスローダウンする可能性があります。

• ソートされていないデータの割合が高い
• テーブルが大きく、列が多すぎる
• インターリーブソートキーの使用状況
• VACUUM 使用が不規則またはまれ
• 同時テーブル、クラスタークエリ、DDL ステートメント、または ETL ジョブ

svv_vacuum_progress クエリを使用して、VACUUM 操作のステータスと詳細情報を確認します。次に、VACUUM のベストプラクティスに従ってトラブルシューティングを行い、将来問題が発生しないようにします。

解決方法

注: 次は、プロビジョニングされた Amazon Redshift クラスターに適用されます。次のシステムテーブルとクエリは Amazon Redshift Serverless では動作しません。

VACUUM オペレーションが進行中かどうかを確認するには、svv_vacuum_progress クエリを実行します。

dev=# SELECT * FROM svv_vacuum_progress;
table_name |          status                 | time_remaining_estimate
-----------+---------------------------------+-------------------------
 data8     |  Vacuum: initialize merge data8 | 4m 55s
(1 row)

svv_vacuum_progress クエリは、バキューム対象のテーブル名、バキュームのステータス、および完了までの推定残り時間も検証します。実行中のバキュームがない場合、svv_vacuum_progress クエリは最後に実行されたバキュームのステータスを表示します。

注: svv_vacuum_progress クエリは、結果を 1 行だけ返します。

バキューム対象のテーブルの詳細を確認します。WHERE 句でテーブル名とスキーマ名を指定します。

SELECT schema, table_id, "table", diststyle, sortkey1, sortkey_num, unsorted, tbl_rows, estimated_visible_rows, stats_off 
FROM svv_table_info 
WHERE "table" IN ('data8');

この出力例を次に示します。

Schema     | table_id | table | diststyle | sortkey1 | sortkey_num | unsorted | tbl_rows  | est_visible_rows | stats_off 
------------+----------+-------+-----------+----------+-------------+----------+-----------+------------------+-----------
 testschema | 977719   | data8 | EVEN      | order_id |  2          |    25.00 | 755171520 | 566378624        | 100.00

この出力から、sortkey1 列にはメインのソートキーが表示されます。

テーブルにインターリーブソートキーがある場合、この列には INTERLEAVED 状態が表示されます。

• sortkey_num 列には、ソートキーの列数が表示されます。
• ソートされていない列は、ソートする必要がある行の割合を示します。
• tbl_rows 列には、削除された行と更新された行を含む行の合計数が表示されます。
• estimated_visible_rows は、削除された行を除外している行の数です。
• 完全なバキューム (削除とソート) の後、tbl_rows と estimated_visible_rows の値は互いに似ていて、ソートされていない行が 0 になっているはずです。 注: テーブル内のデータはリアルタイムで更新されます。VACUUM の進行状況を確認するには、クエリの実行を続けます。ソートされていない行は、VACUUM が進むにつれて徐々に減少することに注意してください。ソートされていないデータの割合が高いかどうかを確認するには、特定のテーブルの VACUUM 情報を確認します。

次のクエリを実行し、前のクエリのテーブル ID を指定して、テーブルの VACUUM 情報を確認します。

SELECT table_id, status, rows, sortedrows, blocks, eventtime
FROM stl_vacuum
WHERE table_id=977719
ORDER BY eventtime DESC LIMIT 20;

この出力例を次に示します。

table_id |             status             |    rows    | sortedrows | blocks |         eventtime         
----------+--------------------------------+------------+------------+--------+----------------------------
   977719 | [VacuumBG] Finished            |  566378640 |          0 |  23618 | 2020-05-27 06:55:33.232536
   977719 | [VacuumBG] Started Delete Only | 1132757280 |  566378640 |  47164 | 2020-05-27 06:55:18.906008
   977719 | Finished                       |  566378640 |  566378640 |  23654 | 2020-05-27 06:46:04.086842
   977719 | Started                        | 1132757280 |  566378640 |  45642 | 2020-05-27 06:28:17.128345
(4 rows)

出力では、最新のイベントが最初にリストされ、次に古いイベントがソート順にリストされます。

• 最後に実行されたバキュームは、自動 VACUUM DELETE でした。これは、2020-05-27 06:55:18.906008 UTC に開始され、数秒で完了しました。
• このバキュームは、削除された行で占められた領域を解放しました。これは、バキュームが開始および完了したときに表示される行とブロックの数で確認できます。

VACUUM の開始から完了まで、テーブルが占有するブロック数に起きる変更に注意してください。

注: Amazon Redshift は、バックグラウンドでテーブルに対してバキュームソートとバキューム削除の操作を自動的に実行します。これらのバックグラウンド実行のバキュームは、負荷が軽い期間中に実行され、負荷が高い時間帯は一時停止します。このバキュームの自動実行により、バキュームコマンドを実行する必要性が軽減されます。

sortedrows 列には、テーブル内のソートされた行の数が表示されます。前回のバキュームでは、VACUUM DELETE 操作が自動的に行われたため、ソートは行われませんでした。削除対象としてマークされた行には、VACUUM 起動時と同じ数のソート済み行が表示されます。これは、アクティブな行がソートされていないためです。VACUUM DELETE が完了すると、ソートされた行が 0 であることを示します。

2020-05-27 06:28:17.128345 UTC から始まった最初のバキュームは、完全なバキュームを示しています。約 18 分後に削除された行とソートされた行から領域を解放しました。バキューム操作が完了すると、行とソートされた行に同じ値が出力に表示されます。これは、バキュームによって行が正常にソートされたためです。

すでに進行中のバキュームについては、引き続きパフォーマンスをモニタリングし、VACUUM のベストプラクティスを組み込みます。

VACUUM のベストプラクティス

VACUUM のパフォーマンスは、次のベストプラクティスで改善できます。

• VACUUM はリソースを大量に消費する操作であるため、オフピーク時に実行してください。
• オフピーク時には、wlm_query_slot_count を使用して、VACUUM 操作のキュー内の同時実行レベルを一時的に上書き します。
• 大きなテーブルの場合、最大 99% のしきい値パラメータで VACUUM 操作を実行します。
• VACUUM を実行する適切なしきい値と頻度を決定します。たとえば、100% のしきい値で VACUUM を実行するか、データを常にソートするのがお勧めです。Amazon Redshift クラスターのクエリパフォーマンスを最適化するアプローチを使用してください。
• VACUUM FULL または VACUUM SORT ONLY は、未ソートの多いリージョンが大きなテーブルで蓄積されないようにしながら、十分な回数実行します。
• 大きなテーブルにソートされていないデータが大量にある場合は、ディープコピーを実行します。ディープコピーを使用すると、既存のテーブルで VACUUM SORT を実行する代わりに、新しいテーブルにデータをロードできます。
• BOOST オプションを用いて VACUUM コマンドを実行します。BOOST オプションは、使用可能なメモリやディスク容量といった追加のリソースを VACUUM に割り当てます。BOOST オプションを使用すると、VACUUUM は 1 つのウィンドウで動作するので、VACUUM 操作中に削除および更新が同時に実行されることはありません。
  注: BOOST オプションを使用して VACUUM を実行すると、クエリのパフォーマンスに影響を与える可能性があります。VACUUM BOOST 操作は、メンテナンス作業中やオフピーク時にのみ実行するのがベストプラクティスです。
• VACUUM のパフォーマンスを向上させるために、大きなテーブルは時系列テーブルに分割します。場合によっては、時系列テーブルを使用すると、VACUUM を実行する必要性を満たすことができます。
• 大きなテーブルには列圧縮タイプを選択します。行を圧縮することで、データを並べ替えるときに消費するディスク領域を減らすことができます。
• VACUUM オペレーション後に ANALYZE コマンドを使用して統計を更新します。この統計情報は、クエリプランナーが最適なプランを選択する際に使用されます。

---