Ihre Website ist träge geworden, oder Besucher sehen den Fehler 503 Resource Limit Reached. Der erste Impuls ist, dem Server die Schuld zu geben oder zu einem größeren Tarif zu greifen. Im Shared Hosting liegt die Ursache jedoch meist in Ihrer Anwendung, und Sie können sie mit den Werkzeugen, die bereits in cPanel vorhanden sind, in wenigen Minuten selbst finden.
Das Wichtigste
- Jedes Shared- und Reseller-Konto bei WebGee läuft in einer eigenen CloudLinux-LVE mit festen Limits für CPU, I/O, Entry Processes und Arbeitsspeicher.
- CPU- und I/O-Limits machen eine Website langsam, während Limits für Entry Processes und Arbeitsspeicher zu 503-Fehlern „Resource Limit Reached“ führen.
- Entry Processes zählen die Anfragen, die im selben Moment verarbeitet werden. Eine langsame Seite erreicht das Limit daher mit deutlich weniger Besuchern als eine schnelle.
- Resource Usage in cPanel und die zugehörigen Snapshots zeigen, welches Limit erreicht wurde und welche Prozesse dafür verantwortlich waren. PHP X-Ray zeigt, wofür die Zeit innerhalb einer Anfrage verbraucht wird.
- Caching, eine Überprüfung der Plugins und korrigierte Cronjobs kommen vor einem Upgrade, denn ein Upgrade hebt nur die Obergrenze an, ohne zu beheben, was die Ressourcen verbraucht.
Bevor Sie beginnen
- Melden Sie sich bei cPanel für das betroffene Konto an.
- Notieren Sie ungefähr, wann die Verlangsamung oder die 503-Fehler aufgetreten sind.
- Halten Sie Ihre aktuelle IP-Adresse bereit, damit PHP X-Ray nur Ihre eigenen Aufrufe aufzeichnet.
- Falls Sie Bolt-Cache verwenden, stellen Sie die Website während der Analyse auf den Proxy-Modus um.
Ihr Konto läuft in einem eigenen Container
Jedes Shared- und Reseller-Konto bei WebGee läuft in einer eigenen Lightweight Virtual Environment (LVE), einem CloudLinux-Container mit festen Ressourcenlimits. Wenn in einem Konto ein Skript außer Kontrolle gerät oder es angegriffen wird, wird dieses Konto gedrosselt oder seine Prozesse werden beendet, während alle anderen Konten ungestört weiterlaufen. Die Limits sorgen dafür, dass das Problem eines anderen nie zu Ihrem wird.
Sofern Ihr Tarif nichts anderes vorsieht, hat jedes Konto:
- CPU: 1 Kern
- Arbeitsspeicher: 1 GB
- Entry Processes: 30 gleichzeitig
Eine ausführliche Erklärung finden Sie unter CloudLinux- und LVE-Limits erklärt.
Ordnen Sie das Symptom dem Limit zu
Jedes Limit verhält sich beim Erreichen anders, und genau das zeigt Ihnen, wo Sie suchen müssen:
- CPU: Die Website wird langsamer, Anfragen werden aber weiterhin abgeschlossen.
- I/O: Die Website wird langsamer, besonders bei allem, was viel auf die Festplatte zugreift.
- Entry Processes (EP): ein 503-Fehler, weil Anfragen sofort beendet werden.
- Physischer Arbeitsspeicher (PMEM): ein 503-Fehler, oder der Prozess wird beendet.
CPU- und I/O-Limits verschlechtern Ihre Website, Limits für Entry Processes und Arbeitsspeicher legen sie lahm. Eine träge Website stößt also an ein anderes Limit als eine, die 503-Fehler ausgibt.
Warum langsamen Websites die Entry Processes ausgehen
Ein Entry Process ist eine Anfrage, die gerade in Ihrem Konto verarbeitet wird. Das Limit gibt an, wie viele davon im selben Moment laufen dürfen – nicht pro Stunde und nicht pro Besucher. Eine PHP-Anfrage ist in der Regel in Sekundenbruchteilen erledigt, und ihr Platz wird sofort wieder frei.
Der Haken: Je länger jede Anfrage dauert, desto weniger Besucher braucht es, um das Limit zu erreichen. Eine Seite, die 5 Sekunden benötigt, belegt ihren Platz 25-mal länger als eine, die 200 ms braucht. Sobald sich Anfragen stauen, werden die Seiten noch langsamer und belegen ihre Plätze noch länger. Dieser Teufelskreis ist der Grund, warum Websites meist plötzlich statt allmählich ausfallen.
Anfragen über dem Limit werden vom Kernel mit SIGKILL beendet, und der Besucher sieht den 503-Fehler. Typische Auslöser sind lang laufende Vorgänge:
- Ein Cronjob, der Minuten dauert und jede Minute ausgeführt wird
- WP-Cron, das bei Seitenaufrufen ausgelöst wird
- Ein Plugin, das bei jeder Anfrage einen langsamen externen API-Aufruf ausführt
- Eine Datenbankabfrage ohne Index
Weitere Details finden Sie unter Was Entry Processes sind.
Eine Ressourcenwarnung ist keine Sperrung Wenn WebGee Ihnen per E-Mail mitteilt, dass Ihr Konto seine Ressourcenlimits erreicht hat, wurde nichts gesperrt. Die Warnung soll sicherstellen, dass Sie von einem Performance-Problem durch uns erfahren und nicht durch einen Kunden. Gelegentliche Warnungen haben keine Folgen; anhaltende Fälle, die die Serverstabilität beeinträchtigen, werden individuell nachverfolgt.
Finden Sie heraus, welches Limit Sie erreicht haben
Beginnen Sie unter cPanel → Resource Usage. Dort sehen Sie, welches Limit wann erreicht wurde und was zu diesem Zeitpunkt lief.
- Öffnen Sie in cPanel Resource Usage.
- Wählen Sie den Zeitraum, in dem die Verlangsamung, die 503-Fehler oder die Warn-E-Mail aufgetreten sind.
- Prüfen Sie, welches Limit erreicht wurde: CPU, I/O, Entry Processes oder Arbeitsspeicher.
- Öffnen Sie den Snapshot für diesen Zeitpunkt. Er listet die verantwortlichen Prozesse auf.
Erst der Snapshot macht aus einem Symptom eine Ursache. Wenn sich die Überschreitungen zu einer bestimmten Uhrzeit häufen, prüfen Sie als Nächstes cPanel → Cron Jobs, denn ein aufwendiger Job mit kurzem Intervall ist ein häufiger Verursacher.
Die vollständige Anleitung finden Sie unter Sie haben eine Warnung zur Ressourcennutzung erhalten und Den Fehler 503 Resource Limit Reached beheben.
Langsame Anfragen mit PHP X-Ray analysieren
Resource Usage zeigt Ihnen, welches Limit betroffen ist; PHP X-Ray zeigt Ihnen, wofür die Zeit innerhalb einer Anfrage verbraucht wird. Es zeichnet echte Anfragen auf und schlüsselt jede einzelne auf, sodass Sie nicht länger raten müssen, ob das Problem ein Plugin, eine Datenbankabfrage oder ein externer Aufruf ist. X-Ray ist im Shared, Reseller und Premium Hosting verfügbar.
- Öffnen Sie in cPanel X-Ray.
- Wählen Sie die Domain oder Subdomain, die analysiert werden soll.
- Geben Sie Ihre eigene IP-Adresse ein, legen Sie die Anzahl der zu sammelnden Anfragen auf 10–20 fest und wählen Sie einen Zeitraum, der lang genug ist, um die Verlangsamung nachzustellen.
- Starten Sie die Aufzeichnung und rufen Sie die langsame Seite dann einige Male in Ihrem Browser auf.
- Öffnen Sie die gesammelte Aufzeichnung, sobald sich die Spalte Collected Requests füllt.
Achten Sie auf Folgendes, ungefähr sortiert danach, wie häufig es die Ursache ist:
- Eine langsame Datenbankabfrage, die viele Male wiederholt wird, meist ein Plugin, das innerhalb einer Schleife abfragt. Object Caching behebt das oft vollständig.
- Ein langsamer externer HTTP-Aufruf, etwa ein Plugin, das einen Lizenzserver oder eine API kontaktiert. Die Seite kann erst fertig geladen werden, wenn die Antwort eintrifft.
- Ein Plugin, das den Großteil der Gesamtzeit beansprucht. Deaktivieren Sie es und analysieren Sie erneut, um den Verdacht zu bestätigen.
Eine Schritt-für-Schritt-Anleitung mit Screenshots finden Sie unter Herausfinden, was Ihre Website verlangsamt.
X-Ray benötigt den Proxy-Modus X-Ray sammelt nur dann Daten, wenn Bolt-Cache deaktiviert ist und Ihre Websites den Proxy-Modus verwenden. Bei aktiviertem Bolt-Cache bleibt die Aufzeichnung leer – der häufigste Grund, warum X-Ray für defekt gehalten wird. Wird die Seite aus dem Cache ausgeliefert, hängen Sie beim Testen ?xray=1 an die URL an.
Verwechseln Sie PHP memory_limit nicht mit Ihrem Kontolimit
memory_limit begrenzt, wie viel Arbeitsspeicher ein einzelnes PHP-Skript belegen darf. Sie ändern den Wert unter cPanel → Select PHP Version → Options (siehe PHP-Version und Einstellungen ändern). Eine Erhöhung ist sinnvoll bei großen Importen, Bildverarbeitung großer Uploads, einem WooCommerce-Shop mit umfangreichem Katalog oder einer Anwendung, die ausdrücklich einen höheren Wert verlangt.
Damit erhöhen Sie jedoch nicht das Arbeitsspeicherlimit Ihres Kontos. Dieses wird durch Ihren Tarif festgelegt und ist die Ursache der 503-Fehler. Ein memory_limit oberhalb der Zuteilung Ihres Kontos bringt nichts, da das Skript beim Erreichen des Kontolimits ohnehin beendet wird.
Ein normaler WordPress-Seitenaufruf kommt problemlos mit 128–256 MB aus. Wenn Ihre Startseite 1 GB benötigt, lädt etwas weit mehr als nötig: ein Plugin, das ohne Begrenzung abfragt, eine unbegrenzte Schleife oder Bildverarbeitung bei jeder Anfrage statt einmalig beim Upload. Analysieren Sie das mit X-Ray, bevor Sie irgendeinen Wert erhöhen.
Um den tatsächlich angewendeten Wert zu prüfen, erstellen Sie eine PHP-Datei mit dem Inhalt <?php echo ini_get('memory_limit');, rufen Sie sie auf und löschen Sie sie anschließend wieder. Bei Bolt-Cache wird der PHP Selector ignoriert, und der Wert stammt aus .user.ini. Mehr dazu unter PHP-Speicherlimits verstehen.
Die Auslastung wieder senken
Beheben Sie zuerst das Problem in der Anwendung. Diese Schritte lösen in dieser Reihenfolge die meisten Fälle:
- Caching aktivieren. Eine gecachte Seite erreicht PHP nie und wird daher nie zu einem Entry Process. Beginnen Sie mit LiteSpeed Cache und ergänzen Sie dann Redis Object Caching für angemeldete Besucher und den Adminbereich.
- Plugins überprüfen. Deaktivieren Sie alle, warten Sie ein paar Minuten und aktivieren Sie sie dann einzeln wieder, während Sie Resource Usage beobachten.
- Cronjobs korrigieren. WP-Cron läuft bei Seitenaufrufen, was unter Last genau das falsche Verhalten ist. Ersetzen Sie WP-Cron durch einen echten Cronjob und verlängern Sie das Intervall aller anderen aufwendigen Jobs.
- Auf ungewöhnlichen Traffic prüfen. Bots und Scraper verbrauchen dieselben Ressourcen wie Ihre Kunden.
- Nach Malware suchen. Eine kompromittierte Website verbraucht Ressourcen für die Zwecke anderer. Scannen Sie Ihre Website auf Malware.
Probleme erkennen, bevor Ihre Besucher es tun
Site Quality Monitoring in cPanel prüft eine Domain stündlich auf Erreichbarkeit und führt wöchentlich einen vollständigen Zustands- und Performance-Scan durch, der nach defekten Links, fehlenden Metadaten, langsamen Seiten und gemischten Inhalten sucht. Die Funktion ist deaktiviert, bis Sie ein Projekt anlegen:
- Wählen Sie in cPanel Site Quality Monitoring.
- Wählen Sie die Monitored domain und geben Sie eine Email Address für Benachrichtigungen ein.
- Setzen Sie das Häkchen für die Einwilligung und wählen Sie Create Project.
Verwenden Sie eine Adresse, die nicht auf dem überwachten Konto gehostet wird, sonst erreicht Sie eine Ausfallwarnung womöglich nie. Das Monitoring sieht, was ein Besucher sieht, und kann Ihnen daher nicht sagen, warum eine Seite langsam ist. Meldet es zeitweise Ausfälle, prüfen Sie Resource Usage, denn die Ursache sind oft Ressourcenlimits und kein tatsächlicher Ausfall.
Details zur Einrichtung finden Sie unter Site Quality Monitoring.
Wann ein Upgrade die richtige Lösung ist
Führen Sie ein Upgrade erst nach der Diagnose durch. Ein Upgrade hebt die Obergrenze an, ohne zu beheben, was die Ressourcen verbraucht – ein außer Kontrolle geratenes Plugin verbraucht dann einfach noch mehr. Zeigt der Snapshot in Resource Usage legitimen Traffic, der legitime Arbeit verursacht, können die Limits erhöht werden; genau dafür sind die Elastic-Cloud-Tarife gedacht. Eröffnen Sie ein Ticket mit Ihren Werten aus Resource Usage, und WebGee berät Sie gern.
Häufige Fragen
Bedeutet der Fehler „503 Resource Limit Reached“, dass der Server ausgefallen ist?
Nein. Er bedeutet, dass Ihr eigenes Konto eines seiner Ressourcenlimits erreicht hat und Anfragen abgewiesen wurden, bis die Auslastung wieder gesunken ist. Andere Konten auf dem Server sind davon nicht betroffen.
Ist das Entry-Process-Limit dasselbe wie ein Besucherlimit?
Nein. Es begrenzt, wie viele Anfragen im selben Moment verarbeitet werden, und jede schnelle Anfrage belegt ihren Platz nur kurz. Eine Website, die Seiten in 200 ms ausliefert, kann weit mehr als 30 gleichzeitige Besucher bedienen, ohne einem Limit von 30 Entry Processes auch nur nahe zu kommen.
Verhindert ein höheres memory_limit unter Select PHP Version die 503-Fehler?
Nein. memory_limit begrenzt ein einzelnes PHP-Skript, während 503-Fehler durch das Arbeitsspeicherlimit Ihres Kontos entstehen, das durch Ihren Tarif festgelegt ist. Ein Skript wird beim Erreichen des Kontolimits beendet, unabhängig von memory_limit.
Warum sammelt PHP X-Ray keine Anfragen?
X-Ray sammelt nur dann Daten, wenn Bolt-Cache deaktiviert ist und Ihre Websites den Proxy-Modus verwenden. Prüfen Sie außerdem, ob Sie Ihre aktuelle IP-Adresse eingetragen haben, und hängen Sie beim Testen einen Query-String wie ?xray=1 an, um den Seitencache zu umgehen.
