Proxmox-Stolperstein: Das vergessene CPU-Limit

Ausgangslage

Eine VM im Cluster lief seit Monaten unauffällig – ein produktiver Dienst, der seine Arbeit tat und keine Aufmerksamkeit mehr brauchte. Irgendwann, vor längerer Zeit, hatte ich für diese VM ein CPU-Limit gesetzt: 0.3 vCPUs. Der Grund damals war nachvollziehbar – ein Testszenario, bei dem ich verhindern wollte, dass ein einzelner Prozess die restlichen VMs auf demselben Node ausbremst. Danach ist die Einstellung einfach liegen geblieben, unauffällig, weil die VM im Alltag kaum Last erzeugte.

Problem

Nach einem Neustart der VM wurde es plötzlich zäh. Der Bootvorgang dauerte spürbar länger als gewohnt, und der anschliessende Login – ob per SSH oder über einen Dienst mit Web-Login – reagierte quälend langsam oder schien streckenweise ganz zu hängen. Die ersten Verdächtigen waren die üblichen: Storage-Latenz, Netzwerkprobleme, ein hängender Dienst beim Start, vielleicht ein Full-Table-Scan in einer Datenbank. Ich habe im Proxmox-Log nachgesehen, iostat und top auf dem Node geprüft, DNS-Auflösung kontrolliert – nirgends ein offensichtlicher Engpass. Die restlichen VMs auf demselben Node liefen normal, der Node selbst war nicht überlastet.

Was das Debugging zusätzlich erschwert hat: In der Proxmox-Übersicht sieht man auf den ersten Blick primär CPU-Auslastung in Prozent bezogen auf die zugewiesenen Cores – nicht sofort, dass ein CPU-Limit den effektiv verfügbaren Takt drastisch einschränkt. Die VM hatte nominell mehrere vCPUs zugewiesen, wirkte also grosszügig dimensioniert. Dass davon durch das Limit nur ein Bruchteil tatsächlich nutzbar war, ist in der Übersicht nicht sofort ersichtlich.

Auflösung

Erst ein gezielter Blick in die VM-Optionen (Hardware/CPU in der Proxmox-Weboberfläche, respektive cpulimit in der Konfiguration) brachte die Ursache zutage: Das CPU-Limit von 0.3 war immer noch aktiv. Für den normalen Betrieb bei geringer Last fällt das kaum auf – sobald aber beim Boot oder beim Login mehrere Prozesse gleichzeitig CPU-Zeit brauchen (Dienste starten, Authentifizierung, Initialisierung), reicht ein Limit von 0.3 vCPUs bei weitem nicht aus. Die VM war faktisch auf einen Bruchteil eines Kerns eingebremst, unabhängig davon, wie viele Cores ihr zugewiesen waren.

Die Korrektur war denkbar einfach: Limit entfernen respektive auf einen sinnvollen Wert setzen, VM neu starten – Bootzeit und Login-Verhalten waren sofort wieder normal.

Lessons Learned

• CPU-Limits sind leise Fallen. Sie greifen nicht sichtbar in der Standardansicht und fallen bei niedriger Grundlast oft monatelang nicht auf – bis ein Moment mit höherem CPU-Bedarf (z. B. ein Neustart) das Limit schmerzhaft sichtbar macht.
• cpulimit ist etwas anderes als cores. Die Anzahl zugewiesener Cores sagt nichts darüber aus, wie viel CPU-Zeit davon tatsächlich genutzt werden darf. Beide Werte gehören bei der Fehlersuche gleichermassen geprüft.
• Temporäre Einstellungen dokumentieren oder terminieren. Ein CPU-Limit, das für einen konkreten, zeitlich begrenzten Zweck gesetzt wird, sollte entweder mit einem Kommentar/Reminder versehen oder nach Abschluss des Tests aktiv wieder entfernt werden. Ohne das verschwindet der Kontext irgendwann komplett.
• Bei „läuft plötzlich langsam“ gehört die VM-Konfiguration selbst früh auf die Checkliste – nicht erst Storage, Netzwerk und Applikationslogs, sondern auch ein kurzer Blick auf CPU-Limit, Memory-Ballooning und ähnliche Ressourcenbeschränkungen direkt in Proxmox.

Fazit

Nicht jedes Performance-Problem liegt im Storage, im Netzwerk oder in der Applikation – manchmal steckt es in einer eigenen, längst vergessenen Einstellung. Ein CPU-Limit von 0.3 vCPUs ist im Proxmox-Alltag schnell gesetzt und ebenso schnell vergessen, entfaltet seine volle Wirkung aber genau dann, wenn man es am wenigsten gebrauchen kann – beim Boot oder beim Login. Ein kurzer Blick in die VM-Ressourcenkonfiguration gehört deshalb künftig früh in meine Troubleshooting-Checkliste, nicht erst als letzter Ausweg.