メモリ関連の問題

メモリ関連のエラーは以下のとおりです。

エラーコード4013に関連するメモリ問題

エラーコード4013は、各モジュールのメモリ不足を示します。例えば、Working Areaが不足している場合です。この問題が発生する原因として、コンパイルおよび実行モジュールのメモリ不足が考えられます。この場合、MemStoreは満杯ではなく、単に各モジュールのメモリ不足が原因でエラーが発生しています。

OceanBaseデータベースのメモリ管理方式では、どのモジュールもglibcライブラリのmallocおよびfreeインターフェースを使用してメモリの確保や解放を行うことは禁止されています。OceanBaseデータベースのメモリは、ノード予約メモリ(system_memory)とsysテナントのメモリを除き、その大部分が一般テナント用に割り当てられており、一般テナントのメモリ制限は調整可能です。しかし、一般テナントのメモリ制限は、その下にあるCTXのメモリを制限し、CTXのメモリは複数のMODによって割り当てられ利用されます。したがって、対応するMODまたはCTXを特定すれば、メモリ確保失敗の操作タイプを特定できます。

エラーコード4030に関連するメモリ問題

エラーコード4030はMemStoreのメモリ不足を示しており、この種の問題は通常、INSERT、UPDATE、DELETEステートメントやTABLE_SCANアクションなど、MemStoreを扱う操作が発生するシナリオで起こります。

MemStoreのメモリが上限を超えた場合、データ書き込みが過剰であるか、または制限がかけられていないか確認する必要があります。大量の書き込みが発生し、データダンプの速度が書き込み速度に追いつかない場合にこのエラーが報告されます。以下のステートメントを実行してメモリ状態を確認できます。

obclient(root@sys)[oceanbase]> SELECT /*+ READ_CONSISTENCY(WEAK),query_timeout(100000000) */ TENANT_ID, SVR_IP,
           round(ACTIVE_SPAN/1024/1024/1024,2) ACTIVE_GB,
           round(FREEZE_TRIGGER/1024/1024/1024,2) FREEZE_TRIGGER_GB,
           round(MEMSTORE_USED/1024/1024/1024,2) TOTAL_GB,
           round(MEMSTORE_USED/FREEZE_TRIGGER*100,2) percent_trigger,
           round(MEMSTORE_LIMIT/1024/1024/1024,2) MEM_LIMIT_GB
FROM oceanbase.GV$OB_MEMSTORE
WHERE TENANT_ID >1000 OR TENANT_ID=1
ORDER BY TENANT_ID, TOTAL_GB DESC;

その他のメモリ関連のクエリ操作については、メモリ使用状況の確認を参照してください。

エラーコード4030が発生する可能性のある主な原因は以下のとおりです：

• モジュールのメモリが上限を超えています。

  この問題に対する緊急対応策は、テナントメモリを増やすことです。

  問題解決後は原因を分析する必要があります。制限がかけられていないことが原因である場合は、適切な措置を講じた上で、以前のテナントメモリ変更をロールバックする必要があります。業務規模の拡大によりテナントメモリが業務を支えるには不十分である場合は、ダンプの頻度に基づいて適切なテナントメモリサイズを設定する必要があります。MemStoreのメモリが上限を超えていない場合、以下のステートメントを実行して、どのメモリモジュールが上限を超えているか判断できます。

  obclient(root@sys)[oceanbase]> SELECT TENANT_ID, SVR_IP, SUM(HOLD) MODULE_SUM
  FROM oceanbase.GV$OB_MEMORY
  WHERE TENANT_ID > 1000 AND HOLD<>0 AND CTX_NAME NOT IN ('KVSTORE_CACHE_ID','MEMSTORE_CTX_ID')
  GROUP BY TENANT_ID, SVR_IP;
  

  メモリモジュールが上限を超えているかどうかの判断基準は、MODULE_SUM > テナント min_memory - テナント MemStore です。モジュールのメモリが上限を超えている場合、まず個々のモジュールのメモリを調整する必要があるかもしれません。例えば、ob_sql_work_area_percentageパラメータを変更してワークエリアメモリを調整します。テナントメモリが小さすぎる場合も、テナントメモリを増やす必要があります。

• PLANCACHEのヒット率が90％未満です。

  OLTPシステムのPLANCACHEヒット率は90％以上である必要があります。以下のステートメントを実行してPLANCACHEのヒット率を確認します。

  • ヒット率が90％未満のPLANCACHEを確認します。

    obclient(root@sys)[oceanbase]> SELECT PLAN_ID, HIT_COUNT, EXECUTIONS, (HIT_COUNT/EXECUTIONS) AS HIT_RATIO
    FROM oceanbase.V$OB_PLAN_CACHE_PLAN_STAT
    WHERE (HIT_COUNT/EXECUTIONS) < 0.9;
    

  • 実行回数が1000回を超え、ヒット率が90％未満のPLANCACHEを確認します。

    obclient(root@sys)[oceanbase]> SELECT PLAN_ID, HIT_COUNT, EXECUTIONS, (HIT_COUNT/EXECUTIONS) AS HIT_RATIO
    FROM oceanbase.V$OB_PLAN_CACHE_PLAN_STAT
    WHERE (HIT_COUNT/EXECUTIONS) < 0.9 AND EXECUTIONS > 1000;
    

    PLANCACHEのヒット率が90％未満の場合、次のようなステートメントが存在しないか確認する必要があります。例えば、ステートメント内の in または not in の後ろのパラメータ数がランダムになっており、結果として大量の無駄遣いが発生している場合です。そうでない場合は、業務量やセッションの急増によるメモリ不足が原因である可能性があり、テナントのメモリサイズを調整する必要があります。

• ログに fail to alloc memory または allocate memory fail などのエラーメッセージが含まれています。

  ログには tenant_id（テナント番号）および context（メモリが属するCTX名）情報が含まれています。以下のステートメントを実行して、具体的なメモリモジュール情報を照会できます。

  obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_MEMORY WHERE CTX_NAME = xxx and tenant_id = xxx;
  

  クエリ結果に基づき、モジュールのメモリが上限を超えている場合、まず個別モジュールのメモリを調整する必要があるかもしれません。テナントメモリが小さすぎる場合も、テナントメモリを増やす必要があります。