スロットリング

obcdcのスロットリング機能により、ほとんどのシナリオで、obcdcの実行中に使用するメモリをユーザーの想定範囲内に制御できます。memory_limit構成パラメータを使用して、想定されるobcdcのメモリ使用量を調整できます。

obcdc内部には複数のモジュールがあり、トランザクションデータは各モジュール間で流通します。全体のデータ生産・消費モデルは、いくつかの直列接続された生産-消費モデルとして大まかに理解できます。スロットリングの調整は、データ消費モジュールとログプルモジュールという2つの主要なモジュールのメモリ制御に分けられます。

データ消費モジュールのスロットリング

ユーザーの消費が遅い場合、データ消費モジュールのタスク配信進度を制御し、大量のデータが生成されても消費されずにメモリ使用量が過剰になるのを防ぎます。obcdcは、消費キューとリソース回収キューのタスク滞留状況から下流の消費速度を判断します。滞留比率がpause_redo_dispatch_task_count_threshold/100を超え、かつメモリ使用量がアラートしきい値（memory_limit * memory_usage_warn_threshold/100）に達した場合、または処理中のREDOログが一定のしきい値に達した場合、下流の消費速度が遅いと判断します。

NEED_PAUSE_REDO DISPATCH=1ログキーワードを使用してlibobcdc.logから消費モジュールのスロットリングログを取得できます。そのREASONフィールドには、具体的なスロットリングの理由が記載されています。

ログプルモジュールのスロットリング

以下の場合、obcdcはログプルのスロットリングをトリガーします：

• メモリ使用量がアラートしきい値（memory_limit * memory_usage_warn_threshold/100）に達した場合。

• メモリ内のアクティブトランザクションが一定のしきい値を超え、かつデータ消費のスロットリングが既にトリガーされている場合。

• シーケンシングモジュールのタスクが滞留している場合。

• データ永続化タスクが滞留している場合。

NEED_SLOW_DOWN=1ログキーワードを使用してlibobcdc.logからログプルスロットリングのログを取得できます。そのREASONフィールドには、具体的なスロットリングの理由が記載されています。

上記で言及した一部のパラメータの説明は以下の通りです：

obcdc内部には、より細かい粒度のスロットリング調整アルゴリズムと対応するスロットリングパラメータがさらに多数存在します。これらのパラメータは、設定されたmemory_limitに応じて自動的に調整されますが、ごく一部のシナリオではこれらのパラメータを微調整する必要が生じる場合があります。ここでは参考のためこれらのパラメータをリストアップします。ただし、ほとんどの場合、これらのパラメータを調整する必要はありません。

スロットリング関連でobcdcが自動的に調整する構成パラメータは以下の通りです。詳細については、obcdc構成パラメータの説明を参照してください。

• redodispatcher_memory_limit

• extra_redo_dispatch_memory_size

• redo_dispatched_memory_limit_exceed_ratio

• part_trans_task_active_count_upper_bound

• part_trans_task_reusable_count_upper_bound

• ready_to_seq_task_upper_bound

• storager_task_count_upper_bound

• storager_mem_percentage