# Proxmox CPU Optimization: vCPU Allocation & Sizing für Profis

TL;DR / Management Summary “Viel hilft viel” ist beim VM-Sizing falsch. Jede vCPU, die einer VM zugewiesen wird, muss vom Host-Scheduler verwaltet werden. Ein Senior Admin nutzt das Minimum-Prinzip: Er weist einer VM nur so viele vCPUs zu, wie sie wirklich benötigt. Er beherrscht das Overprovisioning (z.B. Ratio 4:1) und nutzt NUMA (Non-Uniform Memory Access) Einstellungen, um bei Multi-Sockel-Systemen den Speicherzugriff massiv zu beschleunigen.

# 1. Das vCPU Modell

Physische Kerne vs. Logische Threads.

Proxmox nutzt KVM. Eine vCPU ist im Grunde ein Thread auf dem physischen Host.

Overprovisioning: Sie können mehr vCPUs vergeben, als physische Threads vorhanden sind (Standard: bis zu 4:1 ist unkritisch).
Gefahr: Wenn alle VMs gleichzeitig 100% CPU wollen, sinkt die Performance drastisch (CPU Steal Time).

# 2. Einrichtung in der Praxis

Das richtige Sizing.

# CPU Typ (Das wichtigste Flag)

Default (kvm64): Sicher für Migration.
Host (Empfohlen): Die VM sieht die exakte physische CPU des Hosts (inkl. AES-NI).
Wann?: Immer, wenn Sie identische Hardware im Cluster haben.

# Sockets vs. Cores

Regel: Nutzen Sie immer 1 Socket und erhöhen Sie die Anzahl der Cores.
Grund: Windows und einige Linux-Applikationen haben Lizenz- oder Performance-Limits pro Sockel. Ein Multi-Sockel-Setup in der VM simuliert ein komplexes Mainboard, was unnötigen Overhead erzeugt.

# 3. Deep Dive: NUMA (Multi-Socket Optimierung)

Den Speicherweg verkürzen.

Wenn Ihr Server zwei physische CPUs (Sockel) hat, ist der RAM physisch an einen der Sockel gebunden. Greift CPU 1 auf RAM von CPU 2 zu -> Latenz!

Aktion: Aktivieren Sie den Haken NUMA in den VM-Optionen.
Wirkung: Der Hypervisor versucht, vCPUs und RAM der VM auf dem gleichen physischen Sockel zu halten.

# 4. Day-2 Operations: CPU Units & Priorisierung

Den ‘Noisy Neighbor’ bändigen.

Wenn zwei VMs gleichzeitig 100% CPU wollen:

Aktion: VM -> Hardware -> CPU -> Edit -> CPU units.
Einstellung: 1024 (Standard). Setzen Sie 2048 für Ihren DC und 512 für den Test-Webserver.
Vorteil: Der DC bekommt im Konfliktfall doppelt so viel Rechenzeit.

# 5. Troubleshooting & “War Stories”

Wenn die CPU-Last ‘lügt’.

# Top 3 Fehlerbilder

Symptom: VM zeigt 10% Last, aber der Host 100%.
- Ursache: Interrupt-Storm durch inkompatible Treiber oder Emulation (Artikel 666).
- Lösung: Auf VirtIO Treiber wechseln.
Symptom: Hohe CPU Steal Time im Gast.
- Ursache: Zu extremes Overprovisioning am Host.
- Lösung: VMs auf andere Knoten migrieren (Artikel 672).
Symptom: Applikation im Gast nutzt nur einen Kern, obwohl 4 zugewiesen sind.
- Ursache: Single-Threaded Applikation.
- Fix: Erhöhen Sie die Single-Core Taktrate des Hosts statt der vCPU-Anzahl.

# “War Story”: Die “Viel-hilft-viel” Falle

Ein Admin gab jeder kleinen 1-Core Web-VM 8 vCPUs, “um Puffer zu haben”. Der Host hatte 16 physische Kerne. Das Ergebnis: Der Host war unbedienbar langsam bei nur 20% echter Gesamtauslastung. Die Ursache: Der KVM-Scheduler musste für jede VM warten, bis 8 physische Kerne gleichzeitig frei waren, um die VM für einen Zyklus auszuführen. Die VMs standen sich gegenseitig im Weg. Lösung: Reduzierung der vCPUs auf 2 pro VM. Der Host wurde schlagartig reaktionsschnell, und der Durchsatz der Webserver verdoppelte sich. Lehre: vCPU Sizing ist eine Übung in Bescheidenheit.

# 6. Monitoring & Reporting

Statistiken der Rechenkraft.

# htop am Host

Beobachten Sie die Lastverteilung:

htop

KPI: Load Average. Sollte dauerhaft nicht über der Anzahl der physischen Threads liegen.

# 7. Fazit & Empfehlung

CPU-Tuning ist das Feintuning des Datacenters.

Empfehlung: Nutzen Sie CPU Type: host für maximale Leistung.
Wichtig: Überwachen Sie die CPU Steal Time in Ihren VMs. Wenn dieser Wert steigt, ist es Zeit für neue Hardware oder eine bessere Lastverteilung.

# Anhang: Cheatsheet (vCPU Sizing)

VM Typ	Empfehlung vCPUs	Besonderheit
Domain Controller	2	Hohe Priorität (Units)
SQL Server	4-16	NUMA aktivieren!
Docker Host	2-4	Host CPU nutzen
Test/Lab	1	Geringe Priorität