Amazon Redshift での VACUUM のパフォーマンスに関する問題のトラブルシューティング方法を教えてください。

最終更新日: 2020 年 8 月 26 日

Amazon Redshift クラスターでの VACUUM のパフォーマンスへの影響を心配しています。VACUUM の実行に時間がかかるのはなぜですか? また、Amazon Redshift クラスターで VACUUM を操作する場合、どのようなベストプラクティスを考慮する必要がありますか?

簡単な説明

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

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

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

解決方法

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 は、バックグラウンドで VACUUM DELETE 操作を自動的に実行します。VACUUM DELETE は、負荷が軽い期間中に実行するようにスケジュールされ、負荷が高い時間帯は一時停止します。DELETE ONLY 操作を実行することはめったにありません。

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 を頻繁に実行し、未ソート領域が大きなテーブルに貯まらないようにします。
    大きなテーブルにソートされていないデータが大量にある場合は、(CREATE TABLE AS を使って) ディープコピーを作成します。ディープコピーは、既存のテーブルで VACUUM SORT を実行するのではなく、新しいテーブルにデータをロードするのに役立ちます。
  • BOOST オプションを用いて VACUUM コマンドを実行します。BOOST オプションは、使用可能なメモリやディスク容量といった追加のリソースを VACUUM に割り当てます。BOOST オプションでは、VACUUM は 1 つのウィンドウで動作し、VACUUM 操作が行われている間に同時に削除および更新されないようにします。
    注: BOOST オプションを用いて VACUUM を実行すると、クエリのパフォーマンスが影響を受ける可能性があります。メンテナンス作業中やオフピーク時に VACUUM BOOST 操作を実行するのがベストプラクティスです。
  • VACUUM のパフォーマンスを向上させるために、大きなテーブルは時系列テーブルに分割します。場合によっては、時系列テーブルを使用すると、VACUUM を実行する必要性を満たすことができます。
  • 大きなテーブルには列圧縮タイプを選択します。行を圧縮すると、データを並べ替えるときに消費するディスク領域を減らします。

この記事はお役に立ちましたか?


請求に関するサポートまたは技術的なサポートが必要ですか?