一般的なメモリエラーの処理と最適化の方法 - AnalyticDB

このトピックでは、XIHE コンピュートエンジンのメモリメカニズムと原則について説明します。また、クエリにおけるメモリ関連の一般的なエラーの処理と最適化の方法についても説明します。

XIHE エンジンのメモリ管理メカニズム

アーキテクチャ

コントロールノード：SQL 文を解析し、対応するサブタスクを生成し、特定のコンピュートノードに実行をスケジュールします。また、各コンピュートノードのメモリ使用量も監視します。
コンピュートノード：コンピューティングロジックの実行を担当するノード。データはネットワークシャッフルを介して異なるノード間で交換されます。
コンピュートノードでは、XIHE エンジンは利用可能な物理メモリを 2 つの異なる領域に割り当てます。
- オペレーターメモリ
  分析コンピューティングエンジンは、Join、Aggregate、Window、TopN などの一般的なオペレーターを使用します。これらのオペレーターが実行されるとき、一時データをメモリに保存する必要があります。例としては、JOIN 操作のハッシュプローブテーブルや Aggregate 操作の中間結果などがあります。このメモリは、オペレーターの実行が完了するまで解放できません。このタイプのメモリ使用量は大きく、クエリによって処理されるデータ量に直接関係しており、数百ギガバイト、さらにはテラバイトに達することもあります。これらのオペレーターのメモリ使用量を最適化するために、XIHE はオペレーターメモリと呼ばれる専用のメモリ領域を予約して、メモリ要求と使用量をより効率的にします。
- ストリームメモリ
  コンピューティングロジックの実行中に、さまざまな一時オブジェクトが生成されます。例としては、シャッフル操作中の一時データバッファ、オペレーター内で交換されるデータ、TableScan の一時キャッシュなどがあります。これらのオブジェクトはライフサイクルが短く、要求と解放が迅速に行われます。消費するメモリは、XIHE ではストリームメモリと呼ばれます。

メリット

XIHE エンジンはコンピューティングタスクを分割し、複数のノードに割り当てて並列実行するため、データ処理速度が大幅に向上します。また、高いフォールトトレランスと拡張性を備えており、大量のデータを効率的に処理できます。主な特徴は以下のとおりです。

並列コンピューティング：ビッグデータタスクを複数のサブタスクに分解し、クラスタノードで並列に実行して計算時間を短縮します。
スケーラビリティ：さまざまな規模のデータ処理要件に適応するために、コンピュートノードの動的な追加と削除をサポートします。
複数のコンピューティングモデル：リアルタイムクエリ（超並列処理または MPP）やバッチ処理（Batch）など、複数のコンピューティングモデルをサポートします。

保護メカニズム

コンピューティングエンジンの安定性を確保し、単一の大規模クエリによってノード障害が発生してクラスタ全体の可用性に影響を与えるのを防ぐために、XIHE エンジンはオペレーターメモリとストリームメモリの使用を制限します。これらの制限には、以下が含まれます。

単一クエリの制限：単一のクエリがオペレーターメモリを過剰に使用する場合、たとえば、Join 操作中にオペレーターメモリが使い果たされた場合、そのクエリからの後続のメモリ要求は失敗します。
ノードレベルの制限：単一ノードのオペレーターメモリとストリームメモリの両方にしきい値の上限があります。このメモリが使い果たされると、後続のクエリは失敗します。
クラスタレベルの OOM キルメカニズム：クラスタ全体のメモリが不足すると、コントロールノードは最もメモリを消費しているクエリを停止して、他のクエリのリソースを解放します。

よくある質問

クエリが予約済みメモリ制限を超えました / Out of Memory Pool size pre cal. available

このエラーは、オペレーターメモリが不足しているために発生します。オペレーターメモリ不足の原因と対応する解決策は以下のとおりです。

原因	説明	解決策
結合順序	結合計算中に、XIHE オプティマイザーは適切な結合順序を自動的に推定して、ビルドが小さいテーブルに基づいていることを確認します。ただし、統計情報の有効期限が切れている場合、またはその他の理由でオプティマイザーの推定が不正確な場合、ビルドが大きいテーブルに基づいている可能性があり、メモリ不足の問題が発生します。オペレーターレベルの診断結果を確認して、この問題が存在するかどうかを確認できます。	次のいずれかの解決策を使用できます。統計情報を更新します。結合順序を手動で調整します。
データスキュー	JOIN や Aggregate などの操作では、データ全体の量が限られていても、データスキューが発生する可能性があります。分散キーが不均一なためにすべてのデータが単一ノードに集中して処理される場合、そのノードのオペレーターメモリしきい値がトリガーされ、エラーが発生する可能性があります。ステージレベルの診断結果を確認して、この問題が存在するかどうかを確認できます。	ビジネスレベルで最適化を実行することをお勧めします。たとえば、SaaS アプリケーションでは、大規模な顧客を個別に計算したり、計算前に null などの異常値を除外したりできます。テーブルの作成時にデータスキューが存在する場合、同様の問題が発生する可能性があります。この問題の対処方法の詳細については、「テーブルスキューの診断」の最適化方法をご参照ください。
過剰なデータ量またはデータの拡張	データの拡張は通常、不適切な JOIN 条件または結合順序が原因で発生します。これは、クエリの実行速度を低下させるだけでなく、メモリ不足などのエラーを引き起こす可能性もあります。元のビジネスデータ量が大きすぎる場合も、同様の問題が発生する可能性があります。	次のいずれかの解決策を使用できます。結合中のデータの拡張が、左右両方のテーブルに同一の値が多いなど、データ自体の特性によって引き起こされる場合は、これらの値を個別に処理できます。データの拡張が結合順序によって引き起こされる場合は、結合順序を手動で調整できます。クロス接続の使用は避けてください。タスク処理の並列処理の次数 (hash_partition_count) を増やして、データをより分散させ、実行により多くの計算リソースを使用できるようにします。
集計中の過剰なカーディナリティ	これは、Aggregate または Window オペレーター (フィールドによるパーティション分割) でよく見られます。一意の値が多すぎると、集計のパフォーマンスが低下し、大量のメモリが消費されます。	2 段階集計をキャンセルします。詳細については、「グループ化と集計クエリの最適化」をご参照ください。タスク処理の並列処理の次数 (hash_partition_count) を増やします。 COUNT DISTINCT 操作の場合、SQL 文の前にヒント `optimize_multi_mark_distinct=true` を追加できます。

クエリがシステムメモリプール制限を超えました

このエラーは、ストリームメモリが不足しているために発生します。ストリームメモリ不足の原因と対応する解決策は以下のとおりです。

原因	説明	解決策
いくつかの大きな VARCHAR フィールドをクエリしました	XIHE 内では、複数のデータ行が 1 つのバッチにマージされて処理されます。JSON やリッチテキストなどの大きな VARCHAR フィールドをクエリすると、これらの行によって占有される一時メモリが大幅に増加する可能性があります。これにより、ストリームメモリ制限がトリガーされ、エラーが発生する可能性があります。	次のいずれかの解決策を使用できます。ビジネス側で SQL 文を最適化して、計算に含まれる大きな VARCHAR フィールドが多すぎないようにします。テーブルの作成中に、block_size パラメータを小さくすることができます。
SELECT 操作中にスキャンされる列が多すぎます	単一列のサイズが制限されていても、計算に含まれる列が多すぎると、一時メモリの使用量が増加し、ストリームメモリ制限がトリガーされます。	ビジネス側で SQL 文を最適化して、SELECT 操作中に不要な列がスキャンされないようにします。必要な列のみがスキャンされるようにしてください。
クエリの同時実行数が多すぎます	複数のクエリが同時に実行されると、それらが占有するストリームメモリの合計によってストリームメモリ制限がトリガーされる可能性があります。これにより、後続のクエリでエラーが発生します。	クエリの同時実行数を制限します。

クラスタのメモリが不足しているため、クエリは強制終了されました

原因：クラスタ全体のメモリが不足しており、コントロールノードのメモリ不足 (OOM) キルメカニズムがトリガーされています。

解決策：大量のメモリを占有しているクエリを 1 つずつ分析し、前述の方法に基づいて最適化する必要があります。詳細については、「一般的な低速クエリ」と「クエリプロパティと診断結果の表示」をご参照ください。

クエリがリクエストごとの取消可能制限を超えました / クエリが非スピルメモリ制限を超えました

原因：このタイプのエラーは、バッチ処理 (Batch) モードでのみ発生します。通常、クエリの並列処理の次数が低いために発生し、単一ノードのデータ量が過剰になります。

解決策: クエリの並列処理の次数 (batch_hash_partition_count) を増やします。デフォルトの並列処理の次数は 32 で、これを 64 に変更できます。たとえば、/* batch_hash_partition_count=64 */ のように指定します。 Join クエリの場合は、ハッシュバケットの総数 (hybrid_hash_join_bucket_num) を増やすことができます。デフォルトの総数は 16 で、これを 32 に変更できます。たとえば、/* hybrid_hash_join_bucket_num=32 */ のように指定します。

最適化手法

前述のクエリレベルのソリューションに加えて、リソーススケーリング、分離、ジョブ配信などの手法を使用してシステムパフォーマンスを最適化し、メモリ不足によるクエリ失敗を回避することもできます。

リソースグループの分離

リソースグループは、異なるクエリ間で計算リソースを物理的に分離し、相互干渉を回避できます。たとえば、Service Level Agreement（SLA）要件の高い重要なクエリの場合、独立したリソースグループを使用して実行することで、他の優先度の低いクエリからの干渉を防ぐことができます。さらに、リソースグループは、リソーススケーリングプランの設定をサポートしており、時間またはペイロードに基づいてリソースを自動的にスケールインまたはスケールアウトできます。これにより、メモリ不足の問題が効果的に軽減されます。

サーバーレス配信

Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスタでは、自動配信機能を有効にすることができます。この機能が有効になると、システムはメモリ不足のためにエラーを報告するクエリを、ジョブベースのリソースグループに自動的に配信して実行します。Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスタは、毎月自動配信のための無料クォータを提供します。ジョブベースのリソースグループは、実行中のジョブのサイズに基づいてリソースを動的にプルするため、使用コストを効果的に削減できます。

バッチ処理（Batch）実行モード

バッチ処理（Batch）実行モードでは、クエリがメモリ不足になった場合、システムは自動的にスピル操作を実行してデータをディスクに書き込みます。これにより、メモリ不足によるクエリ失敗を防ぎます。ただし、ディスクへの書き込みやスケジューリングモードの変更などの要因により、バッチ処理（Batch）実行モードではクエリの実行速度が低下する可能性があります。クラスタレベルまたはクエリレベルでクエリの実行モードを切り替えることができます。