パフォーマンスチューニングの手法
理想的には、バックアップ・リストアのパフォーマンスは、データの分散状況(パーティション数とサイズ)およびハードウェア(CPU、ディスク、ネットワーク)の性能にのみ制限されるべきです。しかし、デフォルト設定では、ハードウェアの性能を十分に活用できない場合があります。そのため、OceanBaseデータベースはリソース分離戦略および以下のパラメータを提供し、バックアップ・リストアのパフォーマンスチューニングを実施します。
ネットワーク設定:パラメータ
sys_bkgd_net_percentageは、バックグラウンドシステムタスク(バックアップ・リストアタスクを含む)が使用できる総ネットワーク帯域幅の割合を制限するために使用されます。sys_bkgd_net_percentageを適切な値に設定することで、フロントエンド業務に影響を与えることなく、バックアップ・リストアタスクがネットワーク帯域幅リソースを最大限に活用できます。CPU・I/O設定:同時に、OceanBaseデータベースは、異なるタイプのタスクのCPU・I/O使用量を制限するためのResource Managerリソース分離メカニズムも提供しています。バックアップ・リストアタスクにリソース分離を設定した場合は、実際のリソースとビジネス要件に基づいて上限を設定し、バックアップ・リストアタスクのCPU・I/O使用量がボトルネックに達するのを防いでください。
その他の設定:CPU、I/O、およびネットワークリソースが十分であることを確認した上で、関連するパラメータ(
ha_low_thread_score、log_archive_concurrency、log_restore_concurrency、ha_high_thread_scoreなど)を設定することで、バックアップ・リストアタスクの並列度を向上させ、さらにパフォーマンスを高めることができます。
リソース設定関連
クラスタレベルパラメータ sys_bkgd_net_percentage
パラメータ sys_bkgd_net_percentage は、バックグラウンドシステムタスクが使用できるネットワーク帯域幅の割合を設定するために使用され、デフォルト値はマシンのNIC速度の60%です。帯域幅が満杯の場合、業務リクエストに影響を与えない範囲で、パラメータ sys_bkgd_net_percentage の値を適宜引き上げることができます。
設定が成功した後、以下の方法でログを確認できます:
adminユーザーでOBServerノードが配置されているマシンにログインします。OceanBaseデータベースソフトウェアのインストールディレクトリに移動します。
以下では、OceanBaseデータベースソフトウェアのインストールパスが
/home/admin/oceanbase/である場合を例に説明します。操作時は実際の環境に準じてください。[admin@xxx /]$ cd /home/admin/oceanbase以下のコマンドを実行して、NIC速度を確認します。
[admin@xxx oceanbase]$ grep -E 'print band limit|succeed to init_bandwidth_throttle' log/observer.log*ここで、
observer.logはクラスタ起動時のobserverログです。例えば、クエリ結果は次のとおりです:
log/observer.log.20210811100806:[2021-08-11 10:06:32.934433] INFO [SERVER] ob_server.cpp:1783 [76957] [0] [Y0-0000000000000000] [lt=4] [dc=0] succeed to init_bandwidth_throttle(sys_bkgd_net_percentage_=60,ethernet_speed_=1310720000,rate=786432000) log/observer.log.20210811100806:[2021-08-1110:07:42.351813] INFO [COMMON] utility.cpp:1487 [77169][418] [Y9FA64586E9E-0005C93F15DAE715] [lt=11] [dc=0] print band limit(comment= in , copy_KB=0, sleep_ms_sum=0, speed_KB_per_s=0, total_sleep_ms=0,total__bytes=531, rate_KB/s=786432,print_interval_ms=69417)最初のクエリ結果では、
sys_bkgd_net_percentage_=60は、バックグラウンドシステムタスクが使用できるネットワーク帯域幅がマシンのNIC速度の60%であることを示しています。network_speed=1310720000は、OceanBaseデータベースが認識したマシンのNICの最大速度が1310720000 B/sであることを示しています。rate=786432000は、制限後の最大速度が786432000 B/sであり、rate = network_speed * sys_bkgd_net_percentageであることを示しています。2番目のクエリ結果では、
rate_KB/s=786432は、OceanBaseデータベースが認識した制限後の最大速度(rate)が786432 KB/sであることを示しています。
OceanBaseデータベースが認識したNIC速度が不正確な場合があるため、ログを確認した後、OceanBaseデータベースが認識した速度が実際と一致しない場合は、NIC速度の確認を参照して修正できます。
修正後、ビューV$OB_NIC_INFOを確認することで、修正後のNIC速度が有効になっているかどうかを確認できます。
Resource Managerのリソース分離
Resource Managerは、OceanBaseデータベースのリソース分離メカニズムであり、Functionレベルのリソース分離により、CPU、IOPS、ネットワーク帯域幅など、異なるバックグラウンドタスクのリソース上限を設定できます。リソース分離の詳細については、リソース分離の概要を参照してください。
関数レベルのリソース分離では、バックアップ・リストアに関連するバックグラウンドタスクは以下のとおりです:
- ha_high:レプリケーション、Rebuild、復元などの高優先度・高信頼性タスク。
- ha_mid:移行タスクなどの中優先度・高信頼性タスク。
- ha_low:バックアップやバックアップクリーンアップなどの低優先度・高信頼性タスク。
ビューDBA_OB_RSRC_DIRECTIVESを使用して、現在のテナントで設定されているリソース分離計画を確認できます。クエリ結果が空の場合、テナントにリソース分離計画が設定されていないことを意味します。バックグラウンドタスクに対応するレコードが検索された場合、まずCPU、I/O、ネットワーク帯域幅などがボトルネックに達しており、かつリソース分離の制限と一致しているかどうか確認してください。一致していることを確認した上で、フロントエンド業務に影響を与えない範囲で、適切にリソース分離計画を変更することを推奨します。リソース計画の変更手順の詳細については、リソース管理計画の内容を更新する(MySQLモード)およびリソース管理計画の内容を更新する(Oracleモード)を参照してください。
バックアップ・リストアのパフォーマンステストを実行する際は、リソース分離計画の設定は推奨されません。
データバックアップ関連
パラメータ |
説明 |
デフォルト値 |
設定の説明 |
|---|---|---|---|
| ha_low_thread_score | テナントレベルのパラメータで、データバックアップの並列数を制御します。 | 0、デフォルトの並列数は2を意味します | 小規模テナント(テナントCPU ≤ 4C)はデフォルト値に設定することを推奨します。大規模テナントは、まず10に設定し、バックアップ速度が遅すぎる場合は必要に応じて2倍に調整できます。バックアップ・リストアのパフォーマンステストを実行する際は、最大値の100に直接調整することを推奨します。 |
ログアーカイブ関連
パラメータ |
説明 |
デフォルト値 |
設定の説明 |
|---|---|---|---|
| log_archive_concurrency | テナントレベルのパラメータで、ログアーカイブの並列数を制御します。 | 0、現在のバージョンでは、テナントのMAX_CPUに基づいて以下の適応ルールでアーカイブワーカースレッド数を計算します:
|
大規模・小規模テナントともにデフォルト値を維持し、適応ルールに従ってワーカースレッド数を計算することを推奨します。 |
物理復元関連
パラメータ |
説明 |
デフォルト値 |
設定の説明 |
|---|---|---|---|
| log_restore_concurrency | テナントレベルのパラメータで、ログ復元の並列数を制御します。 | 0、テナントのMAX_CPUのコア数を並列数とします |
この構成パラメータの値を大きくすると、ワーカースレッドが増加するだけでなく、メモリリソースのオーバーヘッドも増加します。デフォルト値の0に統一して設定し、復元速度が遅すぎる場合にのみ、マシンの実際のリソースに応じて適宜この構成パラメータの値を大きくすることを推奨します。 |
| ha_high_thread_score | テナントレベルのパラメータで、データ復元の並列数を制御します。 | 0、デフォルトの並列数は8を意味します | パフォーマンステスト時はデフォルト値の使用を推奨し、バックアップ・リストアのパフォーマンステスト実行時は最大値の100に調整することを推奨します。 |
| _restore_idle_time | クラスタレベルの隠れた構成パラメータで、RS復元のスケジューリング間隔を制御します。 | 1m、1分を意味します | 10sに調整した場合、データ復元の所要時間は数十秒から2分程度短縮されます。パフォーマンス要件が高い小規模テナント(テナントCPU ≤ 4C)に対して調整することを推奨します。そうでない場合、効果は顕著ではありません。 |
テーブルレベル復元関連
物理復元補助テナント段階
テーブルレベル復元関連ビューの紹介 のビューから、該当タスクに関連する一時補助テナント名を取得します。補助テナント名はデフォルトで AUX をプレフィックスとして付加されて識別されます。
テーブルレベル復元における物理復元補助テナント段階は、物理復元と同じです。この段階に関連するパフォーマンスチューニングについては、本ドキュメントの 物理復元関連 の内容を参照してください。
テナント間データ導入段階
パラメータ |
説明 |
デフォルト値 |
設定の説明 |
|---|---|---|---|
| ddl_thread_score | テナントレベルのパラメータで、テナントが配置されているOBServerノード上のテーブルレベル復元スレッドプールの容量を制御します。 | 0、デフォルトではテーブルレベル復元スレッドプールの容量は2を意味します |
|
| recover_table_concurrency | テナントレベルのパラメータで、複数テーブルの並列復元の並列度を制御し、いくつのテーブルが同時にテナント間データ導入を実行できるかを設定します。 | 0、デフォルトでは1つのテーブルのみがテナント間データ導入を実行できることを意味します | デフォルト値の0に統一して設定することを推奨します。また:
注意テナント間データ導入は大量の一時ストレージ容量とメモリリソースを消費するため、テナントのリソース状況に応じて適切に値を引き上げることを推奨します。そのうち、一時ストレージ容量の消費はインデックス再構築段階で発生します。テーブルのデータ量が非常に多い場合、大量の一時容量を消費する可能性があります。一時容量の消費が多すぎると、クエリの失敗、トランザクションのロールバック、サービスの利用不能などの問題が発生する可能性があります。 |
| recover_table_dop | テナントレベルのパラメータで、単一テーブルの復元の並列度を制御します。 | 0、デフォルトでは並列度は1を意味します | 8または16に統一して設定することを推奨します。これでほとんどのシナリオ要件を満たせます。 復元対象のテーブルがデータ量の多い非パーティションテーブルである場合、または復元するテーブルにデータ量の多いパーティションが存在する場合、パーティションのデータ量に応じて |