CPU pinning を外すことは、単なる性能 tuning の取り消しではありません。VM の実行資源を、専有に近い状態から host scheduler による共有実行へ戻す設計変更です。
平均 throughput がほとんど変わらなくても、tail latency、jitter、packet drop、性能の再現性、障害切り分けの前提は変わる可能性があります。特に NFV、仮想 router、仮想 firewall、低遅延 workload では、変更前後を同じ条件で測定する必要があります。
書籍
CPU 仮想化支援、メモリ仮想化、割り込み、仮想デバイスなど、VM の実行モデルを低レイヤから理解する参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
CPU pinning が決めていること
| 状態 | 実行モデル | 運用上の特徴 |
|---|---|---|
| pinning あり | vCPU の実行先を限定する | 競合範囲を読みやすいが、scheduler の自由度は下がる |
| pinning なし | 許可された CPU pool で共有する | 空き CPU を使いやすいが、他 workload の影響を受ける |
| isolated CPU と併用 | host の通常処理から CPU を分ける | vCPU 以外の thread と IRQ も含めた設計が必要 |
| overcommit と併用 | 複数 vCPU が物理 CPU を共有する | run queue と待ち時間の変動を監視する |
pinning は VM を必ず高速化する設定ではありません。改善したい指標と競合させたくない処理を決め、実行場所を限定する手段です。解除する場合は、その限定をどこまで戻すのかを明確にします。
外す対象を分けて確認する
| 対象 | 役割 | 解除時の注意 |
|---|---|---|
vcpupin | vCPU thread の affinity | 一部の vCPU だけ残さず、全 vCPU を確認する |
emulatorpin | QEMU emulator thread の affinity | vCPU だけ解除すると補助処理の配置方針が残る |
iothreadpin | QEMU I/O thread の affinity | storage I/O の競合範囲が変わる |
numatune | ゲストメモリの NUMA policy | CPU だけ共有化しても memory policy は別に残る |
| cpuset / isolated CPU | host 側の実行可能 CPU | VM の XML だけでは host の予約 CPU は戻らない |
| capacity reservation | 運用上の専有枠 | 監視、配置、台帳、課金の前提も更新する |
vcpupin を削除しただけで、完全に共有実行へ戻ったとは限りません。emulator thread、I/O thread、NUMA memory policy、host の cpuset、IRQ affinity、予約 CPU を別々に確認します。
変更前の live 設定と永続設定を記録する
実行中の設定と次回起動時の設定は一致しているとは限りません。変更前に両方を保存し、CPU topology と NUMA node の対応も記録します。
virsh dumpxml vm01
virsh dumpxml vm01 --inactive
virsh vcpuinfo vm01
virsh vcpupin vm01 --live
virsh vcpupin vm01 --config
virsh emulatorpin vm01 --live
virsh emulatorpin vm01 --config
virsh numatune vm01
lscpu -e=CPU,NODE,SOCKET,CORE,ONLINE
numactl --hardware--live は実行中の domain、--config は永続設定を対象にします。live だけを変更すると再起動後に戻り、config だけを変更すると実行中の VM には直ちに反映されません。
XML から削除する範囲を確認する
次は vCPU と emulator thread を固定している例です。共有実行へ戻す場合は、対象となる pinning 要素を永続 XML から削除します。ただし、cputune 内に quota、period、shares など他の制御がある場合は、cputune 全体を削除しません。
<cputune>
<vcpupin vcpu='0' cpuset='2'/>
<vcpupin vcpu='1' cpuset='3'/>
<emulatorpin cpuset='0-1'/>
</cputune>NUMA memory policy を残すかは別の判断です。CPU affinity を広げても numatune の strict policy が残れば、memory allocation は指定 node に制約されます。CPU とメモリを同時に変更すると原因を追いにくいため、段階を分けます。
共有実行で変わること
| 観点 | pinning あり | 解除後 |
|---|---|---|
| scheduler | 実行先が限定される | CPU pool 内で実行先を選びやすい |
| 競合 | 固定先の処理と競合する | 他 VM と host process の影響範囲が広がる |
| tail latency | 条件を固定しやすい | 瞬間的な待ち時間が増える可能性がある |
| capacity | 専有に近い CPU 枠で数える | 共有 pool と overcommit ratio で数える |
| migration | 移行先の CPU map を合わせる | 配置の自由度を上げやすい |
| 障害解析 | CPU ID と競合相手を追いやすい | 時刻ごとの co-tenant と run queue も確認する |
外してよい VM と残す VM を分ける
| 判断 | 条件 |
|---|---|
| 解除を検討する | 一般的な業務 VM で、集約率と migration の柔軟性を優先する |
| 解除を検討する | 現状の CPU 使用率が低く、競合負荷試験でも SLO を満たす |
| 残す候補 | p99 latency、jitter、packet loss に明確な上限がある |
| 残す候補 | DPDK、vhost-user、SR-IOV、NFV で CPU と NIC queue を対応付けている |
| 残す候補 | 性能保証の契約や専有 capacity の前提がある |
| 再設計する | 固定 CPU が他 VM と重複し、専有の前提が成立していない |
パブリック cloud では物理 CPU の詳細が見えなくても、dedicated host、専有 instance、placement、CPU overcommit の選択が同じ判断に関係します。制御できる範囲と性能保証の境界を確認します。
capacity を共有 CPU pool で再計算する
解除前の capacity を固定 CPU 数だけで管理していた場合、その数をそのまま共有 pool の余力とはみなしません。物理 core、SMT sibling、host 用 CPU、既存 vCPU、overcommit ratio、通常負荷と peak 負荷を使って再計算します。
- 物理 core と SMT thread を別の単位として記録する
- host OS、QEMU、IRQ、監視処理の headroom を残す
- 平均 CPU 使用率だけでなく run queue と steal を確認する
- 障害時に VM が片側 host へ寄った状態でも SLO を満たせるか確認する
- 固定 CPU の解放後に別 VM を詰め込みすぎない
単独試験と競合負荷試験を分ける
VM 単独の benchmark だけでは、共有実行へ戻した影響を評価できません。変更前後で同じ workload を実行し、さらに同じ host の別 VM や host process に負荷を加えた状態を比較します。
virsh domstats vm01 --cpu-total --vcpu --memory
mpstat -P ALL 1
pidstat -u -t 1
numastat -c
cat /proc/interrupts| 試験 | 確認すること |
|---|---|
| baseline | 変更前の throughput、p50、p95、p99、drop、CPU 使用率 |
| 解除後の単独負荷 | pinning 以外の条件を変えず、同じ時間と request 数で比較する |
| co-tenant 負荷 | 別 VM の CPU 負荷で latency と jitter が許容範囲にあるか |
| I/O 併用 | softirq、I/O thread、packet drop、storage latency の変化を見る |
| 再起動後 | 永続設定が反映され、同じ結果を再現できるか |
| migration 後 | 移行先でも NUMA と capacity の条件を満たすか |
平均値と tail latency を一緒に見る
平均 throughput が維持されても、p99 latency や jitter が悪化すれば、低遅延サービスでは同じ品質とはいえません。CPU 使用率に加えて、run queue、steal、context switch、softirq、packet drop、retransmission を同じ時刻軸で確認します。
- p50、p95、p99 latency と最大値
- throughput、packet per second、request per second
- host CPU、guest CPU、steal、run queue
- softirq、IRQ、network drop、retransmission
- NUMA remote access と memory pressure
- 同じ host で動く VM と batch job の負荷
ロールバック条件を変更前に決める
変更後に判断を迷わないよう、SLO と capacity の閾値を先に決めます。p99 latency、packet drop、throughput、CPU wait のいずれかが許容値を超えた場合は、保存した XML と CPU map を使って元の affinity へ戻します。
ロールバックでは vcpupin だけでなく、emulatorpin、iothreadpin、numatune、host の isolated CPU、IRQ affinity まで対象を照合します。live と config の片方だけを戻さないことも重要です。
よくある失敗
| 失敗 | 問題 | 確認すること |
|---|---|---|
| vCPU pinning だけを外す | 補助 thread と memory policy が残る | emulator、I/O、NUMA、cpuset |
| live だけを変更する | 再起動後に元へ戻る | live と config の差分 |
| config だけを変更する | 実行中の VM は旧設定のまま | 適用時刻と再起動計画 |
| 平均値だけで合格にする | tail latency と jitter を見落とす | p95、p99、最大値、drop |
| 単独負荷だけで試す | noisy neighbor の影響が分からない | co-tenant 負荷試験 |
| 解放した CPU をすぐ埋める | 障害時と peak 時の余力がなくなる | headroom と縮退 capacity |
まとめ
CPU pinning の解除は、VM を遅くするか速くするかだけの話ではありません。実行資源を専有に近い状態から共有実行へ戻し、scheduler の自由度を上げる代わりに、他 workload との競合範囲と性能変動の可能性を広げます。
最初に live / config の affinity、NUMA memory policy、host の予約 CPU を記録します。その後、capacity を共有 pool として再計算し、単独負荷と co-tenant 負荷で tail latency まで比較します。解除対象、合格基準、ロールバック条件を一組で管理することが、安全に共有実行へ戻すための要点です。
関連記事
VM の CPU / NUMA 設計 – vCPU pinning とメモリ配置を確認する
VM パフォーマンス最適化の進め方 – 計測、仮説、変更、再検証
VM の性能ボトルネックを見分ける – guest / host / backend の切り分け
VM パフォーマンス設計ガイド
単一 VM の vCPU sizing – 物理 core / SMT / NUMA / overcommit で決める
VM の HugePages / TLB / NUMA 設計 – page size と memory placement を確認する
DPDK とは何か – 高速化ではなくパケット処理の場所を変える技術
DPDK で VM ネットワークはなぜ速くなるのか – kernel bypass と NFV dataplane