Resource Limit Is Reached: CloudLinux-Limits erkennen und beheben

Wenn deine Website zeitweise die Meldung Resource Limit Is Reached zeigt, hat dein Hosting-Account ein von CloudLinux verwaltetes Ressourcenlimit erreicht.

Die Meldung bedeutet nicht automatisch, dass der gesamte Hosting-Server überlastet ist. CURIAWEB verwendet CloudLinux, um Hosting-Accounts voneinander zu isolieren und ihnen definierte Ressourcen zur Verfügung zu stellen. Wird eine dieser Grenzen erreicht, kann CloudLinux die weitere Ressourcennutzung des betreffenden Accounts begrenzen.

In dieser Anleitung zeigen wir dir, wie du herausfindest, welches Ressourcenlimit erreicht wurde, wann das passiert ist und welche Anwendung oder Aufgabe dafür verantwortlich sein könnte.

Wichtig: Versuche nicht, die Fehlermeldung durch zufällige Änderungen an PHP, WordPress oder cPanel zu beheben. Öffne zuerst die CloudLinux-Ressourcennutzung und stelle fest, welches Limit tatsächlich erreicht wurde.

Was bedeutet „Resource Limit Is Reached“? #

CloudLinux verwaltet verschiedene Ressourcen eines Hosting-Accounts. Dazu gehören je nach Serverkonfiguration unter anderem:

• CPU-Leistung
• physischer Arbeitsspeicher
• Ein-/Ausgabe-Leistung
• gleichzeitige Entry Processes
• Gesamtzahl laufender Prozesse

Wird eine entsprechende Grenze erreicht, kann die weitere Verarbeitung begrenzt werden.

Je nachdem, welche Ressource betroffen ist und welche Anfrage gerade verarbeitet wird, kann sich das unterschiedlich bemerkbar machen.

Mögliche Symptome sind beispielsweise:

• Website reagiert ungewöhnlich langsam
• einzelne Seiten laden nicht
• Backend reagiert zeitweise nicht
• PHP-Prozesse benötigen ungewöhnlich lange
• Anfragen schlagen unter Last fehl
• 508 Resource Limit Is Reached wird angezeigt

Ein 508-Fehler ist nicht automatisch eine Serverüberlastung #

Eine wichtige technische Unterscheidung lautet:

Hosting-Account erreicht CloudLinux-Limit
≠
gesamter Hosting-Server ist überlastet

CloudLinux verwendet sogenannte LVE-Ressourcenbegrenzungen, um einzelne Hosting-Accounts voneinander abzugrenzen.

Wenn dein Account ein Limit erreicht, betrifft das deshalb zunächst die deinem Account zugewiesenen Ressourcen.

Kurz erklärt: Die Fehlermeldung sagt zunächst: „Dieser Hosting-Account benötigt gerade mehr von einer bestimmten Ressource, als innerhalb seines aktuellen Limits verfügbar ist.“ Sie sagt noch nicht, warum das passiert.

1. Datum und Uhrzeit des Fehlers notieren #

Wenn die Meldung nur sporadisch erscheint, ist der genaue Zeitpunkt für die Diagnose besonders wichtig.

Notiere möglichst:

Datum
Uhrzeit
betroffene Domain
betroffene URL
ausgeführte Aktion
sichtbare Fehlermeldung

Beispiel:

28.08.2026
14:37 Uhr
example.ch
/wp-admin/
508 Resource Limit Is Reached

Mit diesem Zeitpunkt kannst du anschließend die CloudLinux-Ressourcen untersuchen.

2. CloudLinux-Ressourcennutzung öffnen #

Melde dich bei deinem CURIAWEB-cPanel an und öffne:

Messwerte → Ressourcennutzung

Die CloudLinux-Oberfläche zeigt dir die Ressourcennutzung deines Hosting-Accounts und kann darauf hinweisen, ob Ressourcenlimits erreicht wurden.

Eine ausführliche Erklärung der einzelnen Messwerte findest du unter CloudLinux Ressourcennutzung in cPanel verstehen.

3. Passenden Zeitraum auswählen #

Wähle einen Zeitraum, der den Zeitpunkt des Problems enthält.

Wenn der Fehler beispielsweise um 14:37 Uhr aufgetreten ist, interessiert dich insbesondere die Ressourcennutzung rund um diesen Zeitpunkt.

Eine Limitüberschreitung von gestern Abend erklärt normalerweise keinen Fehler von heute Nachmittag.

4. Prüfen, welches Limit erreicht wurde #

Jetzt kommt der wichtigste Schritt: Stelle fest, welche Ressource tatsächlich ihr Limit erreicht hat.

Je nach CloudLinux-Konfiguration können beispielsweise folgende Werte relevant sein:

Ressource	Bedeutung
CPU	verfügbare Rechenleistung
Physical Memory	Arbeitsspeicher der Account-Prozesse
I/O	Datenrate bei Ein-/Ausgabeoperationen
IOPS	Anzahl der Ein-/Ausgabeoperationen
Entry Processes	gleichzeitig eintretende beziehungsweise verarbeitete Prozesse
Number of Processes	Gesamtzahl laufender Prozesse des Accounts

Welche Maßnahme sinnvoll ist, hängt wesentlich davon ab, welches dieser Limits betroffen ist.

5. Faults beziehungsweise Limit-Ereignisse prüfen #

Achte in der CloudLinux-Auswertung besonders auf sogenannte Faults beziehungsweise dokumentierte Limit-Ereignisse.

Ein hoher Wert allein bedeutet nicht automatisch, dass das Limit überschritten beziehungsweise erreicht wurde.

Für die Diagnose ist deshalb wichtig:

Welches Limit?
        ↓
Wann erreicht?
        ↓
Wie häufig?
        ↓
Was lief zu diesem Zeitpunkt?

Praxis-Tipp: Ein Fault zum exakt gleichen Zeitpunkt wie dein Website-Problem ist wesentlich aussagekräftiger als eine beliebige hohe Auslastung mehrere Stunden vorher.

CPU-Limit erreicht #

Wenn das CPU-Limit erreicht wird, benötigt dein Hosting-Account zu diesem Zeitpunkt die ihm verfügbare Rechenleistung vollständig.

CloudLinux kann die weitere CPU-Nutzung entsprechend begrenzen. Prozesse benötigen dadurch möglicherweise länger.

Typische Ursachen können sein:

• viele dynamische Website-Aufrufe
• aufwendige PHP-Prozesse
• ineffiziente Plugins
• umfangreiche Datenbankoperationen
• Importe oder Exporte
• Cronjobs
• Backup- oder Wartungsprozesse
• Bots oder ungewöhnlich viele Zugriffe

CPU-Limit nur kurz erreicht #

Eine einzelne kurze CPU-Spitze muss nicht zwangsläufig ein Problem darstellen.

Wenn du beispielsweise gerade einen großen Import ausführst, kann die CPU-Auslastung vorübergehend deutlich steigen.

Interessanter wird es, wenn:

• das CPU-Limit regelmäßig erreicht wird
• die Website gleichzeitig langsam wird
• die Situation ohne manuell gestartete Aufgabe auftritt
• das Verhalten reproduzierbar ist

CPU-Limit regelmäßig zur selben Uhrzeit #

Wenn die CPU beispielsweise jeden Tag ungefähr zur selben Uhrzeit ihr Limit erreicht, prüfe geplante Aufgaben.

Typische Kandidaten sind:

• Cronjobs
• Importe
• Exporte
• Synchronisationen
• Wartungsaufgaben
• Anwendungs-Backups

Wie du fehlerhafte oder ressourcenintensive Cronjobs untersuchst, erklären wir unter Cronjob funktioniert nicht: Ursachen und Lösungen.

Mehrere Cronjobs gleichzeitig starten #

Wenn mehrere ressourcenintensive Aufgaben zur gleichen Zeit starten, kann sich deren Ressourcenbedarf addieren.

Beispiel:

02:00 → Produktimport
02:00 → Datensynchronisation
02:00 → Export
02:00 → Wartungsprozess

Wenn die Anwendungen dies erlauben, kann es sinnvoll sein, solche Aufgaben zeitlich zu verteilen.

Ändere jedoch keine von einer Anwendung vorgegebenen Cronjobs, ohne deren Funktion zu kennen.

Physical-Memory-Limit erreicht #

Wenn das CloudLinux-Limit für Physical Memory erreicht wird, verwenden die laufenden Prozesse des Accounts zu viel Arbeitsspeicher innerhalb der verfügbaren Ressourcengrenze.

Typische Ursachen können beispielsweise sein:

• viele gleichzeitig laufende PHP-Prozesse
• speicherintensive Importe
• Bildverarbeitung
• umfangreiche Anwendungen
• mehrere parallele Hintergrundprozesse
• fehlerhafter oder ineffizienter Anwendungscode

Physical Memory ist nicht das PHP Memory Limit #

Diese beiden Werte werden häufig verwechselt.

Das PHP-memory_limit und das CloudLinux-Limit für Physical Memory arbeiten auf unterschiedlichen Ebenen.

Vereinfacht:

PHP memory_limit
→ maximaler Speicherrahmen eines PHP-Prozesses

CloudLinux Physical Memory
→ Speicherverbrauch der Account-Prozesse innerhalb des LVE

Wenn das CloudLinux-Speicherlimit erreicht wird, solltest du deshalb nicht einfach das PHP Memory Limit erhöhen.

Wie PHP-Limits funktionieren, erklären wir unter PHP Memory Limit, Upload-Größe und Ausführungszeit einstellen.

Achtung: Ein höheres PHP Memory Limit stellt deinem Hosting-Account nicht automatisch mehr CloudLinux-Arbeitsspeicher zur Verfügung.

„Allowed memory size exhausted“ ist ein anderer Fehler #

Wenn im Error Log eine Meldung wie:

Allowed memory size of ... bytes exhausted

erscheint, wurde das PHP Memory Limit eines PHP-Prozesses erreicht.

Das ist technisch von einem CloudLinux-Physical-Memory-Limit zu unterscheiden.

Prüfe deshalb die konkrete Fehlermeldung, bevor du Einstellungen änderst.

Entry-Process-Limit erreicht #

Entry Processes beziehungsweise EP beschreiben vereinfacht gleichzeitig in die CloudLinux-LVE-Umgebung eintretende beziehungsweise dort verarbeitete Prozesse.

Das EP-Limit kann besonders bei vielen gleichzeitig zu verarbeitenden dynamischen Anfragen relevant werden.

Wird diese Grenze erreicht, können zusätzliche Anfragen nicht normal verarbeitet werden.

In diesem Zusammenhang kann insbesondere ein:

508 Resource Limit Is Reached

auftreten.

Entry Processes sind nicht deine Besucherzahl #

Ein EP-Limit von beispielsweise einem bestimmten Wert bedeutet nicht, dass nur entsprechend viele Personen deine Website gleichzeitig besuchen dürfen.

Besucher und Entry Processes sind unterschiedliche Messgrößen.

Entscheidend ist unter anderem, wie lange dynamische Anfragen verarbeitet werden.

Vereinfacht:

schnelle Anfrage
→ Prozess ist schnell abgeschlossen
→ Ressource wird wieder frei

langsame Anfrage
→ Prozess bleibt länger aktiv
→ mehr gleichzeitige Prozesse können entstehen

Deshalb kann eine langsame Anwendung das EP-Limit auch bei vergleichsweise moderatem Traffic stärker beanspruchen.

Was kann viele Entry Processes verursachen? #

Mögliche Ursachen sind beispielsweise:

• viele gleichzeitige dynamische Anfragen
• langsame PHP-Verarbeitung
• langsame Datenbankoperationen
• ungecachte dynamische Seiten
• Bots oder automatisierte Zugriffe
• lang laufende Anwendungsvorgänge

Bei WordPress oder WooCommerce ist deshalb nicht nur die Zahl der Besucher relevant, sondern auch, wie effizient die einzelnen Anfragen verarbeitet werden.

Number-of-Processes-Limit erreicht #

CloudLinux kann zusätzlich die Gesamtzahl der Prozesse eines Hosting-Accounts begrenzen.

Dieser Wert wird häufig als NPROC beziehungsweise Number of Processes bezeichnet.

Im Gegensatz zu Entry Processes betrachtet NPROC nicht nur gleichzeitig eintretende Webprozesse.

Auch andere laufende Prozesse des Accounts können relevant sein.

Viele Prozesse untersuchen #

Wenn das Prozesslimit regelmäßig erreicht wird, prüfe insbesondere:

• parallel laufende Cronjobs
• lang laufende PHP-Prozesse
• Hintergrundaufgaben
• Import- und Exportprozesse
• mehrere Anwendungen innerhalb desselben Hosting-Accounts

Auch eine alte Testinstallation kann Hintergrundaufgaben ausführen, obwohl sie nicht mehr aktiv genutzt wird.

I/O-Limit erreicht #

Das I/O-Limit betrifft die Geschwindigkeit, mit der Prozesse Daten lesen beziehungsweise schreiben können.

Wird die verfügbare I/O-Leistung vollständig beansprucht, können davon abhängige Prozesse langsamer werden.

Typische Auslöser können sein:

• große Dateioperationen
• Backups
• Entpacken großer Archive
• umfangreiche Importe
• viele Schreibvorgänge
• Cache-Erzeugung

I/O-Limit und voller Speicherplatz unterscheiden #

Ein I/O-Limit bedeutet nicht, dass dein Hosting-Speicher voll ist.

I/O-Limit
→ Geschwindigkeit der Dateioperationen begrenzt

Speicherplatz voll
→ kein beziehungsweise zu wenig Platz für weitere Daten

Den tatsächlichen Speicherverbrauch kontrollierst du unter Speicherplatz und Bandbreite in cPanel überprüfen.

IOPS-Limit erreicht #

Wenn in deiner CloudLinux-Auswertung zusätzlich IOPS angezeigt werden, beschreibt dieser Wert die Anzahl der Ein-/Ausgabeoperationen pro Sekunde.

Viele kleine Dateioperationen können deshalb ein IOPS-Limit beanspruchen, auch wenn die insgesamt übertragene Datenmenge nicht außergewöhnlich groß erscheint.

Welche Ressource wurde erreicht? #

Die folgende Übersicht hilft bei der ersten Einordnung:

Limit	Typische erste Prüfpunkte
CPU	PHP, Plugins, Cronjobs, Importe, Traffic
Physical Memory	speicherintensive und parallele Prozesse
Entry Processes	gleichzeitige beziehungsweise langsame dynamische Anfragen
Number of Processes	Hintergrundprozesse, Cronjobs, parallele Aufgaben
I/O	Backups, Dateioperationen, Archive, Importe
IOPS	sehr viele einzelne Dateioperationen

6. Prüfen, was zum Zeitpunkt des Fehlers lief #

Nachdem du das betroffene Limit identifiziert hast, solltest du herausfinden, welche Aktivität zum gleichen Zeitpunkt stattfand.

Prüfe beispielsweise:

• wurde ein Import ausgeführt?
• lief ein Cronjob?
• wurde ein Backup erstellt?
• gab es ungewöhnlich viele Besucher?
• waren Bots aktiv?
• wurde gerade WordPress aktualisiert?
• lief eine Synchronisation?
• wurde ein großes Archiv verarbeitet?

Erst diese Verbindung zwischen Limit + Zeitpunkt + Aktivität führt zu einer belastbaren Diagnose.

7. cPanel Error Log zum selben Zeitpunkt prüfen #

Wenn die Website gleichzeitig PHP- oder Serverfehler zeigt, öffne zusätzlich:

Messwerte → Fehler

Prüfe dort, ob zum gleichen Zeitpunkt eine passende Fehlermeldung protokolliert wurde.

Wie du diese Einträge liest, erklären wir unter cPanel Error Log lesen und Website-Fehler finden.

CloudLinux-Limit und PHP-Fehler können zusammen auftreten #

Ein Ressourcenproblem und ein Anwendungsfehler schließen sich nicht gegenseitig aus.

Beispielsweise kann ein fehlerhafter Prozess:

ungewöhnlich lange laufen
        ↓
viel CPU oder Speicher verwenden
        ↓
CloudLinux-Limit erreichen

In diesem Fall ist das Ressourcenlimit eine Folge des eigentlichen Anwendungsproblems.

WordPress als Ursache untersuchen #

Bei WordPress können Plugins, Themes und Hintergrundaufgaben erheblichen Einfluss auf den Ressourcenverbrauch haben.

Wenn das Problem unmittelbar nach einer Änderung begonnen hat, prüfe insbesondere:

• neu installiertes Plugin
• Plugin-Update
• Theme-Update
• WordPress-Update
• neue Importfunktion
• Backup-Plugin
• Security- oder Statistik-Plugin
• individuellen Code

Wie du Plugin- und Theme-Konflikte systematisch untersuchst, erklären wir unter WordPress Plugin- und Theme-Konflikte erkennen und beheben.

WP-Cron und Hintergrundaufgaben berücksichtigen #

WordPress verwendet eigene geplante Ereignisse für verschiedene Hintergrundaufgaben.

Plugins können darüber beispielsweise:

• E-Mails verarbeiten
• Daten synchronisieren
• Feeds abrufen
• Berichte erstellen
• Daten bereinigen
• Updates oder andere Wartungsaufgaben ausführen

Eine ressourcenintensive Hintergrundaufgabe kann deshalb auch dann auftreten, wenn du gerade selbst nichts im WordPress-Backend ausführst.

WooCommerce besonders berücksichtigen #

WooCommerce verarbeitet zahlreiche dynamische Vorgänge und Hintergrundaufgaben.

Dazu können beispielsweise gehören:

• Warenkorb
• Checkout
• Kundenkonto
• Bestellungen
• Produktimporte
• Synchronisationen
• geplante Aktionen von Erweiterungen

Bei einem Onlineshop solltest du deshalb genau prüfen, welche Aufgabe zum Zeitpunkt des Ressourcenereignisses ausgeführt wurde.

WordPress Action Scheduler berücksichtigen #

WooCommerce und zahlreiche WordPress-Erweiterungen verwenden den Action Scheduler für Hintergrundaufgaben.

Wenn sich sehr viele ausstehende oder fehlschlagende Aufgaben angesammelt haben, kann dies zu wiederkehrender Hintergrundaktivität beitragen.

Wenn dein Ressourcenproblem regelmäßig auftritt, kann deshalb auch die Warteschlange geplanter Aufgaben innerhalb der betreffenden Anwendung relevant sein.

Bots und Crawler als Ursache prüfen #

Automatisierte Zugriffe können erheblichen Ressourcenverbrauch verursachen, insbesondere wenn viele dynamische URLs aufgerufen werden.

Ein Bot muss dabei nicht zwangsläufig ein bösartiger Angreifer sein.

Auch:

• Suchmaschinen
• SEO-Crawler
• Monitoring-Dienste
• Preis- oder Content-Crawler
• automatisierte Scanner

können zahlreiche Anfragen erzeugen.

Zugriffsstatistiken mit dem Ressourcenereignis vergleichen #

Wenn ein Limit mit ungewöhnlich hohem Traffic zusammenfällt, kannst du zusätzlich die cPanel-Werkzeuge unter Messwerte verwenden.

Dort stehen je nach Auswertung unter anderem Besucher-, Bandbreiten-, Rohzugriffs- und Statistikdaten zur Verfügung.

Dadurch kannst du besser beurteilen, ob eine Lastspitze mit erhöhtem Datenverkehr zusammenfällt.

Traffic ist nicht automatisch die Ursache #

Ein Ressourcenlimit während hohen Traffics bedeutet nicht zwangsläufig, dass ausschließlich die Besucherzahl das Problem ist.

Wenn einzelne dynamische Seiten sehr langsam verarbeitet werden, kann bereits moderater Traffic zu vielen gleichzeitig laufenden Prozessen führen.

Deshalb sollte immer auch die Effizienz der Anwendung untersucht werden.

Caching prüfen #

Bei dynamischen Websites kann geeignetes Caching die Anzahl der PHP- und Datenbankoperationen für wiederkehrende Seitenaufrufe erheblich reduzieren.

CURIAWEB stellt mit AccelerateWP eine WordPress-orientierte Optimierungslösung bereit.

Weitere Informationen findest du unter AccelerateWP in cPanel erklärt.

Nicht mehrere Cache-Systeme übereinander installieren #

Wenn ein Ressourcenlimit erreicht wird, besteht eine häufige Fehlreaktion darin, mehrere Performance-Plugins gleichzeitig zu installieren.

Das kann:

• Konflikte verursachen
• Cache-Inhalte widersprüchlich verwalten
• Fehlersuche erschweren
• dynamische Funktionen beeinträchtigen

Verwende deshalb eine kontrollierte Optimierung und prüfe nach jeder Änderung das Ergebnis.

Cache hilft nicht bei jeder Ursache #

Caching kann besonders bei wiederholten Frontend-Aufrufen helfen.

Es löst aber beispielsweise nicht automatisch:

• fehlerhafte Cronjobs
• ressourcenintensive Importe
• Backend-Prozesse
• bestimmte WooCommerce-Aufgaben
• fehlerhaften Anwendungscode
• ungewöhnlich große Datenbankoperationen

Die Ursache muss deshalb weiterhin identifiziert werden.

PHP-Version prüfen #

Eine geeignete und von der Anwendung unterstützte PHP-Version kann für Performance und Stabilität relevant sein.

Bei CURIAWEB verwaltest du die PHP-Version deiner Domain grundsätzlich über den MultiPHP-Manager.

Wechsle die PHP-Version jedoch nicht blind aufgrund eines Ressourcenfehlers.

Prüfe zuerst, welche Version deine Website, Plugins und Themes unterstützen.

PHP-Erweiterungen prüfen #

Wenn gleichzeitig Fehlermeldungen über fehlende PHP-Funktionen oder Klassen auftreten, kann zusätzlich eine benötigte PHP-Erweiterung relevant sein.

Die Vorgehensweise erklären wir unter PHP-Erweiterungen in cPanel aktivieren und verwalten.

PHP-Limits nicht mit CloudLinux-Limits verwechseln #

PHP-Einstellungen wie:

memory_limit
max_execution_time
upload_max_filesize
post_max_size

sind keine CloudLinux-Limits.

Wenn CloudLinux beispielsweise ein CPU- oder Entry-Process-Limit meldet, wird dieses Problem nicht dadurch gelöst, dass du upload_max_filesize oder memory_limit erhöhst.

Speicherplatz kontrollieren #

Ein voller Hosting-Speicher ist ebenfalls kein CloudLinux-CPU-Limit.

Wenn gleichzeitig Schreib-, Update- oder E-Mail-Probleme auftreten, solltest du zusätzlich den verfügbaren Speicherplatz kontrollieren.

Die Vorgehensweise findest du unter Speicherplatz und Bandbreite in cPanel überprüfen.

Mehrere Websites im Account berücksichtigen #

Wenn mehrere Websites innerhalb desselben Hosting-Accounts betrieben werden, teilen sie die Ressourcen dieses Accounts.

Das bedeutet:

Website A
Website B
Website C
Cronjobs
Hintergrundprozesse
        ↓
gemeinsame Account-Ressourcen

Das Ressourcenproblem muss deshalb nicht zwangsläufig von der Domain verursacht werden, auf der du die Fehlermeldung zuerst gesehen hast.

Alte Testinstallationen nicht vergessen #

Eine alte WordPress-Testseite kann weiterhin von Bots aufgerufen werden und Hintergrundaufgaben ausführen.

Auch nicht mehr aktiv verwendete Installationen können deshalb Ressourcen beanspruchen.

Prüfe bei wiederkehrenden Problemen, welche Anwendungen tatsächlich noch im Hosting-Account vorhanden sind.

Staging-Websites können ebenfalls Prozesse ausführen #

Eine Staging-Kopie ist technisch eine weitere Website.

Wenn dort WordPress, Plugins, Cronjobs oder andere Hintergrundprozesse aktiv sind, können diese ebenfalls Ressourcen verwenden.

Berücksichtige deshalb auch Test- und Staging-Umgebungen.

Backup-Plugins kritisch prüfen #

WordPress-Backup-Plugins können je nach Konfiguration große Datenmengen:

• lesen
• komprimieren
• schreiben
• übertragen

Dadurch können CPU, I/O, Speicher und Prozesslaufzeiten beeinflusst werden.

Wenn Ressourcenprobleme regelmäßig während eines Plugin-Backups auftreten, solltest du dessen Zeitplan und Konfiguration überprüfen.

Große Archive können mehrere Ressourcen gleichzeitig beanspruchen #

Das Erstellen oder Entpacken eines großen ZIP-Archivs kann beispielsweise gleichzeitig:

• CPU
• I/O
• IOPS
• Arbeitsspeicher

beanspruchen.

Betrachte deshalb nicht nur einen einzelnen Messwert, wenn mehrere Ressourcen zum gleichen Zeitpunkt auffällig sind.

Importe kontrolliert durchführen #

Wenn ein großer Import regelmäßig Ressourcenlimits erreicht, prüfe, ob die verwendete Anwendung kleinere Verarbeitungspakete oder eine andere Batch-Größe unterstützt.

Bei einem Produktimport kann es beispielsweise effizienter sein, kontrollierte Teilmengen zu verarbeiten, statt eine extrem große Datenmenge in einem einzigen Vorgang zu erzwingen.

Welche Einstellung sinnvoll ist, hängt von der jeweiligen Anwendung ab.

Datenbankprobleme berücksichtigen #

Langsame oder sehr aufwendige Datenbankoperationen können dazu führen, dass PHP-Prozesse länger aktiv bleiben.

Dadurch können sich unter Last weitere Prozesse ansammeln.

Ein Ressourcenlimit kann deshalb auch ein Symptom einer ineffizienten Anwendung oder Datenbankabfrage sein.

Fehlerhafte Prozesse statt höherem Limit #

Wenn ein einzelner fehlerhafter Prozess unnötig Ressourcen verbraucht, wäre eine reine Erhöhung des Limits keine nachhaltige Lösung.

Beispiel:

Plugin erzeugt Endlosschleife
        ↓
CPU dauerhaft hoch
        ↓
CPU-Limit erreicht

Die eigentliche Lösung besteht dann darin, den fehlerhaften Prozess zu korrigieren – nicht lediglich darin, ihm mehr CPU zur Verfügung zu stellen.

Wann mehr Ressourcen tatsächlich sinnvoll sein können #

Nicht jedes Ressourcenlimit ist auf einen Fehler zurückzuführen.

Eine technisch saubere und gut optimierte Website kann aufgrund ihres tatsächlichen Nutzungsumfangs mehr Ressourcen benötigen.

Das kann beispielsweise bei:

• stark gewachsenem Traffic
• umfangreichen Onlineshops
• vielen gleichzeitigen dynamischen Zugriffen
• ressourcenintensiven Webanwendungen
• regelmäßig großen Verarbeitungsaufgaben

der Fall sein.

Bevor du zu diesem Schluss kommst, sollte jedoch geprüft werden, ob die vorhandenen Ressourcen effizient genutzt werden.

Wichtig: „Mehr Ressourcen“ und „Website optimieren“ sind keine Gegensätze. Eine wachsende Anwendung kann beides benötigen: effiziente Software und eine zum tatsächlichen Bedarf passende Hosting-Ausstattung.

Wann Optimierung sinnvoller ist #

Eine Optimierung sollte insbesondere dann im Vordergrund stehen, wenn:

• ein einzelnes Plugin extrem viel Last verursacht
• Fehler oder Endlosschleifen auftreten
• unnötige Cronjobs parallel laufen
• Bot-Traffic ungewöhnlich hoch ist
• Caching fehlt oder falsch konfiguriert ist
• alte Installationen unnötig Prozesse ausführen
• eine Datenbankoperation ineffizient arbeitet

Wann zusätzliche Ressourcen geprüft werden sollten #

Zusätzliche Ressourcen können dagegen sinnvoll sein, wenn:

• die Website technisch sauber funktioniert
• keine offensichtlichen Fehlerprozesse vorhanden sind
• die Anwendung bereits sinnvoll optimiert ist
• die Limits aufgrund legitimer Nutzung regelmäßig erreicht werden
• der tatsächliche Ressourcenbedarf dauerhaft gestiegen ist

Die Entscheidung sollte anhand der gemessenen Ressourcen und der tatsächlichen Anwendung getroffen werden – nicht allein anhand einer einzelnen Fehlermeldung.

Problem nur einmal aufgetreten #

Wenn ein Ressourcenlimit einmalig während einer außergewöhnlichen Aufgabe erreicht wurde und danach nicht wieder auftritt, besteht nicht automatisch dauerhafter Handlungsbedarf.

Beispiele:

• einmaliger großer Import
• Migration
• Erstellung eines großen Archivs
• außergewöhnliche Traffic-Spitze

Dokumentiere das Ereignis und beobachte, ob es erneut auftritt.

Problem tritt täglich auf #

Wenn dasselbe Limit täglich ungefähr zur gleichen Zeit erreicht wird, spricht dies häufig für einen wiederkehrenden Prozess.

Prüfe:

Cronjobs
WordPress-Hintergrundaufgaben
WooCommerce Scheduled Actions
Backups
Synchronisationen
Importe
Exporte

Der wiederkehrende Zeitpunkt ist dabei ein besonders wertvoller Hinweis.

Problem tritt nur bei vielen Besuchern auf #

Wenn Ressourcenlimits ausschließlich bei erhöhtem Traffic auftreten, solltest du untersuchen:

• welches Limit erreicht wird
• welche URLs besonders häufig aufgerufen werden
• ob diese Seiten dynamisch verarbeitet werden
• ob Caching sinnvoll eingesetzt wird
• ob Bots einen Teil der Last verursachen
• wie schnell einzelne Anfragen verarbeitet werden

Nur die Besucherzahl zu betrachten reicht für eine technische Diagnose nicht aus.

Problem tritt nur im WordPress-Backend auf #

Das WordPress-Backend enthält viele Bereiche, die nicht wie öffentliche Seiten vollständig zwischengespeichert werden können.

Wenn Ressourcenprobleme nur bei bestimmten Administrationsaufgaben auftreten, solltest du genau diese Aktion untersuchen.

Beispiele:

• Produktimport
• Berichterstellung
• Massenbearbeitung
• Plugin-Scan
• Datenbankbereinigung

Problem tritt nur beim Checkout auf #

Bei WooCommerce ist der Checkout ein dynamischer Vorgang.

Wenn Ressourcenprobleme ausschließlich dort auftreten, sollte nicht einfach die gesamte Website gecacht werden.

Untersuche stattdessen die am Checkout beteiligten Plugins, Zahlungsdienste, Datenbankoperationen und externen Verbindungen.

Problem nach Plugin-Update #

Wenn die Ressourcennutzung unmittelbar nach einem Plugin-Update deutlich ansteigt, ist der zeitliche Zusammenhang ein wichtiger Hinweis.

Prüfe:

• Changelog und Systemanforderungen
• PHP-Kompatibilität
• neue Hintergrundfunktionen
• Fehlermeldungen
• Konflikte mit anderen Erweiterungen

Ändere nicht gleichzeitig mehrere andere Komponenten, da dies die Diagnose erschwert.

Problem nach PHP-Wechsel #

Wenn das Problem unmittelbar nach einer Änderung der PHP-Version auftritt, kontrolliere:

• Kompatibilität der Anwendung
• Plugins und Themes
• benötigte PHP-Erweiterungen
• Error Log
• Ressourcenwerte vor und nach dem Wechsel

Ein kontrollierter Wechsel auf die zuvor funktionierende PHP-Version kann ein sinnvoller Diagnoseschritt sein, sofern diese Version weiterhin unterstützt und für die Anwendung geeignet ist.

Problem nach Migration #

Wenn eine migrierte Website auf dem neuen Hosting ungewöhnlich viele Ressourcen benötigt, prüfe unter anderem:

• PHP-Version
• PHP-Erweiterungen
• Cronjobs
• Cache-Konfiguration
• alte absolute Pfade
• Anwendungsfehler
• mehrfach vorhandene Testinstallationen

Eine Migration kann Unterschiede in der Server- oder Anwendungskonfiguration sichtbar machen, die vorher nicht aufgefallen sind.

Nicht alle Maßnahmen gleichzeitig durchführen #

Wenn du gleichzeitig:

PHP wechselst
Plugins deaktivierst
Cache neu konfigurierst
Cronjobs änderst
Datenbank optimierst

und das Problem anschließend verschwindet, weißt du nicht, welche Änderung tatsächlich geholfen hat.

Gehe deshalb kontrolliert vor:

eine Hypothese
        ↓
eine gezielte Änderung
        ↓
erneut testen
        ↓
Ressourcen vergleichen

Ressourcennutzung nach einer Änderung kontrollieren #

Nach einer Optimierung solltest du nicht nur prüfen, ob die Fehlermeldung verschwunden ist.

Kontrolliere auch, ob sich die zugrunde liegenden Ressourcenwerte verbessert haben.

Beispiel:

Vorher:
EP-Limit täglich mehrfach erreicht

Änderung:
langsamen Hintergrundprozess korrigiert

Nachher:
keine EP-Faults im vergleichbaren Zeitraum

Damit erhältst du einen wesentlich besseren Nachweis, dass die Maßnahme tatsächlich wirksam war.

Resource Limit Is Reached systematisch diagnostizieren #

1. Notiere Datum, Uhrzeit und betroffene URL.
2. Öffne Messwerte → Ressourcennutzung.
3. Wähle den passenden Zeitraum.
4. Prüfe, welches Limit erreicht wurde.
5. Kontrolliere Faults beziehungsweise Limit-Ereignisse.
6. Vergleiche deren Zeitpunkt mit dem Website-Problem.
7. Prüfe, welche Prozesse oder Aufgaben zu diesem Zeitpunkt liefen.
8. Kontrolliere Cronjobs und Hintergrundaufgaben.
9. Prüfe bei WordPress Plugins, Themes und geplante Aktionen.
10. Kontrolliere bei Website-Fehlern zusätzlich das Error Log.
11. Prüfe ungewöhnlichen Traffic beziehungsweise Bots.
12. Ändere nur eine mögliche Ursache gleichzeitig.
13. Teste anschließend erneut.
14. Vergleiche die CloudLinux-Werte vor und nach der Änderung.

Was du nicht tun solltest #

Vermeide insbesondere:

• PHP Memory Limit ohne Diagnose extrem erhöhen
• mehrere Cache-Plugins gleichzeitig installieren
• PHP-Versionen wahllos wechseln
• Cronjobs ohne Kenntnis ihrer Funktion löschen
• Plugins und Themes gleichzeitig massenweise deaktivieren
• große Dateien auf Verdacht löschen
• jeden einmaligen Peak als dauerhaftes Hosting-Problem interpretieren

Grundregel: Ein Ressourcenfehler wird nicht zuverlässig behoben, indem du möglichst viele Einstellungen änderst. Du musst zuerst herausfinden, welches Limit erreicht wird und welcher Prozess zu diesem Zeitpunkt Ressourcen benötigt.

Website zeigt keinen 508-Fehler, ist aber langsam #

Ein Hosting-Account kann Ressourcenlimits erreichen, ohne dass jeder Besucher zwingend eine sichtbare 508-Seite erhält.

CPU- oder I/O-Begrenzungen können sich beispielsweise zunächst durch langsamere Verarbeitung bemerkbar machen.

Wenn eine Website sporadisch langsam ist, solltest du deshalb auch ohne sichtbaren 508-Fehler die CloudLinux-Ressourcennutzung zum betreffenden Zeitpunkt prüfen.

Keine CloudLinux-Limits erreicht #

Wenn CloudLinux im relevanten Zeitraum keine passenden Limit-Ereignisse zeigt, solltest du die Fehlersuche auf andere Ebenen erweitern.

Mögliche Ursachen sind beispielsweise:

• PHP-Fehler
• Datenbankprobleme
• externe Dienste
• DNS
• SSL
• Plugin- oder Theme-Fehler
• Browser- beziehungsweise Frontend-Probleme

Versuche nicht, ein Ressourcenproblem zu beheben, wenn die Messwerte dafür keine Hinweise liefern.

Wann solltest du den CURIAWEB-Support kontaktieren? #

Wenn dein Hosting-Account regelmäßig CloudLinux-Limits erreicht und du die verursachende Anwendung oder Aufgabe nicht eindeutig identifizieren kannst, dokumentiere das Problem möglichst genau.

Hilfreich sind insbesondere:

• betroffene Domain
• betroffene URL oder Funktion
• Datum und genaue Uhrzeit
• sichtbare Fehlermeldung
• betroffenes CloudLinux-Limit
• angezeigte Faults beziehungsweise Limit-Ereignisse
• Häufigkeit des Problems
• kürzlich vorgenommene Änderungen
• laufende Cronjobs, Importe oder Hintergrundaufgaben
• relevante Error-Log-Einträge

Mit diesen Angaben lässt sich wesentlich schneller beurteilen, ob ein fehlerhafter Prozess, eine Optimierungsmöglichkeit oder ein dauerhaft höherer Ressourcenbedarf vorliegt.

Zusammenfassung #

Die Meldung Resource Limit Is Reached bedeutet, dass dein Hosting-Account ein von CloudLinux verwaltetes Ressourcenlimit erreicht hat. Sie bedeutet nicht automatisch, dass der gesamte Hosting-Server überlastet ist.

Öffne zuerst Messwerte → Ressourcennutzung und prüfe den Zeitraum, in dem das Problem aufgetreten ist. Entscheidend ist anschließend, welches Limit tatsächlich erreicht wurde.

CPU, Physical Memory, Entry Processes, Number of Processes, I/O und IOPS beschreiben unterschiedliche Ressourcen. Entsprechend unterscheiden sich auch die möglichen Ursachen.

Ein CPU-Limit kann beispielsweise durch aufwendige PHP-Prozesse, Cronjobs oder hohe dynamische Last entstehen. Ein EP-Limit deutet dagegen auf zu viele gleichzeitig verarbeitete eingehende Prozesse hin. Physical Memory wiederum darf nicht mit dem PHP-memory_limit verwechselt werden.

Vergleiche Limit-Ereignisse immer mit dem genauen Zeitpunkt des Website-Problems. Prüfe anschließend Cronjobs, WordPress-Hintergrundaufgaben, Plugins, Importe, Backups, Traffic und Error Logs.

Ein Ressourcenlimit ist außerdem nicht automatisch ein Beweis dafür, dass dein Hosting-Paket grundsätzlich zu klein ist. Fehlerhafter Code, ungünstige Cronjobs oder fehlende Optimierung können unnötige Last verursachen. Umgekehrt kann eine technisch saubere, stark gewachsene Website tatsächlich dauerhaft mehr Ressourcen benötigen.

Die wichtigste Regel lautet: Erst das betroffene Limit identifizieren, dann die verursachende Aktivität finden und erst danach entscheiden, ob optimiert, korrigiert oder tatsächlich mehr Ressourcen benötigt werden.