メモリ関連の問題

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

エラーコード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;
  

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