Sechs klar benennbare technische Fehlerquellen erklären, warum Shared Hosting unter realer Last ausfällt: Ressourcenkonflikte durch Noisy Neighbors, Docker-Container, die der OOM-Killer beendet, Limits für Datenbankverbindungen und Prozessgrenzen. Der Server ist nicht einfach nur „zu langsam.“ Für jede Ursache gibt es ein direkt prüfbares Diagnosesignal, und alle verweisen auf dieselbe Lösung: dedizierte, isolierte Ressourcen, wie sie nur ein VPS bereitstellt.
| Symptom | Tatsächliche Ursache | Was du prüfen solltest |
|---|---|---|
| Antwortzeiten verschlechtern sich monatlich, obwohl der Traffic gleich bleibt | Ressourcenkonflikte durch Noisy Neighbors / CPU Steal | CPU-Steal-Zeit (st) und I/O-Wait per Monitoring prüfen |
| Docker-Setups mit mehreren Containern stürzen wegen Speicherfehlern ab | Eingeschränkter Swap beim Shared Hosting + cgroup-Limits | Explizite Speicherlimits für Container setzen und auf OOM-Kills prüfen |
| Website bleibt nach dem Wechsel zum größten Shared-Plan langsam | Architektonische Grenze: weiterhin geteilter Kernel, kein Root-Zugriff, keine dedizierte I/O-Leistung | Prüfen, ob CPU, I/O oder Datenbank den Flaschenhals bilden. Ein größerer Shared-Plan ändert daran möglicherweise nichts |
| Anwendung stürzt gezielt bei Traffic-Spitzen ab | Ressourcenlimits + Limits für Datenbankverbindungen + Prozessgrenzen werden gleichzeitig erreicht | Zuerst Caching und ein CDN einrichten; bei häufigen Spitzen migrieren |
| Entwicklungsteam erreicht bereits beim Testen von Funktionen die Ressourcenlimits | Staging-Umgebungen unterliegen denselben Limits wie die Produktion | Ressourcenpools für Staging und Produktion trennen |
Das Muster ist klar: Bei keinem dieser Fälle geht es nur um die reine Geschwindigkeit. Ursache ist die fehlende Ressourcenisolation, die Shared Hosting per Definition nicht bietet.
Der Kernunterschied: isolierte und geteilte Ressourcen
Beim Shared Hosting liegen viele Accounts auf demselben physischen Server und greifen auf denselben Pool aus CPU, RAM und I/O zu. Es gibt keine feste Grenze, die verhindert, dass die Lastspitze eines Accounts alle anderen beeinträchtigt. Ein VPS teilt dieselbe physische Hardware per Hypervisor in tatsächlich isolierte Instanzen auf. Jede erhält eigens reservierte Ressourcen sowie Root-Zugriff, damit du das Betriebssystem konfigurieren, benötigte Software installieren und die Ressourcennutzung genau steuern kannst. Der Preisunterschied beruht auf einer realen architektonischen Abweichung und nicht nur auf einer anderen Marketingstufe.
Noisy Neighbors und CPU-Steal-Zeit
Wenn sich die Antwortzeiten Monat für Monat unauffällig verschlechtern, obwohl sich dein eigener Traffic kaum verändert, steckt oft das klassische Noisy-Neighbor-Problem dahinter. Ein anderer Mandant auf derselben physischen Hardware beansprucht einen unverhältnismäßig großen Anteil an CPU, I/O oder Netzwerkbandbreite und entzieht deiner Anwendung benötigte Ressourcen. Du musst hier nicht blind raten: Die CPU-Steal-Zeit, also die Spalte „st“ in top oder ähnlichen Monitoring-Tools, misst genau, wie viel CPU-Zeit der Hypervisor deiner Instanz zugunsten anderer Mandanten vorenthält. Eine erhöhte Steal-Zeit zusammen mit hohem I/O-Wait weist direkt und messbar auf Ressourcenkonflikte hin, statt auf einen Fehler im Code deiner Anwendung.
Docker-Speicherlimits und der OOM-Killer
Mehrere Docker-Container auf Shared Hosting führen fast zwangsläufig zu Abstürzen durch den OOM-Killer (Out Of Memory), weil Shared-Umgebungen den Swap-Speicher meist einschränken oder vollständig deaktivieren und feste cgroup-Speichergrenzen durchsetzen. Ohne ein explizites Speicherlimit für jeden Container, festgelegt über das Flag -m oder das Feld memory in docker-compose.yml, kann ein einzelner außer Kontrolle geratener Container den gesamten zuweisbaren RAM des Hosts belegen. Erreicht er diese Grenze ohne verfügbaren Swap, beendet der OOM-Killer des Kernels den Prozess sofort. Das laufzeitspezifische Speicherverhalten verschärft das Problem: Node.js verwendet beispielsweise standardmäßig ein V8-Heap-Limit, das ohne die explizite Begrenzung über –max-old-space-size über dem Speicherlimit deines Containers liegen kann. Schlankere Basis-Images, etwa Alpine statt eines vollständigen Ubuntu- oder Debian-Images, sowie kontinuierliches Monitoring mit docker stats helfen. Die eigentliche Grenze aus eingeschränktem Swap und festen cgroup-Limits ist jedoch durch die Architektur vorgegeben und lässt sich beim Shared Hosting nicht wegkonfigurieren.
Warum ein größerer Shared-Plan nicht immer hilft
Der Wechsel zum größten Shared-Plan erhöht den deinem Account zugewiesenen Ressourcenanteil, ändert aber nichts an der zugrunde liegenden Architektur: Du nutzt weiterhin einen geteilten Kernel, hast keinen Root-Zugriff und erhältst keine dedizierte I/O-Leistung. Liegt der tatsächliche Flaschenhals bei Ressourcenkonflikten durch Noisy Neighbors, einem Limit für Datenbankverbindungen oder einer architektonischen Grenze für gleichzeitige Prozesse, beseitigt ein größerer Shared-Plan keines dieser Limits. In solchen Fällen behebt ein Upgrade die vorgesehene Verlangsamung nicht, weil es an der falschen Ebene des Problems ansetzt.
Warum Shared Hosting bei Traffic-Spitzen ausfällt
Eine Traffic-Spitze erreicht mehrere Shared-Hosting-Limits gleichzeitig, weshalb der Ausfall oft plötzlich statt schrittweise eintritt: Strikte CPU- und Speicherlimits pro Account sind sofort ausgeschöpft, geteilte Datenbankserver erreichen schnell ihre Obergrenze für gleichzeitige Verbindungen und ein festes Limit für parallele PHP- oder Anwendungs-Worker führt dazu, dass zusätzliche Besucher in einer Warteschlange landen und ihre Anfragen ablaufen. Ein CDN sowie Seiten- und Objekt-Caching können einen erheblichen Teil dieser Last abfangen, bevor sie deinen Server erreicht. Das lohnt sich unabhängig vom Hosting-Plan. Bei wirklich unvorhersehbaren oder sehr hohen Lastspitzen beseitigen jedoch nur dedizierte, skalierbare Ressourcen die Grenze, statt sie lediglich anzuheben.
Ressourcenlimits, die auch die Entwicklung blockieren
Dieselben Limits, die in der Produktion Störungen verursachen, treten oft schon während der Entwicklung auf. Testet ein Team eine neue Funktion in einer Staging-Umgebung, die denselben Ressourcenpool wie die Produktion nutzt, erreicht es identische CPU-, Speicher- oder Prozessgrenzen. In diesem Fall bremsen die Limits die Iterationen, statt den Live-Traffic zu beeinträchtigen. Das ist ein eigenständiges Diagnosesignal: Erreicht dein Team die Hosting-Limits bereits beim Testen und nicht nur bei maximalem Produktions-Traffic, ist der Hosting-Plan für das gesamte Projekt zu klein, nicht nur für die stärksten Lastphasen.
Wann du zu einem VPS wechseln solltest
Jedes der genannten Signale ist ein guter Anlass, vom Shared Hosting zu einem VPS zu wechseln: steigende CPU-Steal-Zeit, wiederkehrende OOM-Kills, ein wirkungsloses Upgrade, Abstürze bei Lastspitzen oder Ressourcenlimits in der Entwicklungsumgebung. Bleib in solchen Fällen nicht beim Shared Hosting und hoffe darauf, dass der nächste Plan das Problem behebt. Einen ausführlicheren, kennzahlenbasierten Leitfaden dazu, wann ein VPS seinem eigenen Plan entwachsen ist, findest du in unserem Ratgeber zum Upgrade von VPS auf VDS. Er behandelt Schwellenwerte für die CPU-Steal-Zeit, p95-/p99-Latenz und den richtigen Zeitpunkt für den Wechsel zu einem VDS.
FAQ: Anzeichen für Ausfälle beim Shared Hosting
Was sind die wichtigsten Unterschiede zwischen Shared Hosting und einem VPS für eine produktive Webanwendung?
Beim Shared Hosting nutzen viele Accounts denselben Server und Ressourcenpool ohne feste Isolation; ein VPS verwendet einen Hypervisor und stellt dir tatsächlich dedizierte CPU-, RAM- und Speicherressourcen sowie Root-Zugriff für die eigene Serverkonfiguration bereit. Bei einer produktiven Anwendung verhindert diese Isolation, dass die Traffic-Spitze eines anderen Accounts deine Uptime beeinträchtigt.
Warum werden die Antwortzeiten meines Servers jeden Monat schlechter, obwohl sich der Traffic kaum verändert hat?
Das ist das klassische Noisy-Neighbor-Muster: Ein anderer Mandant auf der geteilten Hardware beansprucht einen wachsenden Anteil an CPU, I/O oder Bandbreite. Prüfe CPU-Steal-Zeit und I/O-Wait in deinen Monitoring-Tools; erhöhte Werte bei beiden sind ein direktes, messbares Zeichen für Ressourcenkonflikte statt für ein Problem mit deiner eigenen Anwendung.
Warum fällt der Betrieb mehrerer Docker-Container auf Shared Hosting immer wieder mit Speicherfehlern aus?
Shared Hosting schränkt Swap normalerweise ein oder deaktiviert ihn und erzwingt feste cgroup-Speicherlimits. Ohne explizite Speicherlimits pro Container kann ein einzelner Container den gesamten verfügbaren RAM belegen und den OOM-Killer des Kernels auslösen. Speicherlimits für Container und schlankere Basis-Images helfen, doch die Grenze durch den eingeschränkten Swap ist architektonisch im Shared Hosting verankert.
Warum lädt meine Website auch nach dem Wechsel zum größten Shared-Hosting-Plan langsam?
Ein größerer Shared-Plan erhöht deine Ressourcenzuweisung, ändert aber nichts an der zugrunde liegenden Architektur: Du nutzt weiterhin einen geteilten Kernel ohne Root-Zugriff oder dedizierte I/O-Leistung. Wenn Ressourcenkonflikte durch Noisy Neighbors oder ein Limit für Datenbankverbindungen den eigentlichen Flaschenhals bilden, behebt ein größerer Shared-Plan keines der beiden Probleme.
Warum stürzt meine Webanwendung bei Traffic-Spitzen auf Shared Hosting ab?
Lastspitzen erreichen mehrere Shared-Hosting-Limits gleichzeitig: CPU- und Speichergrenzen pro Account, Limits für Datenbankverbindungen und Prozessgrenzen. Anfragen landen dadurch in Warteschlangen und laufen ab, statt verarbeitet zu werden. Caching und ein CDN fangen einen Teil der Last ab; bei häufigen oder unvorhersehbaren Spitzen beseitigen dedizierte Ressourcen die Grenze, statt sie nur anzuheben.
Warum erreicht unser Entwicklungsteam beim Testen neuer Funktionen immer wieder die Ressourcenlimits?
Staging-Umgebungen auf Shared Hosting nutzen oft denselben Ressourcenpool wie die Produktion. Deshalb bremsen dieselben CPU-, Speicher- oder Prozessgrenzen, die Produktionsstörungen verursachen, auch Tests und Iterationen. Das zeigt, dass der Hosting-Plan für das gesamte Projekt zu klein ist, nicht nur für den maximalen Traffic.
Hinweis: Die in diesem Artikel genannten Produktspezifikationen, Funktionen und Preise können sich ändern und je nach Region, Abrechnungszeitraum und laufender Aktion abweichen. Aktuelle Angaben und Preise findest du auf der offiziellen Website des jeweiligen Anbieters oder der jeweiligen Marke.
