Ressourcenlimits im Shared Hosting: Was passiert bei vollem CPU, RAM oder IO?

Was sind Ressourcenlimits im Shared Hosting und wozu dienen sie?

Ressourcenlimits im Shared Hosting sind Obergrenzen, die der Anbieter für jedes Konto festlegt: CPU Anteil, Arbeitsspeicher, Festplattendurchsatz, gleichzeitige Prozesse und Dateianzahl. Sie verhindern, dass eine stark belastete Website alle anderen Websites auf demselben Server ausbremst. Erreicht Ihr Konto eine Grenze, lädt die Seite langsamer oder liefert Fehler.

Wir sind Talha Aslan und Team, ein Team für digitales Marketing und Webentwicklung; ein Hostinganbieter sind wir nicht. Deshalb stützen wir jede technische Definition in diesem Leitfaden auf die offizielle Dokumentation von CloudLinux und cPanel. Unser Ziel: Sie sollen die Zahlen in Ihrem Kontrollpanel lesen können und die richtige Frage an die richtige Stelle richten.

Kurz gesagt bringt Ihnen dieser Text drei Dinge. Zunächst verstehen Sie, was jedes Limit tatsächlich misst. Danach erkennen Sie, wie sich Ihre Website verhält, sobald eine Grenze voll ist. Schließlich wissen Sie, welche Schritte Sie selbst erledigen und welche Sie dem Anbieter überlassen sollten.

Wer setzt die Limits auf einem geteilten Server durch?

Im Shared Hosting teilen sich Hunderte Konten dieselbe physische oder virtuelle Maschine. Der Anbieter braucht daher einen Mechanismus, der verhindert, dass ein einzelnes Konto die gesamte CPU oder den ganzen Speicher belegt. Auf vielen cPanel Servern übernimmt das Betriebssystem CloudLinux mit seiner LVE Technik (Lightweight Virtual Environment) diese Aufgabe.

LVE behandelt jedes Konto wie einen kleinen Container mit eigenen Obergrenzen. Zum Beispiel dürfen die PHP Prozesse eines Kontos ihren CPU Anteil nicht überschreiten, und beim Speicher ist an einem festen Punkt Schluss. CageFS trennt Konten dagegen auf Dateisystemebene und ist ein eigenes Thema. Das haben wir in unserem Beitrag über CageFS erklärt; hier wiederholen wir es nicht.

Allerdings nutzt nicht jeder Anbieter CloudLinux. Manche setzen auf ein anderes Panel oder andere Drosselwerkzeuge. Folglich heißen die Ressourcenlimits im Shared Hosting bei Ihnen eventuell anders als in diesem Text. Die Logik bleibt trotzdem gleich: CPU, Speicher, Festplattenzugriff, gleichzeitige Prozesse und Dateianzahl sind überall die zentralen Kennzahlen.

Was misst das CPU Limit (SPEED)?

Das CPU Limit begrenzt die Rechenleistung, die Ihr Konto nutzen darf. CloudLinux führt es unter dem Namen SPEED und gibt es als Prozentsatz eines Kerns an. Das heißt: 100 Prozent entsprechen einem vollen CPU Kern, höhere Werte bedeuten mehr als einen Kern.

Stößt Ihr Konto an diese Grenze, beendet das System Ihre Prozesse nicht. Laut Dokumentation antwortet eine Website, die CloudLinux bei CPU oder IO drosselt, einfach langsamer. Das typische Symptom ist also keine Fehlerseite, sondern eine Seite, die zu lange lädt.

Was verbraucht die meiste CPU? Auf einer WordPress Seite ohne Cache führt jeder Besuch PHP von Grund auf aus und schickt Abfragen an die Datenbank. Ein schwerer Page Builder, viele Plugins oder eine ineffiziente Suchabfrage vervielfachen diese Arbeit. Zudem wächst die Last mit dem Traffic: hundert gleichzeitige Anfragen bedeuten hundert separate PHP Durchläufe.

Deshalb ist Caching der erste Ansatzpunkt, wenn eine Website ständig an ihr CPU Limit stößt. Für die PHP Seite lohnt sich ein Blick in unseren Leitfaden zu OPcache.

Was passiert, wenn Sie das RAM Limit (PMEM) überschreiten?

Das RAM Limit legt also fest, wie viel physischen Arbeitsspeicher die Prozesse Ihres Kontos gleichzeitig belegen dürfen. CloudLinux nennt es PMEM. Laut Dokumentation zählen dazu auch gemeinsam genutzter Speicher und der Festplattencache.

Beim Speicher läuft es allerdings anders als bei der CPU. Erreicht ein Konto sein PMEM Limit, beendet das System einige Prozesse darin und erhöht einen Fehlerzähler. Die CloudLinux Dokumentation ergänzt, dass der Webserver dann meist 500 und 503 Fehler ausliefert. In der Praxis zeigt sich ein Speicherproblem also eher durch sporadische Fehlerseiten als durch allgemeine Langsamkeit.

Vor allem große Dateioperationen fressen Speicher. Zum Beispiel kann ein Plugin, das hochauflösende Bilder auf dem Server skaliert, ein Import Tausender Produktzeilen oder ein Skript, das ein Backup Archiv erstellt, den Speicher schnell füllen. Außerdem sind das PHP Limit memory_limit und das PMEM Limit des Kontos zwei verschiedene Dinge. Das eine begrenzt einen einzelnen PHP Prozess, das andere das gesamte Konto.

Daher rettet ein höheres memory_limit keine Website, die an PMEM scheitert. Laufen viele Prozesse gleichzeitig, kann es das Problem sogar verschärfen.

Wie bremsen IO und IOPS Limits eine Website aus?

Das IO Limit begrenzt, wie viele Daten Ihr Konto pro Sekunde von der Festplatte lesen und darauf schreiben darf. CloudLinux definiert es als Summe aus Lese und Schreibvorgängen. IOPS betrachtet dagegen nicht die Datenmenge, sondern die Anzahl der Lese und Schreiboperationen pro Sekunde.

Ist eine der beiden Grenzen erreicht, ähnelt sich das Ergebnis: Das System lässt Prozesse warten. Laut Dokumentation drosselt CloudLinux Prozesse am IO Limit, legt sie also schlafen. Es stoppt sie nicht, sondern verlangsamt sie. Somit äußert sich auch ein IO Problem zuerst als Langsamkeit.

Diese Aufgaben belasten den Festplattenzugriff am stärksten:

• Backups: Alle Dateien und Datenbanken zu lesen und in ein Archiv zu schreiben, verursacht viel Festplattenarbeit.
• Dateibasierte Cache Bereinigung: Tausende kleine Cache Dateien auf einmal zu löschen oder neu anzulegen, stößt schnell an das IOPS Limit.
• Logdateien: Eine Website mit aktivem Debug Modus schreibt bei jeder Anfrage eine Zeile auf die Festplatte.
• Große Importe: Produkt oder Medienimporte belasten Lesen und Schreiben gleichzeitig.

Websites mit vielen kleinen Dateien erreichen meist zuerst das IOPS Limit, Websites mit großen Dateien dagegen zuerst das IO Limit.

Was sind Entry Processes (EP) und warum erscheint der Fehler 508?

Entry Processes, kurz EP, sind die Prozesse, die gleichzeitig in Ihr Konto eintreten. CloudLinux beschreibt dieses Limit als Zahl gleichzeitiger Verbindungen zu dynamischen Skripten im Apache. Laut Dokumentation zählen auch gleichzeitig laufende SSH Sitzungen und Cronjobs dazu.

Hier ist eine wichtige Unterscheidung nötig. EP ist nicht die Zahl der Personen, die gerade auf Ihrer Seite sind. Ein statisches Bild oder eine CSS Datei startet in der Regel kein PHP. Eine PHP Anfrage, die nach Sekundenbruchteilen fertig ist, belegt kaum einen Platz. Das EP Limit füllt sich vielmehr dann, wenn sich langsame Anfragen stapeln.

Was passiert dann? Laut Dokumentation kann der Webserver die neue Anfrage nicht in die LVE des Kontos einordnen und liefert den Statuscode 508. Besucher sehen dann typischerweise eine Seite mit dem Titel "Resource Limit Is Reached". Die Standardtabelle in der CloudLinux Dokumentation nennt für EP den Wert 20; jeder Anbieter legt jedoch eigene Werte pro Tarif fest.

Ein Beispiel: Braucht eine Seite normalerweise eine halbe Sekunde, füllt sich das EP Limit selten. Dauert dieselbe Seite wegen einer langsamen externen Schnittstelle oder einer blockierten Abfrage zehn Sekunden, reichen schon wenige Besucher. Ein 508 Fehler deutet daher meist auf langsamen Code hin, nicht auf hohen Traffic.

Was begrenzt das NPROC Limit?

NPROC ist dagegen die Gesamtzahl der Prozesse, die gleichzeitig in Ihrem Konto existieren dürfen. EP zählt nur die Prozesse, die in das Konto eintreten. NPROC zählt dagegen alles, auch die Kindprozesse, die diese starten.

Stellen Sie es sich so vor: Eine PHP Anfrage ist ein Entry Process. Startet diese Anfrage allerdings im Hintergrund einen Befehl zur Bildbearbeitung oder einen Mailversand, steigt NPROC. Ebenso kann ein Backup Skript, das per Cron startet, mehrere Kindprozesse öffnen.

Laut CloudLinux kann Apache 500 oder 503 Fehler zurückgeben, wenn NPROC voll ist. Das Symptom ähnelt also dem Speicherproblem: Fehlerseiten. Prüfen Sie deshalb bei gelegentlichen 500 und 503 Fehlern nicht nur den Speicher, sondern auch die Prozesszahl. Allgemeine Ursachen und eine Reihenfolge zur Behebung finden Sie in unserem Leitfaden zu 503 Service Unavailable.

Andererseits entstehen NPROC Probleme meist durch eine einzige fehlerhafte Einrichtung. Überlappende Cronjobs, hängende Hintergrundskripte und nie geschlossene SSH Sitzungen sind die klassischen Beispiele.

Was passiert, wenn das Inode Limit erreicht ist?

Konkret ist ein Inode der Eintrag, den der Server für jede Datei und jeden Ordner anlegt. Die cPanel Dokumentation beschreibt die Zeile File Usage im Statistikbereich als Zahl der Dateien und Verzeichnisse, also Inodes, die Ihr Konto belegt. Das heißt: Das Inode Limit begrenzt die Anzahl der Dateien, nicht ihre Größe.

Ihr Inode Kontingent kann also auch dann voll sein, wenn noch Speicherplatz frei ist. Zum Beispiel treiben Sitzungsordner, die bei jedem Besuch eine Datei anlegen, nie geleerte Cache Verzeichnisse, Tausende Vorschaubilder, volle Postfächer und alte Backup Ordner die Zahl schnell nach oben.

CloudLinux unterscheidet bei Inodes zwischen weichem und hartem Limit. Das weiche Limit dürfen Sie eine Zeit lang überschreiten; es wirkt als Warnung. Ist das harte Limit erreicht, kann das Konto dagegen keine neuen Daten mehr schreiben. Dann bricht ein Plugin Update womöglich mittendrin ab, ein hochgeladenes Bild verschwindet, das Postfach nimmt keine Nachrichten mehr an und Cache Dateien entstehen nicht.

Kurz gesagt erzeugt ein Inode Problem plötzliche und seltsame Fehler: Die Seite lädt, aber Formulare gehen nicht raus und Updates schließen nie ab.

Wie funktionieren Limits für Speicherplatz und Bandbreite?

Zunächst zum Speicherplatz: Er ist die Gesamtgröße Ihrer Dateien, Datenbanken und Mails. Der Statistikbereich in cPanel zeigt ihn in der Zeile Disk Usage und die Datenbanknutzung in einer eigenen Zeile. Ist der Platz voll, ähnelt die Wirkung dem Inode Limit: Neue Dateien landen nicht, Backups scheitern und Datenbanktabellen können nicht wachsen.

Bandbreite oder Traffic ist die Datenmenge, die Ihre Website ausliefert. Die cPanel Dokumentation beschreibt die Zeile Bandwidth als die im laufenden Monat übertragene Datenmenge. Bei manchen Tarifen sperrt der Anbieter die Website, sobald das Monatskontingent aufgebraucht ist; bei anderen erhalten Sie nur eine Warnung. Dieses Verhalten hängt allein von der Richtlinie Ihres Anbieters ab.

Wie Traffic Kontingente funktionieren und wie Sie Ihren Bedarf abschätzen, erklären wir in unserem Beitrag über Bandbreite beim Webhosting. Ein Punkt verdient hier besondere Betonung: Unkomprimierte große Bilder und selbst gehostete Videos verbrauchen Traffic schneller als alles andere.

Zudem blähen alte Backups im Konto Speicherplatz und Inode Zahl gleichzeitig auf. Verschieben Sie sie nach außen, entlastet das beide Grenzen auf einmal.

Warum sind MySQL Verbindungs und Abfragelimits wichtig?

Auch die Datenbank hat eigene Grenzen, und Websitebetreiber übersehen sie oft. MySQL erlaubt es, Ressourcenlimits pro Konto festzulegen. Die offizielle MySQL Dokumentation erklärt, dass getrennte Grenzen für Abfragen pro Stunde, Änderungen pro Stunde, Verbindungen pro Stunde und gleichzeitige Verbindungen möglich sind.

Im Shared Hosting begegnet Ihnen am häufigsten die Grenze für gleichzeitige Verbindungen. Ist sie voll, erreicht Ihre Website die Datenbank nicht mehr, und Systeme wie WordPress melden einen Fehler beim Aufbau der Datenbankverbindung. Im Fehlerprotokoll steht dann meist eine Zeile, die max_user_connections erwähnt.

Auf manchen CloudLinux Servern läuft außerdem eine Komponente namens MySQL Governor, die die Datenbanknutzung pro Benutzer überwacht. Ob Ihr Anbieter sie aktiviert und mit welchen Schwellen, hängt vom Anbieter ab. Im Panel sehen Sie das nicht immer.

Konkret belasten drei Dinge die Datenbankgrenzen am meisten: persistente Verbindungen, die nie schließen, Plugins mit Dutzenden Abfragen pro Seite und Suchen in großen Tabellen ohne Index. Beginnen Sie bei einem Datenbankfehler also mit langsamen Abfragen und Plugins, die Verbindungen öffnen.

Welches Symptom passt zu welchem Limit?

Die folgende Tabelle fasst zusammen, wie sich die Ressourcenlimits im Shared Hosting typischerweise zeigen, wenn eines voll ist, und wo Sie zuerst nachsehen sollten. Die Symptome stammen aus der Dokumentation von CloudLinux und cPanel; die Einrichtung Ihres Anbieters kann Details verändern.

Als Faustregel gilt: Langsamkeit deutet meist auf CPU oder IO hin, Fehlerseiten dagegen auf Speicher, Prozesse oder EP.

Wie prüfen Sie die Ressourcennutzung in cPanel?

cPanel liefert Ressourcendaten an zwei Stellen. Die erste ist der Statistikbereich auf der Startseite. Laut cPanel Dokumentation zeigt er unter anderem Speicherplatz, Dateinutzung (Inodes), monatliche Bandbreite und Speicherbedarf der Datenbanken. Dieselbe Dokumentation weist darauf hin, dass die Zeilen CPU Usage, Memory Usage und Entry Processes nur auf Servern mit CloudLinux erscheinen.

Die zweite Stelle geht dann tiefer. Laut CloudLinux Dokumentation öffnen Endnutzer das Plugin Resource Usage über die Kachel "CPU and concurrent connection usage" im Bereich Metrics von cPanel. Nutzt Ihr Panel eine andere Sprache oder ein anderes Design, sieht die Beschriftung womöglich etwas anders aus.

Die Ansicht hat drei Reiter:

1. Dashboard: Zeigt, ob das System Ihre Website zuletzt gedrosselt hat und welche Ressource an der Grenze war.
2. Current usage: Stellt die Nutzung in Diagrammen und Tabellen dar, mit Nutzung, Limit und Fehlerzahl nebeneinander.
3. Snapshot: Enthält Momentaufnahmen der Prozessliste, der Datenbankabfragen und der HTTP Anfragen.

Falls cPanel neu für Sie ist, beginnen Sie am besten mit unserem cPanel Leitfaden für Einsteiger.

Wie lesen Sie den Fault Zähler und den Snapshot Reiter?

Vor allem eine Spalte zählt: Die wertvollste Spalte in der Tabelle Current usage ist die Fehlerzahl, also Fault. Sie zeigt, wie oft eine Ressource an ihre Grenze gestoßen ist. Ist die Nutzung hoch, Fault aber null, war Ihre Website nah dran, ohne gedrosselt zu sein. Steigt Fault weiter, haben Ihre Besucher in diesen Momenten Langsamkeit oder Fehler erlebt.

Die Diagramme lassen sich auf Tage, Stunden oder Minuten eingrenzen. So erkennen Sie, ob das Problem jeden Tag zur selben Zeit auftritt oder zufällig. Ein IO Diagramm, das jede Nacht zur gleichen Stunde ausschlägt, weist meist auf ein Backup oder einen Cronjob hin.

Der Reiter Snapshot beantwortet eine einfache Frage: Was lief in diesem Moment? In der Prozessliste sehen Sie, welches Skript die meiste CPU oder den meisten Speicher belegt hat. Im HTTP Bereich stehen die aufgerufenen Adressen, und der Datenbankbereich listet die ausgeführten Abfragen.

Zeigt ein Snapshot zum Beispiel Hunderte Anfragen an dieselbe Such URL, ist Bot Traffic die wahrscheinliche Ursache. Läuft dagegen ein einzelnes Admin Skript sehr lange, steckt vermutlich ein Plugin oder eine geplante Aufgabe dahinter.

Wo beginnen Sie, wenn eine Website ständig an Grenzen stößt?

Eine feste Reihenfolge spart Zeit. Prüfen Sie zunächst im Dashboard, welche Ressource das System begrenzt hat. Suchen Sie dann im Diagramm dieser Ressource das zeitliche Muster. Gleichen Sie es danach mit den Snapshots aus demselben Moment ab.

Nach unserer Praxiserfahrung sind das die häufigsten Gründe, warum ein Shared Hosting Konto an seine Grenzen stößt:

• Plugins: Statistik, Sicherheitsscan oder Plugins für ähnliche Beiträge, die auf jeder Seite schwere Abfragen ausführen.
• Bot Traffic: Crawler außerhalb der Suchmaschinen, Preisvergleichsbots und Brute Force Anmeldeversuche.
• Cronjobs: Geplante Aufgaben, die zu oft laufen oder sich überschneiden.
• Backup Zeitpunkt: Vollständige Backups, die mitten in der Hauptverkehrszeit laufen.
• Große Backups: Archive, die sich im Konto stapeln und Speicherplatz sowie Inodes verbrauchen.

Beobachten Sie nach jeder Änderung die Werte einige Tage lang. Denn ein ruhiger Tag ohne Fault beweist noch nicht, dass die Lösung wirkt. Allgemeine serverseitige Gründe für Langsamkeit behandelt unser Beitrag warum Ihre Website langsam ist.

Wie verbraucht Bot Traffic die Ressourcenlimits im Shared Hosting?

Weil Bots nie pausieren, rufen sie Seiten viel schneller und in viel größerer Zahl auf als Menschen. Auf einer Website ohne Cache bedeutet jede Bot Anfrage einen vollständigen PHP Durchlauf. Folglich kann schon eine gewöhnliche Crawler Welle die EP und CPU Grenzen in Minuten füllen.

Trotzdem ist es ein Fehler, jeden Bot zu blockieren. Wer Suchmaschinen Crawler wie den Googlebot aussperrt, schadet seiner Sichtbarkeit. Prüfen Sie daher zuerst, ob eine Anfrage wirklich vom angegebenen Bot stammt; die Methode erklären wir in unserem Beitrag zur Verifizierung des Googlebot.

Laut offizieller Google Dokumentation verlangsamen die Google Crawler das Crawling vorübergehend, wenn ein Server 5xx Fehler oder den Status 429 liefert. Anders gesagt verliert eine Website, die ständig an ihre Grenzen stößt, nicht nur Besucher, sondern womöglich auch Crawling Tempo.

Gut erzogene Bots steuern Sie mit robots.txt, und unser robots.txt Generator erleichtert die Erstellung. Bösartige Bots ignorieren robots.txt allerdings. Dafür wirken die Firewall Ihres Anbieters oder eine vorgeschaltete CDN Schicht besser.

Warum verursachen Cronjobs und Backup Zeiten plötzliche Spitzen?

Geplante Aufgaben sind der häufigste Grund für Spitzen, die sich in Ihren Diagrammen regelmäßig wiederholen. Der eingebaute Planer von WordPress ist kein echter Server Cron; er läuft, sobald Besucher Seiten aufrufen. Auf einer gut besuchten Website kann das bedeuten, dass er viel öfter läuft als nötig.

Die WordPress Dokumentation empfiehlt, den eingebauten Planer mit dieser Zeile in wp-config.php abzuschalten und stattdessen einen echten Cronjob einzurichten:

define( 'DISABLE_WP_CRON', true );

Danach legen Sie im cPanel Bereich Cron Jobs eine Aufgabe an, die wp-cron.php in festen Abständen ausführt. Den PHP Pfad entnehmen Sie der Dokumentation Ihres Anbieters. Eine Schritt für Schritt Anleitung finden Sie in unserem Leitfaden zum Cronjob.

Backups verbrauchen zudem auf einen Schlag mehr IO und Speicher als jede andere Aufgabe. Legen Sie Ihr Backup Plugin deshalb auf die Stunde mit dem geringsten Traffic und starten Sie zur selben Zeit keine anderen schweren Aufgaben. Schicken Sie Backups außerdem auf einen externen Speicher, statt sie im Konto zu sammeln; unser Beitrag zur Backup Strategie für Websites zeigt einen soliden Aufbau.

Die richtige Reihenfolge: vom Caching bis zum Tarifwechsel

Stößt eine Website ständig an Grenzen, ist der erste Reflex oft ein Upgrade. Ohne die Ursache zu beheben, verschiebt ein Upgrade dasselbe Problem allerdings nur in einen teureren Tarif. Wir empfehlen diese Reihenfolge:

1. Caching: Seitencache und PHP Opcode Cache ersparen dem Server Arbeit, die er sonst bei jedem Besuch wiederholt. Der größte Gewinn kommt meist von hier.
2. Bots blockieren: Stoppen Sie Crawler, die Sie nicht verifizieren können oder nicht brauchen, und lassen Sie Suchmaschinen Bots in Ruhe.
3. Code und Plugins: Entfernen Sie ungenutzte Plugins, ersetzen Sie schwere durch leichtere und beheben Sie langsame Abfragen.
4. Zeitplanung: Legen Sie Cronjobs und Backups außerhalb der Hauptverkehrszeit.
5. Tarifwechsel: Tauchen nach diesen Schritten weiterhin regelmäßig Faults auf, ist Ihre Website tatsächlich gewachsen.

Wenn Sie sich für ein Upgrade entscheiden, begleitet Sie unser Leitfaden zum Hosting Upgrade ohne Ausfall durch den Wechsel. Reicht Shared Hosting nicht mehr aus, klärt unser Vergleich von VPS, VDS und Cloud Server den nächsten Schritt.

Haben "unbegrenzte" Hosting Tarife wirklich keine Limits?

Nein. Anbieter beziehen das Wort unbegrenzt meist auf einen einzelnen Posten wie Speicherplatz oder Traffic. CPU, Speicher, gleichzeitige Prozesse und Inodes bleiben auf einem geteilten Server physisch endlich. Deshalb gelten CPU, RAM und EP Grenzen auch bei "unbegrenzten" Tarifen weiter.

Zudem nehmen viele Anbieter eine Fair Use Klausel in die Bedingungen ihrer unbegrenzten Tarife auf. Theoretisch gibt es also keine Grenze; belastet Ihr Konto den Server jedoch spürbar, kann der Anbieter Sie kontaktieren oder das Konto einschränken.

Dieses Thema behandeln wir ausführlicher in einem eigenen Beitrag. Hier nur ein Tipp: Achten Sie beim Tarifvergleich nicht auf das Wort "unbegrenzt", sondern auf die Werte für CPU, RAM, EP, IO und Inodes. Stehen sie nicht auf der Tarifseite, fordern Sie sie vor dem Kauf schriftlich an. Allgemeine Auswahlkriterien finden Sie in unserem Beitrag, wie Sie das passende Webhosting auswählen.

Welche Fragen sollten Sie Ihrem Hostinganbieter stellen?

Die richtigen Fragen beschleunigen jedes Gespräch mit dem Anbieter, egal ob Sie einen Tarif wählen oder Ressourcenlimits im Shared Hosting untersuchen. Diese Liste nutzen wir:

• Welche Werte gelten in meinem Tarif genau für CPU, RAM, IO, IOPS, EP und NPROC?
• Gibt es ein Inode Limit, und wie lauten weiche und harte Grenze?
• Gilt eine Grenze für gleichzeitige MySQL Verbindungen oder für Abfragen pro Stunde?
• Sperren Sie die Website, wenn das monatliche Traffic Kontingent aufgebraucht ist, oder senden Sie nur eine Warnung?
• Ist die Ansicht Resource Usage in meinem Konto aktiv, und wie weit reicht ihr Verlauf zurück?
• Bei welchen Limits gab es in der letzten Woche Faults in meinem Konto, und zu welchen Uhrzeiten?
• Gibt es serverseitigen Schutz gegen Bots und Brute Force Angriffe?
• Gibt es beim Wechsel in einen höheren Tarif einen Ausfall oder eine neue IP Adresse?

Werden Sie auch bei Problemmeldungen konkret. Statt "Die Seite ist langsam" schreiben Sie etwa: "Jede Nacht zur selben Stunde steigen die IO Faults, und im Snapshot läuft das Backup Skript." Dann kann der Support direkt an der richtigen Stelle ansetzen.

Wann sollten Sie das Problem dem Anbieter überlassen?

Im Shared Hosting endet Ihr Einfluss an der Grenze Ihres Kontos. Plugins, Cache Einstellungen, Cron Zeiten, robots.txt und das Aufräumen von Dateien sind Ihre Aufgabe. Alles, was den Server selbst betrifft, liegt dagegen beim Anbieter.

In diesen Fällen eröffnen Sie besser ein Support Ticket, statt selbst zu experimentieren:

• Ihre Website ist langsam, zeigt aber keine Faults: Das Problem betrifft vermutlich den ganzen Server.
• Im Snapshot tauchen Prozesse auf, die Sie nicht kennen: Das kann ein Sicherheitsproblem sein.
• Sie vermuten, dass sich Ihre Limitwerte geändert haben: Nur der Anbieter kann das bestätigen.
• Sie erleben einen Brute Force oder Denial of Service Angriff: Die Abwehr auf Netzwerkebene ist Aufgabe des Anbieters.

Umgekehrt ist es ebenso unrealistisch, vom Anbieter die Lösung von Problemen auf Website Ebene zu erwarten. Ein Hostingunternehmen optimiert in der Regel weder Ihre Plugins noch Ihr Theme. Für solche Arbeiten sind Ihr Entwickler oder unser Team für Webdesign und Entwicklung die bessere Wahl.

Kurze Checkliste: Ressourcenlimits im Shared Hosting im Griff behalten

Zusammengefasst läuft dieser Leitfaden auf einige wiederkehrende Gewohnheiten hinaus. Öffnen Sie einmal im Monat die Ansicht Resource Usage und prüfen Sie die Spalte Fault. Notieren Sie dann im Statistikbereich, wie voll Speicherplatz und Inode Kontingent sind.

Beobachten Sie außerdem nach jedem neuen Plugin einige Tage lang die Diagramme. Stellen Sie sicher, dass Backup und Cron Zeiten nicht in die Hauptverkehrszeit fallen. Verschieben Sie alte Backups und ungenutzte Dateien aus dem Konto.

Halten Sie schließlich die Werte Ihres Tarifs schriftlich fest. So können Sie bei einem Problem mit dem Anbieter vergleichen, was sich geändert hat. Ressourcenlimits im Shared Hosting sollen alle Nutzer eines Servers schützen, nicht Sie bestrafen; sobald Sie sie lesen können, verwandeln sich die meisten Verlangsamungen und Fehlerseiten in vorhersehbare Probleme.

Quellen: CloudLinux Dokumentation zu Limits, CloudLinux Plugin Resource Usage, cPanel Dokumentation zur Oberfläche, MySQL Ressourcenlimits für Konten, Google Search Central: HTTP und Netzwerkfehler.