ハードウェア中級 #2 CPU 深掘り — ターボ・スロットリング・スチールタイム
第1回 で指標を読む枠組みを作ったので、ここからリソースを 1 つずつ見ていきます。最初は CPU です。基礎 #2 でコア、スレッド、クロック、キャッシュの概念を押さえたなら、今回はその部品が運用中に見せる気まぐれを扱います。スペック表どおりに回らないクロック、自分のものなのに自分のものではない vCPU、そしてコアが遊んでいるのに遅いサーバーといったものです。
クロックは固定値ではありません #
スペック表に「3.0GHz」と書かれていても、実際のクロックは毎瞬揺れています。2 つのメカニズムがあるからです。
- ターボブースト (turbo boost) — 電力と温度に余裕があるとき、ベースクロックより高く引き上げる機能です。ポイントは条件付きだという点です。1〜2 コアだけが働くときは高く上がりますが、全コアが忙しいと電力上限のため低いターボにとどまります。「シングルコアのテストでは速かったのに、全コア負荷ではコアあたりの性能が落ちる」現象の正体です。
- サーマルスロットリング (thermal throttling) — 温度が限界に達すると、CPU が自分を守るためにクロックを強制的に下げる動作です。冷却が弱いサーバーや密度の高いラックで、負荷開始の数分後から性能が落ちるパターンとして現れます。
だから CPU の性能問題を見るときは、使用率と一緒に 現在のクロック を確認する習慣が必要です。使用率 100% なのにクロックがベース値を下回っているなら、問題は仕事の量ではなく電力か冷却の側です。
ここに OS の電力ポリシーがもう 1 層あります。Linux の CPU ガバナー (governor、クロックをどんなポリシーで調整するか決める設定) が powersave になっていると、負荷が来てもクロックをゆっくりとしか上げません。レイテンシに敏感なサーバーがこの設定 1 つで鈍くなることが実際にあります。データベースや低レイテンシサービスのマシンなら performance ガバナーを検討します。
スチールタイム — ハイパーバイザーが持っていった時間 #
第1回の CPU 内訳で後回しにした st (steal) を見る番です。スチールタイム (steal time) は、仮想マシンが CPU を使おうとしたのに ハイパーバイザーが物理 CPU を他へ回したせいで回れなかった時間 です。基礎 #7 で見たように、vCPU は物理コアを時分割で分けてもらう約束なので、同じホストの別の仮想マシンが忙しいと自分の番が遅れて来ます。
運用観点の基準はこうです。
- st が 0 付近を保っていれば正常です。
- st が継続的に数パーセントを超えるなら、同じホストにうるさい隣人がいるか、ホストが過積載 (オーバーコミット) の状態です。
- 自分の仮想マシンの中では直す方法がないというのが核心です。処方はインスタンスを別のホストへ移す (再起動・再デプロイ) か、より隔離されたインスタンスタイプに替えることです。
クラウドでバースタブルインスタンス (t 系のようなクレジットベース) なら、似た症状の別の原因もあります。CPU クレジットが尽きるとベースライン性能に制限されます。st とクレジット残量を一緒に見れば、2 つのケースを区別できます。
コンテキストスイッチ — 仕事を切り替えるコスト #
コア数よりはるかに多いスレッドが回ると、CPU は仕事を細かく交互に処理します。この切り替えがコンテキストスイッチ (context switching、実行中の作業の状態を保存して別の作業に乗り換えること) で、タダではありません。状態の保存・復元という直接コストに加えて、基礎 #2 で見たキャッシュに積んでおいたデータが新しい作業にとっては他人のものなので、キャッシュミスが増えるという間接コストが付きます。
症状は第1回の内訳に現れます。us は低いのに sy が高く、秒あたりのコンテキストスイッチ数が普段の数倍 なら、仕事そのものより仕事の切り替えに時間を使っている状態です。よくある原因は、コア数に対して過剰なワーカースレッド設定と、ロック競合で起きては眠るのを繰り返すスレッドたちです。処方はハードウェアではなく設定の側です。ワーカー数をコア数基準に減らすところから始めます。
CPU ピンニング — 席を固定してキャッシュを守る #
デフォルトではスケジューラは作業をどのコアにでも配置し、頻繁に移します。ほとんどのワークロードにはそれが最善ですが、レイテンシに極度に敏感なプロセスは移動するたびにキャッシュを失います。CPU ピンニング (CPU pinning、プロセスを特定のコアに固定する設定) はその移動を止めて、キャッシュヒット率とレイテンシの一貫性を守る手法です。
# PID 1234 のプロセスをコア 2,3 に固定
taskset -cp 2,3 1234ただしピンニングは両刃です。固定したコアが忙しいとき、他のコアが暇でも借りられません。一般的なサービスには不要で、低レイテンシのネットワーク処理やリアルタイム性ワークロードのように レイテンシのばらつきそのものが問題になる場合 だけ取り出す道具です。第4回の NUMA で、このテーマがメモリの配置と一緒にまた登場します。
よく出会う落とし穴 #
- スペック表のクロックで性能を約束する — 全コア負荷の実効クロックはシングルコアターボより低いです。キャパシティプランは全コア負荷基準で測ります。
- st を自分のサーバーの問題と診断する — スチールはホスト側の事情です。仮想マシンの中でプロセスをいくら最適化しても減りません。別ホストへの移行が処方です。
- スレッドを増やして速度を上げようとする — コアが飽和していればスレッド増設はコンテキストスイッチを増やすだけです。増やす前に第1回の飽和指標をまず確認します。
まとめ #
今回つかんだ絵です。
- クロックはターボとスロットリング、ガバナーのポリシーによって揺れます。使用率と一緒に実際のクロックを見ます。
- スチールタイムはハイパーバイザーレベルの競合シグナルで、処方は内部チューニングではなく移行です。
- コンテキストスイッチの暴走は sy の上昇として現れ、よくある原因は過剰なスレッド設定です。
- CPU ピンニングはレイテンシの一貫性が重要なワークロード専用の道具です。
次回 — メモリ深掘り #
次回の「ハードウェア中級 #3 メモリ深掘り — available・ダーティページ・コンテナ上限」では 2 番目のリソースへ進みます。基礎 #3 でページキャッシュと OOM Killer の概念を押さえたなら、次は free の出力を正確に読む方法、書き込みの暴走を生むダーティページ、そしてコンテナ時代のメモリ上限まで、運用の層を上げます。