Amazon Redshift でのディスク使用率の増加または容量の枯渇をトラブルシューティングする方法を教えてください。

解決策

Amazon Redshift におけるディスク使用率増加または容量枯渇を解決するには、次のトラブルシューティング手順を実行します。

分散キーとソートキー

テーブルの分散方式、分散キー、ソートキーが正しく選択されているかどうかを確認します。分散が均衡していないテーブルでは、ノードのディスク容量が枯渇する可能性があります。分散形式が偏ったテーブルが存在する場合は、分散方式をより均一な分散に変更します。分散と行スキューは、クエリを実行する際、ストレージスキューと中間行セットに影響する可能性があります。

分散キーのカーディナリティを取得するには、次のクエリを実行します。

SELECT <distkey column>, COUNT(*)
 FROM <schema name>.<table with distribution skew>
 GROUP BY <distkey column>
 HAVING COUNT(*) > 1
 ORDER BY 2 DESC;

注: distkey column、schema name、table with distribution skew をテーブルの変数に置き換えてください。

ソートステップを回避するために、ORDER BY 句では SORT KEY 列を使用します。ソートステップはメモリを過剰に消費し、ディスクスピルを引き起こす可能性があります。詳細については、「ソートキー」を参照してください。

フィルターした結果セットにおいて、カーディナリティが高い列を選択してデータ分布を確認します。詳細については、「最適な分散方式の選出」を参照してください。

クエリ処理

割り当てられているクエリメモリをすべて確認します。クエリの処理中、中間クエリ結果は一時ブロックに保存される可能性があります。空きメモリが不足している場合、テーブルがディスクスピルを引き起こす場合があります。中間結果セットは圧縮されないため、空きディスク容量に影響します。詳細については、「クエリに割り当てられたメモリの不足」を参照してください。

デフォルトでは、Amazon Redshift は均一分散したテーブル構造を使用し、一時テーブルには列エンコーディングが行われません。SELECT... INTO ** 構文を使用する場合は、CREATE ステートメントを使用します。リサイズのパフォーマンス最適化に関する詳細については、「Amazon Redshift のパフォーマンス調整手法: トップ 10」のチップ #6** を参照してください。

クエリに割り当てられたメモリが不足している場合、SVL_QUERY_SUMMARY に is_diskbased 値が true であるステップが表示される可能性があります。次のクエリは、指定した期間におけるディスクスピルクエリの上位 20 件を識別します。

SELECT q.userid, q.query, q.starttime, q.endtime, m.query_temp_blocks_to_disk, btrim(querytxt)  
 FROM stl_query q JOIN SVL_QUERY_METRICS_SUMMARY m ON m.query = q.query
 WHERE m.query_temp_blocks_to_disk > 0
   AND starttime BETWEEN '2025-01-01 00:00:00' AND '2025-01-02 00:00:00'
 ORDER BY m.query_temp_blocks_to_disk DESC
 LIMIT 20;

この問題を解決するには、クエリスロット数とクエリに割り当てるメモリを増やします。

使用率の予期せぬ急増が発生した場合は、次のクエリを実行し、ディスクスピルクエリの上位 20 件を識別します。

SELECT a.userid, a.query, a.blocks_to_disk, trim(b.text) as text
 FROM stv_query_metrics a, stv_inflight b
 WHERE a.query = b.query
   AND a.segment = -1
   AND a.step_type = -1
   AND a.max_blocks_to_disk > 0
 ORDER BY 3 DESC
 LIMIT 20;

出力において、列値 blocks_to_disk を参照してディスクスピルを特定します。過剰なスピルが発生するクエリを完全終了し、再度実行する前に追加メモリを割り当てます。

また、WLM クエリ監視ルールを使用することで、高負荷プロセスに対処し、I/O 負荷が高いクエリを特定することも可能です。

VARCHAR(MAX) 列を含むテーブル

VARCHAR または CHARACTER VARYING 列において、データをディスクに保存する際に省略される可能性のある、末尾スペースが存在しないか確認します。クエリの処理時、末尾スペースはメモリ内の全長を占める可能性があります。VARCHAR と CHARACTER VARYING の最大値は、65535 バイトです。列サイズは、可能な限り最小化することをおすすめします。

列幅が最大であるテーブルのリストを生成するには、次のクエリを実行します。

SELECT database, schema || '.' || "table" AS "table", max_varchar
 FROM svv_table_info
 WHERE max_varchar > 150 ORDER BY 2;

幅の広い VARCHAR テーブル列の真の幅を特定し、表示するには、次のクエリを実行します。

SELECT max(octet_length (rtrim(column_name))) FROM table_name;

このクエリ出力を参照し、データ長がユースケースに合っているかどうかを確認します。列長が最大に達しており、ニーズを上回っている場合は、長さを必要最小限に調整します。

詳細については、「Amazon Redshift でのテーブル設計のベストプラクティス」を参照してください。

列の高圧縮

ソートキー以外のすべての列をエンコードするには、ANALYZE COMPRESSION または自動テーブル最適化を実行します。列エンコーディングの利用をおすすめします。

メンテナンス操作

Amazon Redshift データベースのデータベーステーブルを定期的に分析し、バキューム処理を実行します。統計情報が欠けたテーブルに対して実行されるクエリを特定します。次に、Amazon Redshift が不要なテーブル列をスキャンすることを防ぐために、クエリが統計情報が欠けたテーブルに対して実行されないよう設定します。

注: メンテナンス操作 (例: VACUUM、DEEP COPY) は、ソート操作に一時ストレージ容量を使用するため、ディスク使用率の急増を引き起こす可能性があります。

たとえば、次のクエリは Amazon Redshift の古い統計情報を特定します。

SELECT table_id, database, schema, "table", stats_off, size
 FROM svv_table_info
 WHERE stats_off > 10
 ORDER BY size DESC;

さらに、ANALYZE コマンドを実行し、テーブル情報を確認、分析します。

デカルト積 (クロス結合)

クエリの EXPLAIN プランを使用し、デカルト積を含むクエリを探します。デカルト積は関連のないクロス結合であり、ブロック数の増加につながる可能性があります。クロス結合は、メモリ使用率やディスクスピルするテーブル数の増加を引き起こす可能性があります。クロス結合に共通の JOIN 条件が含まれない場合、結合が原因で 2 テーブルのデカルト積が生じます。一方のテーブルのすべての行は、他方のテーブルのすべての行に結合されます。

また、クロス結合は入れ子ループ結合として実行されるため、処理時間が増加する可能性があります。入れ子ループ結合は、全体的なディスク使用率の急増を引き起こします。詳細については、「入れ子ループを含むクエリを特定する」を参照してください。

最小テーブルサイズ

個別のテーブルは、クラスターによってサイズが異なる場合があります。最小テーブルサイズは、列の数と、テーブルに SORTKEY およびデータが含まれたスライス数が存在するかどうかにより決定されます、。直近に Amazon Redshift クラスターをリサイズした場合、スライス変更が原因で全体的な空きディスク容量が変化する可能性があります。Amazon Redshift は、各テーブルが使用するテーブルセグメントもカウントします。詳細については、「Amazon Redshift クラスター内のテーブルが消費するディスクストレージ容量が、想定よりも多いか少ない原因を教えてください」を参照してください。

トゥームストーンブロック

WRITE トランザクションが Amazon Redshift テーブルに行われた際、読み取り操作が同時実行中の場合、トゥームストーンブロックが発生します。Amazon Redshift は、同時読み取り操作の一貫性を維持するために、書き込み操作の前にブロックを保持します。Amazon Redshift ブロックは変更できません。Insert、Update、Delete アクションを実行するたびに、ブロックセットが新規作成され、古いブロックはトゥームストーンとマークされます。

長時間実行テーブルトランザクションが原因で、トゥームストーンがコミット段階でクリアされない場合があります。同時実行される ETL ロード数が過剰な場合も、トゥームストーンをクリアできない可能性があります。Amazon Redshift はトランザクションが開始された時点からデータベースを監視するため、データベースに書き込まれたすべてのテーブルにもトゥームストーンブロックが保持されます。長時間実行テーブルトランザクションが複数ロードにわたり頻繁に発生する場合、トゥームストーンの蓄積が "Disk Full" エラーを引き起こす可能性があります。

アクティブな長時間実行クエリが存在する場合は、commit コマンドを実行してクエリを完全終了し、後続のすべてのブロックを解放します。

begin;
create table a (id int);
insert into a values(1);
commit;
drop table a;

トゥームストーンブロックを確認するには、次のクエリを実行します。

SELECT trim(name) as tablename, count(case when tombstone > 0 then 1 else null end) as tombstones
 FROM svv_diskusage
 GROUP BY 1
 HAVING count(case when tombstone > 0 then 1 else null end) > 0
 ORDER BY 2 DESC;

大規模ファイルのコピー

空き容量が十分な場合も、COPY 操作に "Disk Full error" が返される場合があります。ソート操作がディスクスピルし、一時ブロックが生成された場合、このエラーが発生します。

"Disk Full" エラーが発生する場合は、STL_DISK_FULL_DIAG テーブルを確認します。一時ブロックおよび、エラーの原因となったクエリ ID を確認します。

SELECT
  '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,
  node_num,
  query_id,
  temp_blocks
 FROM stl_disk_full_diag;

詳細については、「Amazon Redshift におけるデータ読み取りのベストプラクティス」を参照してください。

コンシューマークラスターでのデータ共有クエリブロック

コンシューマークラスターでデータ共有クエリを実行すると、そのクエリに関連するデータブロックは PercentageDiskSpaceUsed メトリクスにカウントされます。クラスター再起動などの要因では、これらのデータブロックは PercentageDiskSpaceUsed メトリクスから除外されます。この想定動作に対しては、追加の措置は必要ありません。

ディスク容量を確認する

Amazon Redshift コンソールの [パフォーマンス] タブでディスク容量のパーセンテージを確認します。

関連情報

Amazon Redshift のパフォーマンス