ProxmoxのCPUオーバーコミット比率に共通の正解はありません。今週はVMごとのピーク負荷とホストのCPU待ちを記録し、同時に動く負荷に合わせてvCPUを調整してください。争奪が続く場合は、不要なvCPUを減らすか負荷を分けてから、独占型の物理サーバー容量を見直します。
対象は、新しいVMへのvCPU割り当てに迷うProxmox管理者、多数のVMを運用するMSPや小規模VPS事業者、監視値からホストの余力を判断したい企業IT担当者です。
今週の作業順： まず業務ピークを記録し、次に代表的なVMで配分を試し、変更前後の応答とCPU待ちを比較します。短時間の平均値だけで割り当てを決めないことが重要です。
Proxmox CPUオーバーコミット率は配分と稼働負荷を分けて考える
vCPUの割り当て合計がホストの論理スレッド数を超えても、全VMが常に同時にCPU時間を必要とするわけではありません。一方、同時に計算を行うVMが重なると、割り当て済みのvCPU数だけでは見えない待ち時間が生じます。
そのため、確認する項目は次のように分けます。
- 割り当て量： VMごとのvCPU数と合計。これは予約済みの物理コア数そのものではありません。
- 実際の同時負荷： どのVMが、どの時間帯にCPUを使うか。開発環境の断続的な処理と、継続的な計算処理は分けて記録します。
- 待ちと業務影響： ホスト側・ゲスト側のCPU利用状況に加え、応答時間やジョブの完了状況を見ます。
Proxmox VE 9.2は公式発表で2026年5月21日に公開されています。ただし、リリース情報は特定のCPUオーバーコミット率や単機性能を保証するものではありません。Proxmox VE 9.2の公式発表と、Proxmox VE 9.x管理ガイドを基準に、実環境の設定を確認してください。
| 負荷の傾向 | 割り当て時に重視する点 | 適合の目安 |
|---|---|---|
| 開発・検証環境。利用時間が分散する | 同時に稼働するVMと、テスト実行が重なる時間帯 | 共有を試しやすい |
| 内部サービス。利用ピークが決まっている | ピーク時の応答時間とサービスの優先順位 | 重要VMを優先 |
| 継続的な計算処理 | 長時間のCPU使用と処理待ちの継続性 | 余力を多めに評価 |
| 複数顧客のVM。ピークが重なりうる | 顧客ごとの稼働記録と、負荷が集中する時間帯 | 個別に制限・監視 |
この表は実測性能の評価ではなく、負荷を分類するための判断軸です。平均使用率が低くても、短いピークが業務の遅延につながるなら、ピークの時間帯を基準に配分を検討します。
vCPUの合計はホストの論理スレッド数を超えてよいか
超える設定自体は可能ですが、合計値を同時に使えるCPU性能とみなしてはいけません。vCPUのリソース計画では、割り当て合計と同時に稼働する負荷を別々に記録し、ピーク時に必要なサービス品質を満たすかを確認します。
物理コア数と論理スレッド数のどちらを計算の基準にするかも、単純な一方選びにはできません。SMTによる論理スレッドは物理コアと同じ処理能力を意味しないため、仕様上のスレッド数をそのままVMに配れる性能として扱わず、実際の処理と待ちを観察します。
| 見方 | 分かること | 判断に使うときの注意 |
|---|---|---|
| 物理コア | CPUのコア構成 | 論理スレッドと同じ性能とは扱わない |
| 論理スレッド | OSから見える処理単位 | VMの実効性能や同時処理量を保証しない |
| vCPU割り当て合計 | VMに設定した仮想CPUの総数 | 同時に消費されるCPU時間を示す値ではない |
| ピーク時の実負荷 | 実際にCPUを必要とする時間帯 | 継続時間と業務上の許容遅延も併せて見る |
物理コアと論理スレッドのどちらで計算するか
どちらか一方の数値だけで固定比率を作るのではなく、CPUの構成を把握したうえで、業務のピーク時に実測した負荷を基準にします。比較検討でCPUの型番やコア数を見ることは有用ですが、構成表だけからVM数や性能を断定することはできません。
vCPUの大きさとスケジューリングを業務に合わせる
すべてのVMに多くのvCPUを割り当てる運用は避けてください。小さな処理を行うVMと、並列処理を必要とするVMでは適切な割り当てが異なります。大きなvCPU構成が必要な処理もありますが、不要な割り当てを増やすだけでは実負荷の改善につながらない場合があります。
ProxmoxではCPUの上限や相対的な優先度などを設定できます。上限はVMが使えるCPU量を制御するもの、優先度は競合時の配分に関係するものとして区別してください。VMのCPU設定とコマンドは、対象バージョンの管理ガイドおよび仮想マシン管理コマンドの仕様で確認します。LXCの設定へVMの項目をそのまま適用せず、コンテナ側の仕様も確認してください。
設定変更の前に対象VMの構成と復旧手順を記録し、業務影響の少ない時間帯を選びます。変更後に悪化した場合に元の値へ戻せる状態を作ってから実施してください。
CPU争奪の兆候を複数の指標で確かめる
ホストのCPU使用率が高いだけで、超過割り当てが原因とは断定できません。逆に、平均使用率が低くても、特定の時間帯だけVMの応答が悪化することがあります。ホストとゲスト双方の値、実際の業務応答を同じ時間帯で比較します。
確認手順は次のとおりです。
- VMごとの役割とピーク時間を記録します。 定期処理や開発テストなど、負荷の原因も併記します。
- 割り当てを一覧にします。 VMのvCPU数と合計を記録し、コンテナは別枠で管理します。
- ホストとゲストのCPU状況を同時に確認します。
topなどで利用状況を見て、ゲスト内のCPU待ちや応答の変化も調べます。 - 負荷の推移を記録します。 Linuxの
/proc/loadavgは実行待ちだけでなく、特定の状態で待機するタスクも含むため、CPU使用率の代用として読み替えないでください。load averageの説明も参照します。 - 短い突発と継続的な遅延を区別します。 処理時間、応答時間、ピークの長さを、利用者が許容できる水準と照合します。
- 一度に一種類の変更を行います。 vCPU数、上限、優先度のどれを変えたかを記録し、変更前後を同じ種類の負荷で比較します。
CPU使用率やロード値だけでは原因を特定できません。I/O待ちやゲスト内の処理なども候補になります。Proxmox公式フォーラムのCPU使用率に関する議論や、ProxmoxコミュニティのvCPU割り当てに関する議論は、個別環境の経験談として参考にし、公式の推奨比率として扱わないでください。
高負荷時はvCPUを減らすか、物理容量を見直すか
高負荷時にVMが遅くなった場合、まず負荷の発生元と必要なvCPU数を確認します。次の条件分岐で対応を選び、単にvCPUを追加して配分総量を増やす方法は避けます。
- 実負荷に対してvCPUを過剰に割り当てている場合： 不要な割り当てを縮小し、変更前後の応答を比較します。
- 優先度の低い処理が重要VMと競合している場合： 負荷の時間帯や配置を調整し、必要に応じてCPU上限や優先度を見直します。
- 継続的な争奪があり、合理的な配分変更でも改善しない場合： 物理CPU容量の再評価、またはワークロードの分割を検討します。
- ピーク時にも余力があり、応答目標を満たしている場合： 固定比率に合わせて割り当てを増やさず、現状を記録して継続監視します。
NodeKVMの独立サーバー仮想化を検討する場合は、構成表のスペックを実測性能と混同せず、自身の負荷記録と照合してください。現在選べる構成には、AMD EPYC 7543Pの32コア／64スレッド、128GBまたは256GBのメモリー、直結の1TB NVMeが2台あり、追加の2TB NVMeは最大2台です。帯域は250Mbps、1Gbps、2Gbpsから選択でき、Proxmox VE 8／9の無料イメージにも対応しています。これらはNodeKVMの提供構成で確認できる仕様であり、VM数や処理性能を保証するものではありません。
CPUだけでなく、メモリー容量、必要なディスク構成、ネットワーク使用量も合わせて確認します。帯域の選択は、無制限転送量で帯域を選ぶ考え方も参考にし、VMのCPU計画とは別の条件として整理してください。契約期間は月払い・四半期払い・半年払い・年払いから選べます。具体的な料金と選択肢はNodeKVMの料金・構成案内で確認できます。
共有型の仮想サーバーでは、他の利用者とCPUを共有し、負荷の影響を受ける場合があります。また、CPUの割り当てと実際の処理能力が一致するとは限らず、ディスクや帯域の選択肢も提供形態によって異なります。ピーク負荷の記録をもとに、共有環境のまま調整できるか、それとも独占型のAMD物理サーバーが合うかを比較してください。まずはNodeKVMの実際の構成と料金を照合し、要件に合う場合に限って移行や契約を検討するのが適切です。