ODPのパフォーマンス分析

基礎理論

パフォーマンスチューニング

パフォーマンスチューニングは、ソフトウェアとハードウェアの能力を最大限に引き出し、実環境でシステムの最適なパフォーマンスを実現することを目的としています。これにより、ソフトウェアとハードウェアのコストパフォーマンスを向上させ、顧客のコストを削減できます。以下のように、perf stat コマンドを使用して一定期間のハードウェア性能指標データを収集できます。

Performance counter stats for process id '3260':

   182250.331423      task-clock (msec)         #   18.221 CPUs utilized
      3,259,379      context-switches          #    0.018 M/sec
      1,628,966      cpu-migrations            #    0.009 M/sec
               51      page-faults               #    0.000 K/sec
442,995,845,816      cycles                    #    2.431 GHz
226,812,458,841      instructions              #    0.51  insn per cycle
   45,556,284,037      branches                  #  249.965 M/sec
      662,510,643      branch-misses             #    1.45% of all branches

   10.002402740 seconds time elapsed

パフォーマンスチューニングの手順

パフォーマンスチューニングの主な手順は以下のとおりです：

1. 最適化目標の特定。

   1. スループット：スループットでは、CPU情報とコンポーネントのボトルネックに注目します。現在、ODPとOceanBaseデータベースはどちらもCPUをフル稼働させることができます。

   2. レイテンシ：アクセスパス上のコンポーネント数と各区間の所要時間に注意が必要です。ネットワークレイテンシも重要な要素です。

   3. エクスペリエンス：全体を考慮すると、業務側に近いほど最適化効果が顕著になる可能性があります。

2. ストレステストと情報収集：ターゲットデータを収集するだけでなく、各コンポーネントのCPU消費量、ネットワークレイテンシなどのデータも収集する必要があります。

3. ストレス解析によるパフォーマンスボトルネックの特定：上記で収集したデータから、まずボトルネックを引き起こすコンポーネントを特定し、その後詳細な分析を進めます。

4. 最適化の実施：現在の最適化は主にパラメータ調整やデプロイメントの調整です。特殊な場合は、コードを修正してバージョンアップで解決する必要があります。

5. 最適化効果の確認：主にレイテンシとスループットが顧客要件またはテスト結果を満たしているかどうかを確認します。

ODPのパフォーマンス

関連データの概要

パフォーマンス関連データの概要は以下の通りです：

• qps = 同時実行数 * (1000ms / rt)。

• rt = 1000ms / (qps / 同時実行数)。

• 同一データセンター内のネットワーク遅延は、基本的に100μs以内です。

• OceanBaseデータベースの転送効率は、ODPの転送効率の50％未満です。

ODPのパフォーマンスデータの概要：

• システム全体の専有パフォーマンスは2万～3.5万の間であり、CPU型番などの影響を受けます。負荷が小さい場合、HTを経由しない方がパフォーマンスは高くなります。

• OceanBaseデータベースと混合デプロイメントする場合、競合が発生するため、ODPに負荷分散を行う方がパフォーマンスが向上します。

• 他のデプロイメント方法と比較して、クライアント側にデプロイする方法が最もパフォーマンスが良いです。

• ARMプラットフォームをサポートしていますが、ARMプラットフォームのパフォーマンスはx86システムほど良くありません。

トラブルシューティング

ODPの主な問題はQPSとRTです：

• QPS：一般的にはスケールアウトで解決できます。スケールアウトが不可能な場合は、単一マシンのパフォーマンス向上を検討します。CPUが十分でもQPSが上がらない場合は、具体的な問題に応じて分析する必要があります。

• RT：Slow Queryログを確認することでODPの処理時間を確認できます。ODP自体の処理時間はμsレベルですが、全体のアーキテクチャの方がRTに大きな影響を与えます。

問題を処理する際には、何を達成したいのかという実装目標を明確に区別する必要があります。例えば、ODPがボトルネックとなり(CPUが満杯の状態)、OMSのデータ移行が遅くなった場合、ODPインスタンスの数を増やすことでより迅速に問題を解決できます。

スレッドモデル

topコマンドの-Hオプションを使用するとスレッド状況を確認できます。ODPのワーカースレッドは、obproxyおよびスレッド名がET NETで始まるスレッドです。ODPはスレッド間の共有をほぼ排除しているため、各スレッドは独立して動作でき、各リクエストは均等に各ワーカースレッドに分配されます。

パラメータ調整

パフォーマンスチューニングで扱う主なパラメータは以下の通りです：

alter proxyconfig set enable_compression_protocol=false; --圧縮を無効にし、CPU使用率を下げる
alter proxyconfig set proxy_mem_limited='16G'; --OOMを防ぐため、実際の環境に応じて動的に調整可能
alter proxyconfig set enable_prometheus=false;
alter proxyconfig set enable_metadb_used=false;
alter proxyconfig set enable_standby=false;
alter proxyconfig set enable_strict_stat_time=false;
alter proxyconfig set use_local_dbconfig=true; --3.x系でのみ利用可能
alter proxyconfig set work_thread_num= xxx; --xxxは実際のコア数以下に設定する

ルーティングの正確性

OceanBaseデータベースの転送効率はODPほど高くないため、コアシナリオにおいてODPのルーティング正確性は非常に重要であり、可能であればすべてローカル計画にすることが望ましいです。非コアシナリオでは、このような厳密な要件を課す必要はありません。現在、ODPは通常のテーブル、パーティションテーブル、LDC、プライマリゾーンなどのルーティングをサポートしています。詳細については、データルーティングの章を参照してください。

プロセス性能分析

スレッドモデルデータ

一定の10万QPSデータにおけるCPU消費は以下の表のとおりです：

ツールによる確認

ツールによる主な確認方法は以下のとおりです：

1. topコマンド

   1. topコマンドを使用してODPのCPU使用率をリアルタイムで確認します。CPU使用率がOceanBaseデータベースを超えた場合、そのパフォーマンスは異常である可能性があり、さらなる分析が必要です。

   2. top -Hを使用してスレッドのCPU消費を確認します。ODPのスレッド消費は非常に均等です。

2. perfコマンド

   1. perf topを使用してホットスポット関数を確認します。現在、ODPでは5%を超える関数はありません。

   2. perf statを使用してハードウェア指標を確認します。異なるCPUを分析する際に役立ちます。

3. ログ出力

   ログは性能に大きな影響を与えます。ODPのログ生成速度を確認します。もし1〜2秒ごとに1つのログが生成されている場合、性能への損害は大きいです。