TiDBランタイムダッシュボード：具体的なケースから学ぶ詳細分析

※このブログは2025年6月12日に公開された英語ブログ ｢TiDB Runtime Dashboard: A Detailed Analysis with Use Cases｣ の拙訳です。

TiDBのランタイム環境では、Goランタイムレベルでのメモリ管理、ガベージコレクション (GC) の挙動、そしてロック競合に関連する問題が、システムの安定性とパフォーマンスに著しい影響を与える可能性があります。しかし、これらの問題は再現や直接的な分析が難しいことがしばしばあります。そのため、効果的なトラブルシューティングとパフォーマンスチューニングには、高品質なランタイム監視メトリクスが不可欠となります。

本ブログでは、TiDBランタイムダッシュボードの具体的な診断による価値に焦点を当ててご紹介します。まず、このダッシュボードがどのような問題の調査に役立つのかを概説します。次に、よく使用されるパネルについて詳しく解説します。最後に、実際の事例を用いて、これらのパネルがどのように問題の分析と特定に役立つのかを実演します。

注記：この記事は、TiDB 8.5で利用可能なTiDBランタイムダッシュボードに基づいています。

TiDBランタイムダッシュボード：適用可能なトラブルシューティングのシナリオ

このセクションでは、メモリ使用量の急増、CPUオーバーヘッド、GCによるレイテンシ、ロック競合といった一般的な症状について概説します。これらの根本原因を特定するために、特定の監視パネルをどのように使用するかを説明します。各シナリオでは、TiDBのランタイムメトリクスから何を探し、どう解釈すれば、より迅速かつ的確なトラブルシューティングができるかについての指針を解説します。

異常なメモリ使用量

TiDBインスタンスがOOM (Out of Memory) イベントまたは異常に高いメモリ使用量が発生した場合、Memory Usageパネルは根本原因の特定に役立ちます。メモリ使用量の傾向とオブジェクトの割り当て内訳を分析することで、ユーザーは問題がメモリリーク、頻繁な小規模オブジェクトの割り当て、または遅延したガベージコレクションによるものかどうかを判断できます。

異常なCPU使用率

CPU使用率が予期せず高くなったり変動したりする問題に対し、Estimated Portion of CPU Timeパネルは、CPU時間がユーザーコードとGoランタイムの各コンポーネントにどのように分配されているかについての理解に役立ちます。これにより、GCや解放されたメモリの回収、その他のランタイムレベルのプロセスが過剰なCPUリソースを消費しているかどうかを特定でき、オーバーヘッドの真の原因を突き止めるのに役立ちます。

GCによるレイテンシの急上昇

非効率なガベージコレクションの挙動は、特にstop-the-world (STW) の一時停止が短時間で頻繁に発生する場合、深刻なレイテンシのばらつきを引き起こす可能性があります。Golang GC、GC STW Latency、GOGC & GOMEMLIMITといったパネルは、GCの頻度、継続時間、および設定パラメータに関する包括的な情報を提供し、GCの挙動が適切であるかを評価するのに役立ちます。

ロック競合

TiDBインスタンスでCPU使用率が高かったり、Goroutineがブロックされたりする場合、それはロック競合やスケジューラーのリソース圧迫が原因である可能性があります。Goroutine CountやSyncMutex Waitといったパネルは、大量のGoroutineがブロックされているかどうか、あるいはシステムがロックを非効率に使用しているかどうかを明らかにします。これにより、さらなる調査のための貴重な手がかりが得られます。

TiDBランタイムダッシュボード：主要なパネルの詳細な説明

このセクションでは、最も重要な監視パネルについて、その測定対象、重要性、そして出力の解釈方法を詳しく解説します。メモリ消費、ガベージコレクションの頻度、またはロック競合を追跡する場合でも、これらの視覚化はTiDBランタイムおよびGo実行環境の内部動作を把握するための手がかりとなります。

メモリ使用量

このパネルは、 tidb-server プロセスの全体的なメモリ使用量を表示します。内容は以下の通りです。

• RSSの折れ線グラフ：プロセスの実際の物理メモリ使用量 (Resident Set Size) を示します。
• 積み上げ棒グラフ：メモリ使用量を詳細なカテゴリに分類し、ユーザーがメモリ消費を理解しやすくします。

棒グラフの主要項目の説明：

• heap_inuse：Goアプリケーションのコードがアクティブに使用しているヒープメモリです。
• heap_unused：Goランタイムがオペレーティングシステムから割り当てたものの、現在使用していないヒープメモリです (予約済みですが未割り当ての状態です) 。
• stack_inuse：Goroutineのスタックが使用しているメモリです。
• go_runtime_metadata：型情報やメモリ情報などのメタデータを管理するためにGoランタイムが必要とするオーバーヘッドです。
• free_mem_reserved_by_g：GoランタイムがOSから予約している空きメモリです。頻繁なシステムコールのオーバーヘッドを減らすため、将来の割り当てのために保持されています。

このパネルを使うことで、メモリの使用状況が健全であるか、過剰な割り当てやメモリ解放の遅延といった兆候がないかを素早く評価できます。

CPU時間の推定割合

このパネルは、TiDBインスタンスにおける、さまざまな種類のシステムタスクにわたる推定CPU時間配分を表示します。これにより、CPU消費の主な原因をユーザーが素早く特定できるようになります。また、CPUが高い使用率を示すシナリオにおいて、ビジネスロジックがCPUを消費しているのか、Goランタイム (例：ガベージコレクションやメモリの回収) が消費しているのかを示すことで、問題の診断に役立ちます。

このパネルの主な項目には以下のものが含まれます：

• user_total：ユーザーコードによって消費されたCPU時間で、通常は実際のビジネスロジックの実行コストを示します。
• gc_total：Golangのガベージコレクション (GC) が使用したCPU時間で、メモリ解放がCPUリソースに与える影響を反映します。
• idle_total：CPUがアイドル状態であった時間 (スケジューラに実行可能なタスクがない状態) で、リソースの過剰な割り当てやワークロードが低い状況を特定するのに役立ちます。
• scavenge_total：Goランタイムのメモリ回収処理が費やしたCPU時間で、未使用の物理メモリページをオペレーティングシステムに返すためにバックグラウンドで実行されます。

このパネルは、いくつかの一般的な疑問に答えるのに役立ちます。

• TiDBインスタンスは現在、GCによる負荷を受けているか？
• CPUの大部分が、メモリ回収のようなバックグラウンドのランタイムタスクに消費されていないか？
• ユーザーレベルのCPU使用率は、想定されるビジネス負荷と一致しているか？

また、このパネルをGolang GCやGC STW Latencyなどの関連パネルと組み合わせることで、GC関連のパフォーマンスオーバーヘッドについて包括的に把握できます。

Go言語のガベージコレクション

このパネルは、各監視間隔中に発生したGo言語のガベージコレクション (GC) イベントの回数を表示し、GC操作の頻度を視覚化するのに役立ちます。

ユーザーはしばしば、このパネルをEstimated Portion of CPU Timeパネルと組み合わせて使用し、GCがCPUリソース消費に与える影響を分析します。たとえば、GCのトリガー頻度が高く、それに対応するGCが使用するCPU時間が大幅に増加している場合、システム内でGCの負荷が高まっていることを示している可能性があり、TiDB全体のパフォーマンスに悪影響を及ぼす恐れがあります。

GC STW Latency (go 1.22.0以上)

このパネルは、ガベージコレクションによって引き起こされたStop-The-Worldの一時停止のレイテンシを表示します。これにより、従来のGC STW Duration (last 256 GC cycles) パネル (下の最初の図に示されています) に比べて、より詳細で低遅延な視点を提供します。

加えて、このパネルはGC-triggeredSTWとnon-GC-triggeredSTWのイベントを区別するため、STWの一時停止がパフォーマンスに与える影響をより詳細に分析できます。たとえば、non-GC-related STWレイテンシが高い場合、頻繁なプロファイル収集やデバッグ操作といった、他の要因によるオーバーヘッドを示している可能性があります。

注記：GC STW Duration (last 256 GC cycles) パネルは、直近256回のGCサイクルにおけるSTWの一時停止時間について、パーセンタイル統計 (例：最小値／p25／p50／p75／最大値) を表示します。GC STW Latencyと比較すると、その粒度は比較的粗いため、過去の傾向分析により適しています。

同期ミューテックス待機

このパネルは、Goroutineが sync.Mutex または sync.RWMutex でブロックされる累積時間 (概算) を表示し、システム内のロック競合を分析するのに役立ちます。

このパネルを観察することで、ユーザーは深刻な同期ボトルネックがないかを簡単に評価できます。例えば、TiDBの並行処理パフォーマンスが低下し、このメトリクスが大幅に増加している場合、重要な実行パスで深刻なロック競合が発生している可能性があります。このようなケースでは、根本原因を特定するために、ミューテックスプロファイルやGoroutineのスタックトレースを調査する必要があります。

GOGCとGOMEMLIMIT

このパネルは、Go言語のGCに関連する二つの重要な設定パラメータ、GOGCとGOMEMLIMITを表示します。これらの設定は、Goランタイムのメモリ管理の挙動に直接影響を与えます。

このパネルを監視することで、ユーザーは enable_gogc_tuner や tidb_server_memory_limit といった、TiDBのメモリ制御メカニズムが意図した通りに機能しているかを確認できます。

TiDBランタイムダッシュボードの例：Golang GCが tidb-server で持続的な100%CPU使用率を引き起こしています

このGitHub Issueは、ある顧客環境で実際に発生した問題を再現したものです。TiDBを旧バージョンからTiDB 6.5にアップグレードした後、メモリ消費量が tidb_server_memory_limit で定義されたしきい値に近づくと、 tidb-server のCPU使用率が継続的に高くなるという現象が発生しました。この問題は、アップグレード前の古いバージョンでは発生していませんでした。

TiDBランタイムダッシュボードの観察結果

TiDB Runtime → CPU Usageの監視パネルから、CPU使用率が16:48頃から大きく変動し始め、16:55以降は一貫して1600%という高い水準で推移し、ビジネスのスループットに深刻な影響を与えていたことがわかります。

CPU使用率が異常な状況だったため、最初のステップとしてTiDB Runtime → Estimated Portion of CPU Timeパネルを調べ、どのタスクが高いCPU負荷の原因となっているかを分析しました。

監視データによると、 gc_total (ガベージコレクションに費やされたCPU時間) の割合は16:48以降に大幅に増加し、1.8%から最終的には約32%で安定しました。さらに、 gc_total の上昇と全体のCPU飽和度には明確な正の相関関係が見られ、GC活動が高いCPU負荷の主要な原因であったことが示唆されます。

メカニズム分析

TiDB 6.5では、2つの新しい設定パラメータが導入されました。

• tidb_server_memory_limit
• tidb_server_memory_limit_gc_trigger

tidb-server プロセスのメモリ使用量が tidb_server_memory_limit * tidb_server_memory_limit_gc_trigger に達すると、TiDBは積極的にGo言語のGCをトリガーします。このメカニズムは、Goランタイムの GOMEMLIMIT 変数を動的に調整することで実装されます。新しい GOMEMLIMIT の値は、 tidb_server_memory_limit * tidb_server_memory_limit_gc_trigger に設定されます。

TiDBは、GCが過度に頻繁に発生するのを避けるために、適応的な調整戦略を採用しています。

1. 初期状態：メモリ使用量がしきい値を下回っている間、 tidb_server_memory_limit_gc_trigger はデフォルト値の 0.7 を維持します。
2. GCがトリガーされた後：メモリがしきい値を超えてGCがトリガーされると、 tidb_server_memory_limit_gc_trigger は 1.1 に引き上げられます。その後、1分後には自動的に 0.7 に戻ります。

異なるメモリ使用量における想定される挙動は以下の通りです。

• メモリ使用量 < tidb_server_memory_limit * 0.7 ：トリガー値は 0.7 のままで、CPU使用率は通常の運用範囲内に収まるはずです。
• メモリ使用量 [limit * 0.7, limit * 1.1) ：トリガー値は 0.7 に戻るたびに、すぐに1.1に引き上げられます。CPU負荷は依然として通常のワークロードパターンを反映しているはずです。
• メモリ使用量 ≥ limit * 1.1 ：トリガー値は長期的に 1.1 のままになります。しかし、GCが頻繁に発生するため、CPU使用率が急上昇し、飽和状態に達する可能性があります。

注記：ヒープ外メモリの寄与があるため、実際のメモリ使用量の上下限は、理論上の値よりも若干高くなる可能性があります。

ケースごとの分析

今回のケースでは、以下の設定値が適用されていました。

• tidb_server_memory_limit = 760MB
• tidb_server_memory_limit_gc_trigger = 0.7
• これにより、計算されたしきい値の範囲は以下の通りです。
  • 下限：760MB * 0.7 = 532MB
  • 上限：760MB * 1.1 = 836MB

TiDB Runtime → GOGC & GOMEMLIMITパネルによると、16:46から16:55までの期間、 GOMEMLIMIT は計算された上下限の間で変動していました。16:55を過ぎると、システムは頻繁なGCのトリガー条件を継続的に満たし、値は下限で固定された状態になりました。

一方、TiDB Runtime → Memory Usageパネルによると、 tidb-server プロセスのRSSメモリ使用量は、16:46から16:55にかけて580MBから712MBに増加し、その後も上昇を続けました。

先に説明したメカニズムに基づけば、このメモリ範囲では、 GOMEMLIMIT は上限値付近に留まるはずです。しかし、監視データは GOMEMLIMIT が下限値に固定されたままであることを示しており、これは期待された挙動から逸脱していました。

この矛盾は、 tidb_server_memory_limit_gc_trigger の適応的な調整メカニズムが、意図した通りに機能していなかったことを示唆しています。

その後のコード分析により、 tidb_server_memory_limit_gc_trigger の自動調整メカニズムの実装にバグがあることが確認されました。このバグが GOMEMLIMIT の正しい更新を妨げ、結果としてGCサイクルが頻繁に発生し、最終的にCPU使用率の継続的な高騰を引き起こしていました。

修正を適用して再テストを実施したところ、監視データは、 GOMEMLIMIT が期待通りに適応していること、Go言語のGCが消費するCPU時間の割合が約2%で安定していること、そしてTiDBインスタンス全体のCPU使用率が飽和状態に達しなくなったことを示しました。

まとめ

TiDBランタイムダッシュボードは、メモリ使用量、ガベージコレクションの挙動、スケジューラのレイテンシ、ロック競合といった主要な側面をカバーし、Goランタイムレイヤーに関する包括的な可視性を提供します。これらの主要なパネルを十分に理解し、効果的に活用することで、ユーザーはTiDBインスタンス内の潜在的なパフォーマンス問題をより効率的に特定できます。特に、再現が困難な問題に対処する場合、ランタイムメトリクスはしばしば決定的な診断の手がかりとなります。

実際の運用やトラブルシューティングのシナリオでは、ビジネスの状況、監視の傾向、そしてプロファイリングツールを組み合わせることで、より的を絞った効率的な分析を行うことをお勧めします。

今すぐTiDB Cloudを立ち上げて、TiDBの包括的なオブザーバビリティ機能一式をライブ環境で体験してみましょう。