OOM (メモリ不足) エラーは、クエリが Hologres で利用可能なメモリを超えた場合に発生します。このトピックでは、メモリ使用量を監視し、OOM エラーを特定して解決する方法について説明します。
メモリ消費量の分析
-
メモリ消費量の表示
-
総消費量： Hologres コンソールには、すべてのノードにわたる集計されたメモリ消費量が表示されます。詳細については、「モニタリングメトリック」をご参照ください。
-
クエリごとの消費量:
memory_bytesフィールドは、クエリごとのメモリ消費量を概算します。この値は不正確な場合があります。詳細については、「スロークエリログの取得と分析」をご参照ください。
-
-
高いメモリ使用量への対処
Hologres コンソールで全体的なメモリ使用量を監視します (「モニタリングメトリック」をご参照ください)。持続的に 80% を超える使用率は高い状態です。Hologres はメタデータとキャッシュのためにメモリを事前割り当てするため、30%～50% のアイドル時の使用率は正常です。100% に近い使用率は、安定性とパフォーマンスを低下させます。
-
原因
-
メタデータによる高いメモリ消費
メタデータのメモリはテーブル数とともに増加し、タスクが実行されていない場合でも高い使用率を引き起こす可能性があります。各テーブルグループ内のテーブル数 (パーティションを含み、外部テーブルを除く) を 10,000 未満に維持してください。テーブルグループ内のシャードが多すぎると、フラグメンテーションとメタデータのオーバーヘッドが増加します。
-
計算による高いメモリ消費
クエリの高いメモリ使用量は、通常、大量のデータボリュームのスキャン、または複数の
COUNT DISTINCT関数、複雑なJOIN操作、複数列に対するGROUP BY、あるいはウィンドウ関数などの複雑な操作に起因します。 -
Other モジュールでの高いメモリ使用量
メモリ監視で Other モジュールのメモリ使用量が急激に増加し、全体的なメモリ使用率も高い場合、原因は実験的なパラメータ
hg_experimental_enable_hash_partitioned_sort_v2である可能性があります。このパラメータは、ウィンドウ行番号フィルタリングのためのハッシュパーティションソートアルゴリズムを有効にします。このアルゴリズムには既知のリソース消費の問題があり、分類されていないメモリが Other モジュールカテゴリに蓄積される原因となります。解決策
次の SQL 文を実行して、この実験的パラメーターを無効化してください：
SET hg_experimental_enable_hash_partitioned_sort_v2 = off;このパラメーターを無効にした後、インスタンスのメモリ使用量を監視してください。Other モジュールに起因するメモリは、通常のレベルまで減少するはずです。
-
-
主な影響
-
安定性
特にメタデータによるメモリの過剰な消費は、クエリで使用可能なメモリを減少させ、
SERVER_INTERNAL_ERROR、ERPC_ERROR_CONNECTION_CLOSED、またはTotal memory used by all existing queries exceeded memory limitationなどの散発的なエラーを引き起こす可能性があります。 -
パフォーマンス
過剰なメタデータによる高いメモリ使用量は、キャッシュスペースを枯渇させ、キャッシュヒット率を低下させ、クエリのレイテンシを増加させます。
-
-
解決策
-
過剰なメタデータが原因でメモリ使用量が多くなった場合は、
hg_table_infoテーブルを使用してテーブルを管理します。詳細については、「テーブル統計のクエリと分析」をご参照ください。不要なデータやテーブルを削除し、不要なパーティションを削減してメモリを解放します。 -
高いメモリ使用量が計算によって引き起こされる場合： 書き込みとクエリのユースケースごとに SQL を個別に最適化してください。詳細については、「クエリ中のOOMエラーの解決」および「データインポート/エクスポート中のOOMエラーの解決」をご参照ください。
-
一般的な解決策： コンピューティングリソースとストレージリソースをスケールアップしてください。詳細については、「インスタンスリスト」をご参照ください。
-
-
OOM エラーの特定
OOM エラーは、計算メモリが割り当てられた制限 (例：20 GB 以上) を超えたときに発生します。一般的なエラーメッセージは次のとおりです：
Total memory used by all existing queries exceeded memory limitation.
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100エラーメッセージは次のように解釈します：
-
queries=(query_id, memory_used_by_query)queries=(2031xxxx,184yy)などの各エントリは、クエリごとのメモリ消費量を示します。 たとえば、queries=(2031xxxx,18441803528)は、クエリquery_id=2031xxxxが単一ノードで約 18 GB を消費したことを意味します。 メモリ消費量の上位 5 件のクエリが一覧表示されます。 詳細については、「低速クエリログの取得と分析」をご参照ください。 -
使用量/上限: xy1/xy2compute_memory_used_on_node/compute_memory_limit_on_nodeをバイト単位で示します。Usedは、そのノードで実行中のすべてのクエリによって消費されるコンピューティングメモリの合計です。たとえば、Used/Limit: 33288093696/33114697728は、クエリが 33.2 GB を使用し、33.1 GB の上限を超えて OOM が発生したことを意味します。 -
quota/sum_quota: zz/100zzは、リソースグループに割り当てられるインスタンスリソースが全体に占める割合です。例えば、quota/sum_quota: 50/100は、リソースグループがインスタンスの総リソースの 50% を使用していることを意味します。
OOM エラーの基本的な原因
Hologres は、クエリ効率を最適化するためにインメモリ計算を優先します。メモリが不足したときにディスクへのスピルを行うシステムとは異なり、Hologres はクエリが利用可能なメモリを超えると直接 OOM エラーを発生させます。
メモリ割り当てと制限
Hologres インスタンスは分散システムとして動作し、インスタンスの仕様によって数が異なる複数のノードで構成されます。詳細については、「インスタンス管理」をご参照ください。
各ノードには通常、16 個の vCPU と 64 GB のメモリがあります。いずれかの単一ノードでメモリが枯渇すると、OOM エラーが発生します。64 GB は、クエリ計算、バックエンドプロセス、キャッシュ、およびメタデータ用に分割されます。V1.1.24 より前では、計算メモリは 20 GB に制限されていました。V1.1.24 以降では、メタデータの消費が少ない場合に、利用可能なメモリがクエリに動的に割り当てられます。
クエリ中の OOM エラーの解決
-
原因：
-
不適切な実行計画： 不正確な統計情報、不適切な結合順序、またはその他の最適化の問題が原因である可能性があります。
-
高いクエリの同時実行： 多くのクエリが同時に大量のメモリを消費している状態です。
-
複雑なクエリ： 本質的に複雑なクエリ、または大量のデータをスキャンするクエリです。
-
UNION ALL操作：UNION ALLを含むクエリは、エグゼキュータの並列度を増加させ、メモリ使用量の増加につながることがあります。 -
不十分なリソースグループの割り当て： リソースグループは設定されているものの、割り当てられたリソースが不十分な状態です。
-
データスキューまたはシャードプルーニング： これらは、不均衡な負荷と特定のノードへの高いメモリプレッシャーを引き起こす可能性があります。
-
-
分析と解決策：
-
原因： 不十分なリソースグループの割り当て
解決策： サーバーレスコンピューティング機能を使用して、インスタンスの専用リソースを追加の計算能力で補完します。概要と使用方法については、「サーバーレスコンピューティング」および「サーバーレスコンピューティングの操作」をご参照ください。
Hologres V3.0 以降では、クエリキューがサーバーレスコンピューティングリソース上で OOM クエリを自動的に再実行します。詳細については、「大規模クエリの制御」をご参照ください。
-
原因： 不適切な実行計画
-
タイプ 1： 不正確な統計情報
EXPLAIN <SQL>を実行して、実行計画を表示します。rows=1000は、統計情報が欠落しているか不正確であることを示しており、過剰なリソースを消費して OOM エラーを引き起こす非効率的な実行計画につながります。tt=# explain select count(1) from tmp join tmp1 on tmp.a = tmp1.b; QUERY PLAN ---------------------------------------------------------------------------------- Partial Aggregate (cost=0.00..10.11 rows=1 width=8) -> Gather Motion (cost=0.00..10.11 rows=10 width=8) -> Partial Aggregate (cost=0.00..10.11 rows=10 width=8) -> Hash Join (cost=0.00..10.11 rows=1 width=1) Hash Cond: (tmp.a = tmp1.b) -> Parallelism (Gather Exchange) (cost=0.00..5.04 rows=1000 width=1) -> DecodeNode (cost=0.00..5.04 rows=1000 width=1) -> Seq Scan on tmp (cost=0.00..5.01 rows=1000 width=1) -> Hash (cost=5.04..5.04 rows=1000 width=1) -> Parallelism (Gather Exchange) (cost=0.00..5.04 rows=1000 width=1) -> DecodeNode (cost=0.00..5.04 rows=1000 width=1) -> Seq Scan on tmp1 (cost=0.00..5.01 rows=1000 width=1) Optimizer: HQO version 0.8.0 (13 rows)解決策は次のとおりです：
-
ANALYZE <tablename>コマンドを実行して、テーブルの統計情報を更新します。 -
自動分析を有効にして、統計情報を自動的に更新してください。詳細については、「ANALYZEとAUTO ANALYZE」をご参照ください。
-
-
タイプ 2： 不適切な結合順序
ハッシュ結合では、小さい方のテーブルをビルド側にする必要があります。
EXPLAIN <SQL>を使用して実行計画を確認します。大きい方のテーブルでハッシュテーブルをビルドする場合、結合順序が非効率になり、OOM が発生する可能性があります。主な理由:-
テーブル統計が陳腐化しています。例えば、上位テーブルの統計が更新されなかったため、
rows=1000となっています。実行計画では、Hash Left Join の左側にある Result ノードの推定行数はわずか 1,000 ですが、右側のハッシュビルド側の推定行数は 6,754,108,416 (約 67.5 億) にもなります。この大きな食い違いは、大きい方のテーブルがハッシュテーブルのビルドに使用されたことを示しています。
Gather (cost=0.00..56428622.14 rows=6754109416 width=496) -> Insert (cost=0.00..49020180.01 rows=6754109416 width=496) -> Result (cost=0.00..79269.98 rows=6754109416 width=742) -> Hash Left Join (cost=0.00..54211.24 rows=6754109416 width=660) Hash Cond: (row_pk = dws_tb_crm_itm_prf_exp_analysis_nd.row_pk) -> Result (cost=0.00..7.03 rows=1000 width=600) -> Redistribution (cost=0.00..6.01 rows=1000 width=496) -> Result (cost=0.00..6.00 rows=1000 width=496) Filter: ((ds = ‘${bizdate}’::text) AND (NOT (row_pk IS NULL))) -> Forward (cost=0.00..6.00 rows=1000 width=504) -> Sequence (cost=0.00..5.00 rows=1000 width=504) -> Partition Selector for dws_tb_crm_itm_prf_exp_analysis_nd_extl (dynamic scan id: 1) (cost=10.00..100.00 rows=100 width=4) Partitions selected: 0 (out of 33) -> DynamicSeqScan (cost=0.00..5.00 rows=1000 width=504) -> Hash (cost=11717.79..11717.79 rows=6754108416 width=60) -> Exchange (Gather Exchange) (cost=0.00..11717.79 rows=6754108416 width=60) -> Decode (cost=0.00..2755.96 rows=6754108416 width=60) -> Seq Scan on dws_tb_crm_itm_prf_exp_analysis_nd (cost=0.00..871.47 rows=6754108416 width=60) Optimizer: HQO version 0.10.0 (19 rows) -
オプティマイザーが最適な実行計画を生成できなかった場合
解決策：
-
最新の統計情報を確保するために、結合に関与するすべてのテーブルで
ANALYZE <tablename>を実行します。これにより、オプティマイザが正しい結合順序を決定するのに役立ちます。 -
ANALYZE <tablename>を実行しても結合順序が正しくない場合は、GUC パラメーターを調整します。optimizer_join_order = queryを設定し、オプティマイザが SQL 文で指定された結合順序に強制的に従うようにします。このアプローチは、複雑なクエリに特に適しています。SET optimizer_join_order = query; SELECT * FROM a JOIN b ON a.id = b.id; -- テーブル b がハッシュテーブルのビルド側として使用されます。必要に応じて、結合順序ポリシーを調整することもできます。
パラメーター
説明
set optimizer_join_order = <value>
このパラメーターは、オプティマイザーの結合順序アルゴリズムを制御します。有効な値：
-
query：Join Order 変換を実行せず、結合は SQL クエリで指定された順序で厳密に実行されます。この設定では、オプティマイザーのオーバーヘッドが最も低くなります。 -
greedy：グリーディアルゴリズムを使用して、考えられる結合順序を探索します。このオプションでは、中程度のオプティマイザのオーバーヘッドが発生します。 -
exhaustive(デフォルト): Join Order 変換に動的計画法アルゴリズムを使用します。最適な実行計画の生成を目指しますが、オプティマイザのオーバーヘッドは最も高くなります。
-
-
-
タイプ 3： 不適切なハッシュテーブルの推定
ハッシュ結合では、小さい方の入力でハッシュテーブルを構築すべきです。しかし、クエリの複雑さや不正確な統計情報により、システムがビルド側の入力として大きい方のリレーションを選択し、OOM をトリガーする非常に大きなハッシュテーブルを作成することがあります。
Hash (cost=727353.45..627353.35 , rows=970902134 width=94)はビルド入力を表し、rows=970902134はハッシュテーブルを構築するための推定データ量を示します。実際のテーブルに含まれるデータがこれより少ない場合、推定は不正確です。実行計画の最下部にある Hash ノードは、推定行数が
rows=970902134(約 9 億 7000 万行) と非常に高くなっており、これはビルド側のデータ量が大幅に過大に見積もられているか、または誤って選択されていることの典型的な兆候です。-> Broadcast (cost=0.00..5.17 rows=119488 width=16) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=16) -> Decode (cost=0.00..5.10 rows=1867 width=16) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=16) -> Hash (cost=5.17..5.17 rows=119488 width=16) -> Broadcast (cost=0.00..5.17 rows=119488 width=16) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=16) -> Decode (cost=0.00..5.10 rows=1867 width=16) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=16) -> Hash (cost=5.13..5.13 rows=119488 width=8) -> Broadcast (cost=0.00..5.13 rows=119488 width=8) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1867 width=8) -> Decode (cost=0.00..5.10 rows=1867 width=8) -> Seq Scan on xxx (cost=0.00..5.00 rows=1867 width=8) -> Hash (cost=5.10..5.10 rows=896 width=3) -> Broadcast (cost=0.00..5.10 rows=896 width=3) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=14 width=3) -> Decode (cost=0.00..5.10 rows=14 width=3) -> Seq Scan on xxx (cost=0.00..5.00 rows=14 width=3) -> Hash (cost=627353.45..627353.45 rows=970902134 width=94) -> Partial HashAggregate (cost=0.00..627353.45 rows=970902134 width=94)解決策：
-
統計情報の検証: サブクエリのテーブル統計情報が最新かつ正確であるかを確認します。そうでない場合は、
ANALYZE <tablename>を実行して更新します。 -
ハッシュテーブル推定の無効化： 次のパラメーターを使用して、実行エンジンのハッシュテーブル推定をオフにしてください：
説明このパラメーターのデフォルトは
offです。ただし、特定のチューニングシナリオで有効になっている可能性があります。現在有効になっている場合は、必ずoffに戻してください。SET hg_experimental_enable_estimate_hash_table_size =off;
-
-
タイプ 4： 大規模テーブルのブロードキャスト
ブロードキャストはすべてのシャードにデータをコピーするため、シャード数が少ない小さなテーブルに対してのみ効率的です。結合中、ビルド側の入力はすべてのシャードにブロードキャストされます。大規模なデータセットや過剰なシャード数は、大量のメモリを消費し、OOM エラーを引き起こす可能性があります。
たとえば、8,000 万行のテーブルが、実行計画では推定 1 行としか表示されないことがあります。実際には 8,000 万行すべてがブロードキャストされるため、過剰なメモリを消費し、OOM をトリガーします。
Gather (cost=0.00..119000614.54 rows=495989952 width=5537) -> Insert (cost=0.00..112801537.07 rows=495989952 width=5537) -> Redistribution (cost=0.00..428813.57 rows=991979904 width=2320) -> Result (cost=0.00..338771.55 rows=991979904 width=2320) -> Result (cost=0.00..338771.55 rows=991979904 width=2320) -> Hash Left Join (cost=0.00..310003.14 rows=991979904 width=5561) Hash Cond: ((olap_event_1480807263997566978.pub_distinct_id = olap_event_1480807263997566978_new.pub_distinct_id) AND (olap_event_1480807263997566978.pub_event_name = olap_event_1480807263997566978_new.pub_event_name) AND (olap_event_1480807263997566978.uuid = olap_event_1480807263997566978_new.uuid)) -> Exchange (Gather Exchange) (cost=0.00..68102.40 rows=495989952 width=5537) -> Decode (cost=0.00..65774.92 rows=495989952 width=5537) -> Seq Scan on olap_event_1480807263997566978 (cost=0.00..1923.43 rows=495989952 width=5537) -> Hash (cost=5.10..5.10 rows=80 width=24) -> Broadcast (cost=0.00..5.10 rows=80 width=24) -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1 width=24) -> Decode (cost=0.00..5.10 rows=1 width=24) -> Seq Scan on olap_event_1480807263997566978_new (cost=0.00..5.00 rows=1 width=24) Optimizer: HQO version 1.1.0解決策：
-
実行計画の推定行数が実際と一致するかどうかを確認します。一致しない場合は、
ANALYZE tablenameを実行して統計情報を更新します。 -
次の GUC パラメーターを使用してブロードキャストを無効にし、再配布オペレーターとして書き換えてください。
SET optimizer_enable_motion_broadcast = off;
-
-
-
原因： 高いクエリの同時実行
QPS が大幅に急増するか、または OOM エラーで
HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy);が表示され、各クエリが最小限のメモリしか使用していない場合、高い同時実行性が原因である可能性が高いです。 解決策:-
書き込み同時実行数の削減： 書き込み操作が原因である場合は、その同時実行数を減らしてください。詳細については、「データインポート/エクスポート中のOOMエラーの解決」をご参照ください。
-
読み書き分離の実装： プライマリインスタンスとセカンダリインスタンス (共有ストレージ) を使用した読み書き分離アーキテクチャをデプロイしてください。
-
インスタンスのコンピューティング仕様を増強してください。
-
-
原因： 複雑なクエリ
単一のクエリがその複雑さや大量のデータ量のために OOM をトリガーする場合、以下のアプローチを検討してください：
-
データの事前計算： Hologres 内での大規模な ETL 操作を避けるために、事前計算されたデータを Hologres に書き込んでください。
-
フィルター条件を追加してください。
-
SQL の最適化： Fixed Plan や Count Distinct の最適化などのテクニックを使用してください。詳細については、「内部テーブルのクエリパフォーマンスの最適化」をご参照ください。
-
-
原因： UNION ALL
以下に示すように、SQL 文に多数の
UNION ALLサブクエリが含まれていると、エグゼキュータはそれらを並行して処理するため、メモリに過負荷がかかり OOM エラーが発生する可能性があります。subquery1 UNION ALL subquery2 UNION ALL subquery3 ...解決策： 次のパラメーターを使用して直列実行を強制し、OOM エラーを緩和してください。これによりクエリのパフォーマンスが低下することに注意してください。
SET hg_experimental_hqe_union_all_type=1; SET hg_experimental_enable_fragment_instance_delay_open=on; -
原因： 不適切なリソースグループ設定
OOM エラーでは、
memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100と報告されます。zz が小さい値 (たとえば、10 (割り当てられたリソースのわずか 10%) など) である場合、そのグループ内のクエリのメモリは制限され、OOM が発生する可能性が高くなります。AcquireOrRelease] HGERR code 53200 HGERR msge Total memory used by all existing queries exceeded memory limitation. HGERR detl memory usage for existing queries=(7001xxx5,4367295472)(673125xxx9,1701576)(6731xxx3,3590736)(6731xxx5,3510024)(673116xxx,3088256) Used/Limit: 4408213504/42552795136 quota/sum_quota: 10/100.解決策: リソースグループのクォータをリセットします。各リソースグループに、インスタンスの総リソースの少なくとも
30%を割り当てます。 -
原因： データスキューまたはシャードプルーニング
全体的なメモリ使用量が低いにもかかわらず OOM が発生する場合、データスキューまたはシャードプルーニングによって特定のノードにメモリプレッシャーが集中している可能性があります。
説明シャードプルーニングは、すべてのシャードではなく、シャードのサブセットのみをスキャンするクエリ最適化技術です。
-
データスキューを確認するには、次の SQL クエリを使用します。
hg_shard_idは、各行がどのシャードに格納されているかを示す、すべてのテーブルの組み込みの隠しフィールドです。SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id; -
シャードプルーニングの確認: 実行計画でシャードプルーニングの形跡を確認します。 たとえば、シャードセレクターに
l0[1]と表示されている場合、そのクエリでは特定の 1 つのシャードのデータのみが選択されたことを意味します。-- 配布キーは x です。フィルター条件 x=1 に基づいて、シャードを迅速に特定できます。 SELECT count(1) FROM bbb WHERE x=1 GROUP BY y;QUERY PLAN -------------------------------------------------------------- Result (cost=0.00..5.10 rows=1 width=8) -> HashAggregate (cost=0.00..5.10 rows=1 width=8) Group Key: y -> Exchange (Gather Exchange) (cost=0.00..5.10 rows=1 width=4) -> Decode (cost=0.00..5.10 rows=1 width=4) -> Seq Scan on bbb (cost=0.00..5.00 rows=1 width=4) Filter: (x = 1) Shard Selector(Eagerly): ->: l0 [1] Optimizer: HQO version 1.3.0 (10 rows)
解決策：
-
データスキューを防ぐために、適切な配布キーを設計してください。
-
ビジネスロジックが本質的にデータスキューを引き起こす場合は、アプリケーションロジックを適宜変更してください。
-
-
原因： 高カーディナリティの多段階 GROUP BY
Hologres V3.0 以降では、
GROUP BY列が分散キーと一致しない (分散キーがGROUP BYキーのサブセットではない) 場合、高カーディナリティデータに対する多段階集計で OOM が発生する可能性があります。各同時実行インスタンスが大規模なハッシュテーブルを維持し、メモリプレッシャーが高くなるためです。これを軽減するには、次のパラメーターを設定します。-- GUC パラメーターを使用して、集計ハッシュテーブルの最大行数を設定します。次の SQL 文は、partial_agg_hash_table が最大 8192 行を持つことができることを示します。デフォルト値は 0 で、制限がないことを示します。 SET hg_experimental_partial_agg_hash_table_size = 8192;
-
データインポート/エクスポート中の OOM エラーの解決
OOM エラーは、内部テーブル間、外部テーブルとのやり取り、MaxCompute からのインポートなど、Hologres でのデータ転送中に発生する可能性があります。
-
解決策 1： インポートとエクスポートにサーバーレスコンピューティングを使用する
サーバーレスコンピューティングを使用して、インポートおよびエクスポートタスクのためにインスタンスのリソースを補完し、リソースの競合を回避してください。概要については、「サーバーレスコンピューティング」をご参照ください。使用方法については、「サーバーレスコンピューティングの操作」をご参照ください。
-
解決策 2： 幅の広いテーブルまたは列のスキャン同時実行数を制御する
MaxCompute のインポートでは、幅の広いテーブルや列と高いスキャン同時実行数が組み合わさることで、OOM エラーが発生する可能性があります。次のパラメーターを使用して同時実行数を制御してください。
-
幅の広いテーブルのスキャン同時実行数を制御する (一般的なシナリオ)
説明SQL 文と一緒に次のパラメーターを適用してください。最初の 2 つのパラメーターを優先してください。OOM エラーが解決しない場合は、それらの値をさらに減らしてください。
-- 外部テーブルにアクセスする際の最大同時実行数を設定します。デフォルト値はインスタンスの vCPU 数と同じです。最大値は 128 です。特にデータインポートシナリオにおいて、外部テーブルへのクエリが他のクエリに影響を与え、システムビジーエラーを引き起こすのを防ぐため、大きな値を設定しないでください。このパラメーターは Hologres V1.1 以降で有効です。 SET hg_foreign_table_executor_max_dop = 32; -- MaxCompute テーブルから読み取る際のバッチサイズを調整します。デフォルト値は 8192 です。 SET hg_experimental_query_batch_size = 4096; -- 外部テーブルにアクセスする際に DML 文を実行するための最大同時実行数を設定します。デフォルト値は 32 です。このパラメーターは、インポート操作が過剰なシステムリソースを消費するのを防ぐために、データインポートおよびエクスポートシナリオ向けに最適化されています。このパラメーターは Hologres V1.1 以降で有効です。 SET hg_foreign_table_executor_dml_max_dop = 16; -- MaxCompute テーブルにアクセスする際のスプリットサイズを設定します。このパラメーターで同時実行数を調整できます。デフォルト値は 64 MB です。テーブルが大きい場合は、この値を増やして、スプリットが多すぎてパフォーマンスに影響するのを防ぎます。このパラメーターは Hologres V1.1 以降で有効です。 SET hg_foreign_table_split_size = 128; -
幅の広い列のスキャン同時実行数を制御する
幅の広いテーブルのパラメーターを調整しても OOM エラーが発生する場合は、データに幅の広い列が含まれていないか確認してください。含まれている場合は、次のパラメーターを調整して問題を解決します。
-- 幅の広い列のシャッフル並列処理を調整して、データの蓄積を減らします。 SET hg_experimental_max_num_record_batches_in_buffer = 32; -- MaxCompute テーブルから読み取る際のバッチサイズを調整します。デフォルト値は 8192 です。 SET hg_experimental_query_batch_size=128;
-
-
原因： 外部テーブル内の過剰な重複データ
外部テーブルに大量の重複データが含まれている場合、インポートパフォーマンスが低下し、OOM エラーが発生する可能性があります。たとえば、1 億行のテーブルに 8,000 万行の重複がある場合、重複度が高いと見なされます。ビジネスコンテキストに基づいて重複度を評価してください。
解決策： インポート前にデータを重複排除するか、より小さなバッチでインポートしてください。
「The shards are incomplete, the workers or shards are unhealthy」エラーの原因
このエラーは通常、メモリ不足 (OOM) が直接の原因ではありません。Hologres インスタンスの CPU 使用率が過度に高い場合に発生し、ワーカーノードやシャードが異常な状態になることが原因です。
この問題を解決するには：
-
Hologres インスタンスのモニタリングメトリックをチェックし、CPU 使用率が上昇しているかどうかを確認してください。
-
CPU 使用率が高い場合は、ワークロードが減少するのを待ってからクエリを再試行してください。
-
エラーが続く場合は、複雑なクエリや過剰な同時実行が CPU の飽和を引き起こしていないか確認してください。リソースを大量に消費するクエリを最適化するか、同時実行数を減らして CPU 使用率を下げてください。