Overselling ist eine verbreitete Praxis unter VPS-Anbietern, die deine Server-Performance still verschlechtern kann. So funktioniert es, und darauf solltest du bei der Wahl deines Hosts achten.
Veröffentlicht am: 5/22/2026
Wenn sich dein VPS träge anfühlt, obwohl die Spezifikationen auf dem Papier in Ordnung wirken, kann Overselling der Grund sein. Es ist eine der verbreitetsten Praktiken in der Hosting-Branche, und die meisten Anbieter werben nicht damit. Wer versteht, wie es funktioniert, trifft eine bessere Kaufentscheidung und zahlt nicht für Ressourcen, die in der Praxis gar nicht zuverlässig bereitstehen.
Von Overselling spricht man, wenn ein Hosting-Anbieter mehr Ressourcen vergibt, als die physische Hardware tatsächlich hat. Die Logik dahinter stammt aus der Luftfahrt: Nicht jeder Passagier erscheint, also verkauft man mehr Sitze, als das Flugzeug fasst. Auf Hosting übertragen heißt das: Nicht jeder Kunde nutzt seine volle Zuteilung gleichzeitig, also passen theoretisch mehr VPS-Instanzen auf einen Server, als die Spezifikationen eigentlich erlauben würden.
Beim klassischen Shared Hosting ist das nahezu universell akzeptiert. Beim VPS-Hosting ist die Ausgangslage aber eine andere. Kunden zahlen für dedizierte, isolierte Ressourcen, und Overselling untergräbt genau diese Erwartung.
RAM lässt sich am leichtesten überbuchen, und das ist extrem verbreitet. Ein Anbieter hat zum Beispiel einen physischen Host mit 256 GB RAM, vergibt aber VPS-Instanzen, die zusammen 512 GB oder mehr ausmachen. Bei niedriger Auslastung funktioniert das problemlos. Sobald mehrere Kunden gleichzeitig ihren zugeteilten RAM tatsächlich nutzen, geht dem Host der physische Speicher aus, er beginnt auf die Festplatte auszulagern oder, schlimmer, beendet im Notfall Prozesse über den OOM-Killer (Out-of-Memory).
Aus deiner Sicht sieht das so aus: Deine Anwendung stürzt plötzlich ab, Dienste starten unerwartet neu oder alles gerät fast zum Stillstand. Das kann wie ein Bug in deiner Software wirken, obwohl der eigentliche Grund darin liegt, dass dem Host der physische Speicher ausgeht.
Manche Anbieter setzen Memory Ballooning in ihren Hypervisoren ein, um nicht genutzten RAM dynamisch von inaktiven VMs zurückzuholen. Das ist etwas ehrlicher als reines Overselling, bedeutet aber trotzdem, dass dein zugeteilter Speicher nicht garantiert ist.
Beim Thema CPU ist es etwas differenzierter. Moderne Hypervisoren erlauben es, virtuellen Maschinen mehr vCPUs zuzuweisen, als der physische Host an logischen Kernen hat. Ein Server mit 64 physischen Threads kann VMs mit insgesamt 200 vCPUs hosten. Solange die meisten VMs inaktiv sind, kommt der Scheduler damit klar.
Das Problem zeigt sich unter Last. Wenn mehrere Kunden gleichzeitig CPU-intensive Workloads ausführen, konkurrieren sie alle um dieselben physischen Threads. Der Scheduler muss aggressiv time-slicen, und deine Tasks landen in der Warteschlange. Das wird als CPU Steal Time sichtbar — also der Anteil der Zeit, in der deine vCPU auf physischen CPU-Zugriff wartet, den der Hypervisor nicht freigibt.
Hohe Steal Time ist ein zuverlässiges Signal dafür, dass dein Host CPU überbucht. Tools wie top, vmstat oder sar zeigen unter Linux die "st"-Spalte, in der Steal direkt abzulesen ist. Wenn du dauerhaft mehr als 5–10 % Steal siehst, teilt sich dein VPS die CPU mit mehr VMs, als sinnvoll wäre.
Storage-Overselling folgt demselben Muster. Anbieter vergeben in Summe mehr Plattenspeicher an VMs, als ihre Storage-Arrays physisch hergeben — in der Annahme, dass die meisten Kunden ihre Disks ohnehin nicht füllen. Eine Zeit lang geht das gut, aber sobald der darunterliegende Speicher voll wird, schlagen Schreibvorgänge fehl oder werden drastisch langsamer. Bei drehenden Festplatten war das früher gängig; bei NVMe-Arrays ist es weniger verzeihlich, weil der Performance-Einbruch dort steil und meist unerwartet kommt.
Über die reine Kapazität hinaus kann Storage-Performance auch durch IOPS-Throttling oder Konkurrenz auf gemeinsam genutzten Arrays leiden. Selbst wenn dein Speicherplatz physisch reserviert ist, können mehrere VMs, die dieselbe SSD belasten, deren Schreibdurchsatz sättigen.
Egal ob RAM, CPU oder Disk: Overselling führt zu dem, was häufig als Noisy-Neighbor-Problem beschrieben wird. Dein VPS teilt sich einen physischen Host mit anderen Kunden. Startet einer von ihnen einen Backup-Job, kompiliert eine große Codebasis oder bedient einen Traffic-Peak, kann er unverhältnismäßig viele Ressourcen ziehen und alle anderen VMs auf derselben Maschine ausbremsen.
Auf einem überbuchten Host kann ein einziger stark ausgelasteter Kunde die ganze Maschine destabilisieren. Genau deshalb wirkt VPS-Performance manchmal stark inkonsistent — blitzschnell um 2 Uhr nachts, zäh um die Mittagszeit. Diese Schwankungen sind nicht zufällig; sie hängen direkt daran, wie ausgelastet deine Nachbarn gerade sind.
Es gibt ein paar praktische Methoden, das zu prüfen.
Beobachte die CPU Steal Time. Wie erwähnt ist die st-Spalte in top das deutlichste Signal. Starte einen CPU-intensiven Task und schau, ob Steal hochläuft.
Mach einen Memory-Pressure-Test. Tools wie stress-ng reservieren Speicher und zeigen, ob dein System unter einer Last ins Swappen gerät, die es eigentlich problemlos verkraften müsste.
Benchmarke regelmäßig den Disk-Durchsatz. Mit fio kannst du sequenzielle und zufällige Lese- und Schreibgeschwindigkeiten zu verschiedenen Tageszeiten messen. Große Schwankungen zwischen den Messungen deuten auf Konkurrenz im gemeinsamen Storage-Pool hin.
Überwache die Grundlatenz. Unerklärliche Latenz-Spikes, vor allem bei leichter Last, kommen oft von Scheduling-Verzögerungen im Hypervisor auf einem stark belasteten Host.
Anbieter, die nicht überbuchen, garantieren dir, dass die Ressourcen, für die du bezahlst, physisch für deine Instanz reserviert sind. Dein RAM ist exklusiv deiner VM zugeordnet und kommt nicht aus einem geteilten Pool. Deine vCPUs entsprechen echten Threads, die nicht an fünfzig andere VMs weitergereicht werden. Dein NVMe-Speicher stammt aus Kapazität, die tatsächlich auf der Disk vorhanden ist.
Der praktische Unterschied zeigt sich in der Konsistenz. Benchmarks zu unterschiedlichen Tageszeiten liefern vergleichbare Ergebnisse. CPU Steal bleibt niedrig oder bei null. Speicherintensive Anwendungen stürzen nicht zufällig ab. Der Disk-Durchsatz ist vorhersehbar.
Das wirkt sich auch auf die Dimensionierung aus. Wer eine Datenbank oder einen Caching-Layer betreibt, kann sich bei überbuchtem RAM nicht auf seine Speichergrenzen verlassen. Du stellst deinen MySQL-Buffer-Pool vielleicht auf 80 % des zugeteilten RAMs ein und stellst dann fest, dass dieser Speicher physisch nie wirklich nur dir zur Verfügung stand.
Die ehrliche Antwort lautet: Marge. Physische Hardware ist teuer, und ein Anbieter, der Ressourcen 1:1 vergibt, muss mehr verlangen, um seine Kosten zu decken, als jemand, der dieselben Spezifikationen mit einer Overcommit-Ratio von 2:1 oder 3:1 verkauft. Für viele Workloads — etwa kleine Websites mit wenig Traffic oder Entwicklungsumgebungen — fällt Overselling im Alltag tatsächlich kaum auf. Das Problem ist nur, dass Kunden, die einen überbuchten VPS für Produktion kaufen, das oft erst dann merken, wenn etwas schiefläuft.
Einige Anbieter werben offen mit "kein Overselling" oder "garantierten Ressourcen". Genau danach lohnt es sich zu suchen. Andere erwähnen das Thema mit keinem Wort, was in der Regel ein Zeichen ist, vor dem Abschluss noch etwas genauer hinzusehen.
Overselling ist ein echtes Performance-Risiko, gerade für alle, die produktive Dienste auf einem VPS betreiben. Wenn dein Workload auf vorhersehbaren Speicher, CPU-Zugriff oder Disk-Durchsatz angewiesen ist, zählt das, was dein Anbieter tatsächlich garantiert, mehr als die genannten Spezifikationen.
Danke fürs Lesen! Wenn du eine Hosting-Umgebung suchst, in der Ressourcen nie überbucht werden, bietet QDE unmanaged KVM-VPS-Hosting mit dediziertem RAM, reinem NVMe-Speicher und AMD-EPYC- sowie Ryzen-Prozessoren — nichts davon stammt aus einem überbuchten Pool.
Bereit zu starten oder noch Fragen? Kontaktiere unser Team und wir helfen dir, den passenden Tarif für deinen Workload zu finden.
Overselling bedeutet, dass ein Hosting-Anbieter seinen VMs in Summe mehr Ressourcen zuweist, als der zugrunde liegende physische Server tatsächlich besitzt. Das kann RAM, CPU und Storage betreffen und führt häufig zu inkonsistenter oder eingeschränkter Performance unter Spitzenlast.
Das direkteste Signal ist die CPU Steal Time, unter Linux sichtbar in der st-Spalte in top oder vmstat. Dauerhaft mehr als 5 % Steal unter moderater Last deutet auf einen überbuchten Host hin. Zusätzlich kannst du Disk-Durchsatz und Speicher zu unterschiedlichen Tageszeiten benchmarken — große Schwankungen sind ein Warnsignal.
Nicht immer. Für leichte Workloads wie kleine Websites oder Entwicklungsumgebungen kann ein überbuchter VPS die meiste Zeit gut laufen. Probleme treten meist erst unter dauerhafter Last auf oder wenn mehrere Kunden gleichzeitig aktiv sind.
Es beschreibt die Situation, in der ein einzelner Kunde auf einem geteilten physischen Host unverhältnismäßig viele Ressourcen verbraucht und damit die Performance für alle anderen auf derselben Maschine verschlechtert. Es ist eine direkte Folge von Overselling.
Such gezielt nach Anbietern, die ausdrücklich erklären, RAM oder CPU nicht zu überbuchen. Schau dir Benchmarks und unabhängige Reviews an. Frag den Anbieter direkt nach seinen Overcommit-Ratios. Wer ausweicht oder keine Antwort gibt, betreibt häufig Overselling.
RAM ist die am häufigsten überbuchte Ressource, gefolgt von CPU. Auch Storage kann überbucht sein — manche Anbieter setzen dafür Thin-Provisioning-Pools ein, die sich in der Praxis ähnlich verhalten.