CloudLinux Ressourcennutzung in cPanel verstehen

Wenn eine Website zeitweise langsam reagiert, Prozesse abbrechen oder Fehler nur unter Last auftreten, solltest du neben PHP-Fehlern und Speicherplatz auch die verfügbaren Hosting-Ressourcen prüfen.

CURIAWEB verwendet CloudLinux, um Hosting-Accounts voneinander zu isolieren und Ressourcen kontrolliert zuzuweisen. In cPanel kannst du unter Messwerte → Ressourcennutzung nachvollziehen, ob dein Account Ressourcenlimits erreicht hat und welche Ressourcen zu einem bestimmten Zeitpunkt besonders stark beansprucht wurden.

In dieser Anleitung zeigen wir dir, wie du die CloudLinux-Ressourcennutzung öffnest, die wichtigsten Messwerte richtig einordnest und zwischen einer kurzen Lastspitze und einem tatsächlichen Ressourcenproblem unterscheidest.

Wichtig: Ein hoher Messwert oder eine einzelne Lastspitze bedeutet nicht automatisch, dass mit deiner Website etwas nicht stimmt. Entscheidend ist, ob ein Limit tatsächlich erreicht wird, wie häufig das passiert und ob der Zeitpunkt mit einem sichtbaren Problem der Website zusammenfällt.

Was macht CloudLinux? #

Auf einem Shared-Hosting-System verwenden mehrere Hosting-Accounts dieselbe physische Serverinfrastruktur.

CloudLinux sorgt unter anderem dafür, dass die Ressourcen einzelner Accounts voneinander abgegrenzt werden. Dadurch kann beispielsweise eine stark ausgelastete Website nicht unbegrenzt Ressourcen des gesamten Servers beanspruchen.

Für einen einzelnen Hosting-Account können dabei verschiedene Ressourcen separat betrachtet und begrenzt werden.

Dazu gehören je nach Serverkonfiguration insbesondere:

• CPU-Leistung
• physischer Arbeitsspeicher
• Ein-/Ausgabe-Leistung
• gleichzeitige eingehende Prozesse
• Gesamtzahl der Prozesse

Die CloudLinux-Anzeige hilft dir dabei zu erkennen, welche Ressource zu welchem Zeitpunkt beansprucht wurde.

CloudLinux-Ressourcen sind nicht dein Speicherplatz #

Eine der wichtigsten Unterscheidungen ist die zwischen Hosting-Speicher und laufenden Systemressourcen.

Bereich	Bedeutung
Speicherplatz	Platz für Dateien, E-Mails, Datenbanken und andere gespeicherte Daten
Bandbreite	übertragene Daten
Physical Memory	Arbeitsspeicher, den laufende Prozesse verwenden
CPU	Rechenleistung für laufende Prozesse
I/O	Datenrate bei Ein-/Ausgabeoperationen
Entry Processes	gleichzeitig verarbeitete eingehende Prozesse innerhalb des CloudLinux-LVE-Kontexts
Processes	Anzahl laufender Prozesse des Accounts

Wenn du wissen möchtest, welche Dateien oder E-Mails deinen Hosting-Speicher belegen, verwende stattdessen Speicherplatz und Bandbreite in cPanel überprüfen.

1. Ressourcennutzung in cPanel öffnen #

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

Messwerte → Ressourcennutzung

Die dort bereitgestellte CloudLinux-Oberfläche zeigt dir Informationen über die Ressourcennutzung deines Hosting-Accounts.

Je nach aktueller CloudLinux-Version und Serverkonfiguration können Darstellung und Bezeichnungen einzelner Werte etwas variieren.

2. Zuerst die Zusammenfassung prüfen #

Bevor du einzelne Diagramme analysierst, solltest du die Zusammenfassung beziehungsweise den aktuellen Status betrachten.

CloudLinux kann dort darauf hinweisen, ob dein Account innerhalb eines betrachteten Zeitraums Ressourcenlimits erreicht hat.

Das ist für die Diagnose wesentlich aussagekräftiger als die bloße Feststellung, dass ein Diagramm einmal einen hohen Wert zeigt.

Grundregel: Suche nicht zuerst nach dem höchsten Ausschlag im Diagramm. Prüfe zuerst, ob überhaupt ein Limit erreicht wurde und zu welchem Zeitpunkt dies passiert ist.

3. Zeitraum der Analyse auswählen #

Bei sporadischen Problemen ist der betrachtete Zeitraum besonders wichtig.

Wenn deine Website beispielsweise gestern gegen 14:30 Uhr langsam oder nicht erreichbar war, solltest du die Ressourcennutzung möglichst für genau diesen Zeitraum untersuchen.

Ein sinnvoller Diagnoseablauf ist:

Website-Problem feststellen
        ↓
Datum und Uhrzeit notieren
        ↓
Ressourcennutzung öffnen
        ↓
passenden Zeitraum auswählen
        ↓
Limits und Messwerte vergleichen

Ein Ressourcenereignis zu einem völlig anderen Zeitpunkt erklärt dein aktuelles Website-Problem normalerweise nicht.

CPU-Nutzung verstehen #

Die CPU stellt Rechenleistung zur Verfügung. PHP-Skripte, Datenbankoperationen und andere Prozesse benötigen CPU-Zeit, um ihre Aufgaben auszuführen.

Eine erhöhte CPU-Nutzung kann beispielsweise entstehen durch:

• viele gleichzeitige Website-Aufrufe
• rechenintensive PHP-Prozesse
• umfangreiche Datenbankoperationen
• Importe und Exporte
• Backup- oder Wartungsprozesse
• Cronjobs
• ineffiziente Plugins oder Anwendungen
• Bot-Zugriffe

Eine hohe CPU-Nutzung ist zunächst nur ein Messwert. Entscheidend ist, ob das für den Account geltende CPU-Limit tatsächlich erreicht wird.

Was passiert bei einem erreichten CPU-Limit? #

Wenn ein Account die ihm zugewiesene CPU-Leistung vollständig beansprucht, kann CloudLinux die weitere CPU-Nutzung begrenzen.

Vereinfacht bedeutet das:

Anwendung benötigt mehr CPU-Leistung
        ↓
CPU-Limit des Accounts wird erreicht
        ↓
weitere Verarbeitung wird begrenzt
        ↓
Prozesse können länger benötigen

Für Besucher kann sich dies beispielsweise als langsamere Website bemerkbar machen.

Ein CPU-Limit bedeutet deshalb nicht zwangsläufig, dass ein Prozess sofort mit einer sichtbaren Fehlermeldung beendet wird.

Kurze CPU-Spitze oder dauerhaftes Problem? #

Eine kurze CPU-Spitze kann bei bestimmten Aufgaben völlig normal sein.

Beispielsweise kann ein Import für kurze Zeit deutlich mehr Rechenleistung benötigen als der normale Websitebetrieb.

Kritischer ist ein Muster wie:

CPU-Limit regelmäßig erreicht
→ Website gleichzeitig langsam
→ gleiche Situation wiederholt sich
→ Ursache reproduzierbar

Dann solltest du untersuchen, welcher Prozess beziehungsweise welche Anwendung die Last verursacht.

Physical Memory verstehen #

Physical Memory bezeichnet den physischen Arbeitsspeicher, den die Prozesse deines Hosting-Accounts innerhalb der CloudLinux-Umgebung verwenden.

Dieser Wert ist nicht dasselbe wie:

• dein Hosting-Speicherplatz
• die Größe deiner Website
• das PHP-memory_limit

Das ist eine besonders wichtige Unterscheidung.

Physical Memory und PHP memory_limit unterscheiden #

Das PHP-memory_limit begrenzt den Speicher, den ein einzelner PHP-Prozess entsprechend seiner PHP-Konfiguration verwenden darf.

Das CloudLinux-Limit für Physical Memory betrachtet dagegen den Speicherverbrauch der Prozesse des Hosting-Accounts auf einer anderen Ebene.

Vereinfacht:

PHP memory_limit
→ PHP-Konfiguration eines PHP-Prozesses

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

Ein höheres PHP-memory_limit erhöht deshalb nicht automatisch das CloudLinux-Speicherlimit.

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

Wichtig: Wenn CloudLinux ein Speicherlimit meldet, solltest du nicht einfach das PHP Memory Limit erhöhen. Dadurch kann ein Ressourcenproblem sogar deutlicher werden, weil einzelne PHP-Prozesse mehr Speicher beanspruchen dürfen.

Was kann viel Arbeitsspeicher benötigen? #

Ein erhöhter Speicherverbrauch kann beispielsweise durch mehrere gleichzeitig laufende PHP-Prozesse, umfangreiche Anwendungen oder besonders speicherintensive Aufgaben entstehen.

Typische Situationen sind:

• große Importe
• Bildverarbeitung
• umfangreiche WordPress- oder WooCommerce-Prozesse
• mehrere parallele PHP-Anfragen
• Cronjobs
• Backup- oder Wartungsprozesse
• fehlerhafter oder ineffizienter Anwendungscode

I/O verstehen #

I/O steht für Input/Output und beschreibt vereinfacht die Datenrate, mit der Prozesse Daten lesen beziehungsweise schreiben können.

Das betrifft beispielsweise Zugriffe auf Dateien.

Hohe I/O-Aktivität kann unter anderem bei folgenden Aufgaben entstehen:

• großen Dateioperationen
• Backups
• Entpacken großer Archive
• umfangreichen Importen
• Cache-Erzeugung
• bestimmten datenintensiven Anwendungen

Was passiert bei einem I/O-Limit? #

Wenn ein Prozess mehr I/O-Leistung benötigt, als für den Account verfügbar ist, kann die Datenverarbeitung entsprechend begrenzt werden.

Das kann dazu führen, dass Dateioperationen beziehungsweise davon abhängige Prozesse länger benötigen.

Ein I/O-Limit ist deshalb nicht dasselbe wie ein voller Speicherplatz.

Speicherplatz voll
→ es fehlt Platz für weitere Daten

I/O-Limit erreicht
→ die Datenrate der Ein-/Ausgabe ist begrenzt

IOPS können separat angezeigt werden #

Je nach CloudLinux-Konfiguration kann zusätzlich ein Wert für IOPS angezeigt werden.

IOPS beschreibt die Anzahl der Ein-/Ausgabeoperationen pro Sekunde und ist damit nicht identisch mit der übertragenen Datenmenge pro Sekunde.

Vereinfacht:

I/O
→ wie viele Daten pro Zeit übertragen werden

IOPS
→ wie viele einzelne Ein-/Ausgabeoperationen pro Zeit erfolgen

Viele kleine Dateioperationen können deshalb ein anderes Ressourcenprofil erzeugen als wenige große Dateioperationen.

Entry Processes verstehen #

Entry Processes – häufig als EP bezeichnet – gehören zu den CloudLinux-Werten, die besonders häufig missverstanden werden.

Sie beschreiben vereinfacht die Anzahl gleichzeitig in die CloudLinux-LVE-Umgebung eintretender beziehungsweise dort gleichzeitig verarbeiteter eingehender Prozesse.

Dazu können insbesondere dynamische Webanfragen gehören.

Wichtig: Entry Processes entsprechen nicht der Anzahl deiner Website-Besucher. Ein Besucher ist nicht automatisch ein Entry Process.

Warum Besucher und Entry Processes nicht dasselbe sind #

Ein Besucher kann nacheinander mehrere Anfragen auslösen. Gleichzeitig können verschiedene Anfragen sehr unterschiedlich lange verarbeitet werden.

Für das EP-Limit ist deshalb die Gleichzeitigkeit relevanter Prozesse entscheidend und nicht einfach die Zahl der Besucher pro Tag.

Eine Website mit vielen schnellen, gut gecachten Aufrufen kann sich daher anders verhalten als eine Website mit wenigen, aber sehr langsamen dynamischen Anfragen.

Was passiert beim Erreichen des Entry-Process-Limits? #

Wenn zu viele entsprechende Prozesse gleichzeitig verarbeitet werden müssen und das EP-Limit erreicht wird, können zusätzliche Anfragen nicht normal verarbeitet werden.

In diesem Zusammenhang können Besucher beispielsweise Fehler wie:

508 Resource Limit Is Reached

sehen.

Die konkrete Diagnose und Behebung behandeln wir im nächsten Artikel unter Resource Limit Is Reached: CloudLinux-Limits erkennen und beheben.

Number of Processes verstehen #

CloudLinux kann zusätzlich die Gesamtzahl der Prozesse eines Accounts begrenzen. Dieser Wert wird häufig als Number of Processes beziehungsweise NPROC bezeichnet.

Hier geht es nicht nur um gleichzeitig eingehende Webanfragen.

Zum Prozessbestand können – abhängig von der jeweiligen Umgebung – unterschiedliche Prozesse des Accounts beitragen.

Deshalb sind Entry Processes und Number of Processes nicht dasselbe.

Entry Processes und Number of Processes vergleichen #

Wert	Vereinfacht betrachtet
Entry Processes (EP)	gleichzeitig eintretende beziehungsweise verarbeitete eingehende Prozesse
Number of Processes (NPROC)	Gesamtzahl laufender Prozesse des Accounts

Ein Account kann deshalb ein Prozessproblem haben, ohne dass EP und NPROC zwingend gleichzeitig dasselbe Verhalten zeigen.

Faults sind für die Diagnose besonders wichtig #

In der CloudLinux-Auswertung können neben aktuellen beziehungsweise durchschnittlichen Werten auch sogenannte Faults beziehungsweise Limit-Ereignisse relevant sein.

Ein Fault zeigt vereinfacht, dass eine Ressourcengrenze erreicht wurde.

Das ist für die Diagnose oft aussagekräftiger als ein Diagramm, dessen Linie lediglich nahe am Limit liegt.

Praxis-Tipp: Wenn du wissen möchtest, ob ein Ressourcenlimit wirklich relevant war, achte besonders auf dokumentierte Limit-Ereignisse und deren Zeitpunkt.

100 % bedeutet nicht bei jedem Wert dasselbe #

Prozentanzeigen müssen immer im Kontext des jeweiligen Ressourcenlimits gelesen werden.

Beispielsweise bedeutet eine CPU-Anzeige von 100 % innerhalb einer Hosting-Ressourcenansicht nicht automatisch, dass der gesamte physische Server zu 100 % ausgelastet ist.

Sie kann sich auf die deinem Account zugewiesene Ressource beziehen.

Verwende Prozentwerte deshalb nicht als Aussage über die Gesamtauslastung des Servers.

Account-Limit und Serverauslastung unterscheiden #

Wenn dein Hosting-Account ein CloudLinux-Limit erreicht, folgt daraus nicht automatisch, dass der gesamte Hosting-Server überlastet ist.

CloudLinux dient gerade dazu, Ressourcen einzelner Accounts voneinander abzugrenzen.

Vereinfacht:

Account erreicht eigenes Ressourcenlimit
≠
gesamter Server ist ausgelastet

Diese Unterscheidung ist bei der Interpretation der Werte entscheidend.

Durchschnittswerte können kurze Spitzen verdecken #

Ein Durchschnittswert über einen längeren Zeitraum kann unauffällig aussehen, obwohl innerhalb dieses Zeitraums eine kurze starke Lastspitze aufgetreten ist.

Wenn deine Website nur für wenige Minuten Probleme hatte, solltest du deshalb einen möglichst passenden Zeitraum betrachten und Limit-Ereignisse berücksichtigen.

Ein einzelner Peak ist noch keine Diagnose #

Angenommen, die CPU-Nutzung erreicht einmal kurz einen hohen Wert, während:

• die Website normal funktioniert
• keine Limits dokumentiert werden
• keine Fehler auftreten
• der Wert anschließend wieder sinkt

Dann besteht nicht automatisch Handlungsbedarf.

Eine Lastspitze kann schlicht durch eine gerade ausgeführte Aufgabe entstanden sein.

Wiederkehrende Limits sind relevanter #

Deutlich interessanter ist ein Muster wie:

jeden Tag gegen 02:00 Uhr
→ CPU steigt stark
→ I/O steigt
→ Limits werden erreicht
→ Website reagiert gleichzeitig langsam

Ein solches wiederkehrendes Muster spricht dafür, die zu diesem Zeitpunkt laufenden Prozesse genauer zu untersuchen.

Cronjobs mit Ressourcenereignissen vergleichen #

Wenn Ressourcenprobleme regelmäßig zu derselben Uhrzeit auftreten, kontrolliere auch geplante Cronjobs.

Ein Import, Export, Backup oder Synchronisationsprozess kann zu einem wiederkehrenden Lastmuster führen.

Wie du Cronjob-Probleme untersuchst, erklären wir unter Cronjob funktioniert nicht: Ursachen und Lösungen.

Mehrere Cronjobs zur selben Zeit #

Wenn mehrere ressourcenintensive Cronjobs exakt gleichzeitig starten, können sich deren Anforderungen addieren.

Beispielsweise:

02:00 → Import
02:00 → Export
02:00 → Synchronisation
02:00 → Wartungsprozess

Wenn die jeweiligen Anwendungen zeitlich flexibel sind, kann eine Verteilung der Startzeiten sinnvoll sein.

Ändere von einer Anwendung vorgegebene Zeitpläne jedoch nicht ohne Prüfung.

Backups können Ressourcen benötigen #

Backup- und Archivierungsprozesse können je nach Umfang CPU, I/O und andere Ressourcen beanspruchen.

Wenn eine Lastspitze während eines Backups auftritt, ist der zeitliche Zusammenhang deshalb relevant.

Das bedeutet jedoch nicht automatisch, dass das Backup fehlerhaft ist.

Importe und Exporte können Lastspitzen verursachen #

Große Datenimporte und -exporte sind typische Beispiele für zeitweise ressourcenintensive Vorgänge.

Ein WooCommerce-Produktimport, eine umfangreiche Datenbankoperation oder die Verarbeitung vieler Dateien kann vorübergehend deutlich mehr Ressourcen benötigen als der normale Websitebetrieb.

WordPress-Plugins als mögliche Ursache #

Bei WordPress können Plugins Hintergrundaufgaben, Datenbankabfragen oder externe Verbindungen ausführen.

Wenn ein Ressourcenproblem unmittelbar nach Installation oder Aktualisierung eines Plugins beginnt, sollte dieser zeitliche Zusammenhang untersucht werden.

Das Plugin ist dadurch noch nicht automatisch als Ursache bewiesen.

Eine systematische Konfliktdiagnose findest du unter WordPress Plugin- und Theme-Konflikte erkennen und beheben.

WooCommerce benötigt häufig mehr dynamische Verarbeitung #

Onlineshops enthalten viele Bereiche, die nicht einfach wie statische Seiten behandelt werden können.

Warenkorb, Checkout, Kundenkonto, Bestellungen, Hintergrundaufgaben und verschiedene Erweiterungen können zusätzliche dynamische Verarbeitung verursachen.

Ein WooCommerce-Shop sollte deshalb nicht allein anhand der Besucherzahl mit einer einfachen Informationswebsite verglichen werden.

Bots können Ressourcen verbrauchen #

Nicht nur menschliche Besucher erzeugen Last.

Bots, Crawler und automatisierte Scanner können viele Anfragen an eine Website senden.

Wenn ungewöhnliche Ressourcenlast gleichzeitig mit starkem Traffic auftritt, können deshalb auch Zugriffsstatistiken beziehungsweise Access Logs relevant sein.

Viele Besucher bedeuten nicht automatisch Ressourcenprobleme #

Eine hohe Besucherzahl allein sagt wenig über die benötigten Serverressourcen aus.

Entscheidend sind unter anderem:

• wie viele Anfragen gleichzeitig erfolgen
• wie schnell PHP diese verarbeitet
• wie effizient Datenbankabfragen sind
• welche Inhalte gecacht werden können
• welche Plugins beziehungsweise Anwendungen beteiligt sind

Eine gut optimierte Website kann deshalb deutlich mehr Anfragen verarbeiten als eine technisch ineffiziente Website mit vergleichbarer Anwendung.

Caching kann dynamische Last reduzieren #

Wenn Inhalte nicht bei jedem Aufruf vollständig neu durch PHP und die Datenbank erzeugt werden müssen, kann Caching die dynamische Serverlast deutlich reduzieren.

CURIAWEB stellt mit AccelerateWP ein entsprechendes Werkzeug im cPanel bereit.

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

Caching löst nicht jedes Ressourcenproblem #

Ein Cache hilft vor allem bei Anfragen, die sinnvoll zwischengespeichert werden können.

Er löst beispielsweise nicht automatisch:

• fehlerhafte Cronjobs
• extrem aufwendige Backend-Prozesse
• schlecht programmierte Datenbankoperationen
• bestimmte WooCommerce-Hintergrundaufgaben
• Speicherlecks oder fehlerhaften Code

Aktiviere deshalb nicht wahllos zusätzliche Cache-Systeme, wenn die eigentliche Ursache unbekannt ist.

Mehrere Cache-Plugins können problematisch sein #

Mehr Caching bedeutet nicht automatisch mehr Geschwindigkeit.

Mehrere gleichzeitig arbeitende Cache- und Optimierungslösungen können sich gegenseitig beeinflussen oder unnötige Komplexität erzeugen.

Verwende deshalb eine kontrollierte und zur Hosting-Umgebung passende Konfiguration.

PHP-Version kann die Ressourcennutzung beeinflussen #

PHP-Versionen unterscheiden sich unter anderem hinsichtlich Performance und Software-Kompatibilität.

Eine veraltete oder für die Anwendung ungeeignete PHP-Version kann deshalb indirekt auch für die Ressourcenanalyse relevant sein.

Die PHP-Version einer Domain verwaltest du bei CURIAWEB grundsätzlich über den MultiPHP-Manager.

Wechsle PHP jedoch nicht nur deshalb, weil ein Ressourcenwert hoch ist. Prüfe zuerst die Kompatibilität deiner Anwendung.

PHP Memory Limit ist keine Performance-Einstellung #

Ein häufiger Fehler besteht darin, bei einer langsamen Website einfach das PHP-memory_limit stark zu erhöhen.

Das Memory Limit stellt einem PHP-Prozess lediglich einen maximal zulässigen Speicherrahmen zur Verfügung.

Es macht PHP nicht automatisch schneller und stellt dem Hosting-Account keine zusätzliche CPU-Leistung zur Verfügung.

Error Log parallel prüfen #

Wenn eine Website gleichzeitig Fehler zeigt, solltest du neben den CloudLinux-Werten auch das Fehlerprotokoll untersuchen.

Unter cPanel Error Log lesen und Website-Fehler finden erklären wir, wie du typische PHP- und Webservermeldungen einordnest.

Ressourcenproblem oder PHP-Fehler? #

Beide Probleme können ähnliche Symptome verursachen.

Beobachtung	Wichtiger Prüfpunkt
PHP Fatal Error	Error Log
Allowed memory size exhausted	PHP Memory Limit und Anwendung
CloudLinux-Limit dokumentiert	Ressourcennutzung
Resource Limit Is Reached	CloudLinux-Limits
Website sporadisch langsam	Zeitpunkt mit Ressourcen und Logs vergleichen
Speicherplatz voll	Speicherplatznutzung

CPU-Limit und langsame Datenbank nicht gleichsetzen #

Wenn eine Anwendung viel CPU benötigt, kann eine ineffiziente Datenbankabfrage beteiligt sein. Der CPU-Wert allein beweist dies jedoch nicht.

Umgekehrt kann eine langsame Anwendung durch externe APIs, Dateizugriffe oder andere Faktoren verzögert werden, ohne dass die CPU permanent am Limit liegt.

Die Ressourcengrafik zeigt dir was belastet wird – sie zeigt nicht automatisch welcher konkrete Programmcode die Ursache ist.

Die CloudLinux-Anzeige ist kein Prozess-Debugger #

CloudLinux hilft dir, Ressourcenengpässe zeitlich und nach Ressourcentyp einzugrenzen.

Die Anzeige sagt beispielsweise:

CPU-Limit wurde um 14:32 Uhr erreicht

Sie bedeutet nicht automatisch:

Plugin XYZ ist schuld

Für die eigentliche Ursachenanalyse musst du den Zeitpunkt mit Website-Aktivitäten, Cronjobs, Logs, Updates oder anderen technischen Informationen kombinieren.

Was unmittelbar vor dem Ressourcenproblem passiert ist #

Wenn die Ressourcennutzung erst seit kurzem auffällig ist, prüfe Änderungen wie:

• neues Plugin installiert
• Plugin oder Theme aktualisiert
• neue Website importiert
• Cronjob eingerichtet
• Backup-Lösung geändert
• neue Marketingkampagne gestartet
• Traffic stark gestiegen
• WooCommerce-Erweiterung aktiviert
• PHP-Version geändert

Der zeitliche Zusammenhang ist ein wichtiger Hinweis, aber noch kein Beweis.

Lastspitze nach Änderung gezielt reproduzieren #

Wenn eine bestimmte Aktion möglicherweise für die hohe Last verantwortlich ist, kannst du – sofern die Aktion gefahrlos wiederholbar ist – den Ablauf gezielt beobachten.

Beispielsweise:

Ressourcennutzung prüfen
        ↓
Zeit notieren
        ↓
betroffene Aktion ausführen
        ↓
Ressourcennutzung erneut prüfen

Führe dabei keine Zahlungs-, Versand-, Import- oder anderen verändernden Prozesse mehrfach aus, wenn du deren Verhalten bei Wiederholung nicht kennst.

Mehrere Websites im selben cPanel-Account berücksichtigen #

Wenn mehrere Domains oder Anwendungen innerhalb desselben Hosting-Accounts betrieben werden, können sie gemeinsam Ressourcen des Accounts verwenden.

Eine hohe Ressourcennutzung muss deshalb nicht zwangsläufig von der Website stammen, bei der du das Problem zuerst bemerkst.

Berücksichtige alle Anwendungen und Hintergrundprozesse des betreffenden Accounts.

Alte oder vergessene Installationen können Ressourcen erzeugen #

Eine nicht mehr aktiv genutzte WordPress-Testinstallation kann weiterhin:

• von Bots aufgerufen werden
• WP-Cron ausführen
• Plugins laden
• automatische Aufgaben verarbeiten

Wenn mehrere Installationen im Hosting-Account vorhanden sind, solltest du deshalb auch ältere Testsysteme berücksichtigen.

Ressourcenwerte nach Optimierung vergleichen #

Wenn du eine konkrete Ursache gefunden und behoben hast, vergleiche anschließend die Ressourcennutzung unter möglichst ähnlichen Bedingungen.

Beispiel:

Vorher:
CPU-Limit täglich mehrfach erreicht

Änderung:
fehlerhaften Hintergrundprozess korrigiert

Nachher:
keine CPU-Faults mehr im vergleichbaren Zeitraum

Damit kannst du wesentlich besser beurteilen, ob die Maßnahme tatsächlich geholfen hat.

Nicht mehrere Optimierungen gleichzeitig durchführen #

Wenn du gleichzeitig:

PHP wechselst
Cache änderst
Plugins deaktivierst
Cronjobs verschiebst
Datenbank optimierst

und die Last anschließend sinkt, weißt du nicht, welche Maßnahme dafür verantwortlich war.

Gehe bei der Diagnose deshalb kontrolliert und schrittweise vor.

Wann ist ein Ressourcenlimit tatsächlich relevant? #

Ein Limit ist besonders relevant, wenn mehrere Punkte zusammenkommen:

• das Limit wird tatsächlich erreicht
• das Ereignis tritt wiederholt auf
• der Zeitpunkt stimmt mit einem Website-Problem überein
• das Verhalten lässt sich reproduzieren oder einem Prozess zuordnen

Eine einzelne kurze Lastspitze ohne sichtbare Auswirkungen sollte dagegen nicht überbewertet werden.

Typische Ressourcen und ihre Bedeutung #

Ressource	Bedeutung	Bei Limit zuerst untersuchen
CPU	Rechenleistung	PHP-Prozesse, Anwendung, Cronjobs, Traffic
Physical Memory	Arbeitsspeicher der Account-Prozesse	parallele/speicherintensive Prozesse
I/O	Datenrate bei Dateioperationen	Backups, Archive, Importe, Dateioperationen
IOPS	Anzahl der I/O-Operationen	viele kleine Dateioperationen
Entry Processes	gleichzeitig eintretende/verarbeitete Prozesse	gleichzeitige dynamische Anfragen
Number of Processes	Gesamtzahl laufender Prozesse	Hintergrundprozesse, parallele Aufgaben

CloudLinux-Werte systematisch analysieren #

1. Notiere Datum und Uhrzeit des Website-Problems.
2. Öffne Messwerte → Ressourcennutzung.
3. Wähle einen passenden Zeitraum.
4. Prüfe, ob CloudLinux ein erreichtes Ressourcenlimit meldet.
5. Identifiziere die betroffene Ressource.
6. Prüfe Faults beziehungsweise Limit-Ereignisse.
7. Vergleiche deren Zeitpunkt mit dem Website-Problem.
8. Prüfe Cronjobs, Importe, Backups und andere Aktivitäten zu diesem Zeitpunkt.
9. Kontrolliere bei Website-Fehlern zusätzlich das Error Log.
10. Ändere anschließend gezielt nur eine mögliche Ursache.
11. Vergleiche die Ressourcennutzung nach der Änderung erneut.

Was du bei hohen Ressourcenwerten nicht tun solltest #

Vermeide insbesondere folgende Schnellschüsse:

• PHP Memory Limit pauschal extrem erhöhen
• PHP-Version ohne Kompatibilitätsprüfung wechseln
• mehrere Plugins gleichzeitig deaktivieren
• Dateien auf Verdacht löschen
• mehrere Cache-Plugins installieren
• Cronjobs wahllos entfernen
• einen einzelnen Peak als dauerhafte Überlastung interpretieren

Praxis-Tipp: Ressourcenanalyse ist eine zeitliche Diagnose. Die Frage lautet nicht nur „Welcher Wert ist hoch?“, sondern vor allem „Welches Limit wurde wann erreicht und was lief zu genau diesem Zeitpunkt?“

Wenn die Website langsam ist, aber keine Limits erreicht werden #

Wenn CloudLinux keine relevanten Limit-Ereignisse zeigt, solltest du nicht weiter versuchen, ein Ressourcenproblem zu erzwingen.

Eine langsame Website kann zahlreiche andere Ursachen haben.

Dazu gehören beispielsweise:

• langsame Datenbankabfragen
• externe APIs
• große oder schlecht optimierte Bilder
• JavaScript im Browser
• Plugins oder Themes
• fehlendes oder ungeeignetes Caching
• DNS- oder Netzwerkabhängigkeiten

CloudLinux ist dann lediglich eine mögliche Ursache, die du durch die Messwerte bereits besser eingrenzen konntest.

Wenn die Website gar nicht erreichbar ist #

Bei einer vollständig nicht erreichbaren Website solltest du nicht ausschließlich die CloudLinux-Anzeige betrachten.

DNS, Domainkonfiguration, SSL, Webserver, PHP, Anwendung und weitere Ebenen können ebenfalls relevant sein.

Die vollständige Diagnose behandeln wir unter Website nicht erreichbar: Hosting-Fehler systematisch diagnostizieren.

Wann solltest du den CURIAWEB-Support kontaktieren? #

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

Hilfreich sind insbesondere:

• betroffene Domain beziehungsweise Anwendung
• Datum und Uhrzeit des Problems
• betroffene Ressource
• sichtbare Limit-Ereignisse beziehungsweise Faults
• sichtbares Verhalten der Website
• ob das Problem regelmäßig oder nur einmal auftritt
• kürzlich vorgenommene Änderungen
• zu diesem Zeitpunkt laufende Cronjobs, Importe oder andere Aufgaben
• gegebenenfalls relevante Error-Log-Einträge

Je genauer der Zeitpunkt bekannt ist, desto leichter lässt sich ein Ressourcenereignis mit einer bestimmten Aktivität in Verbindung bringen.

Zusammenfassung #

Unter Messwerte → Ressourcennutzung kannst du im CURIAWEB-cPanel nachvollziehen, wie dein Hosting-Account die von CloudLinux verwalteten Ressourcen verwendet.

Zu den wichtigsten Messwerten gehören CPU, Physical Memory, I/O, gegebenenfalls IOPS, Entry Processes und die Gesamtzahl der Prozesse.

Diese Werte dürfen nicht mit Speicherplatz oder Bandbreite verwechselt werden. Ebenso ist das CloudLinux Physical Memory nicht dasselbe wie das PHP-memory_limit.

Für die Diagnose sind nicht nur hohe Messwerte wichtig. Entscheidend ist insbesondere, ob ein Ressourcenlimit tatsächlich erreicht wurde, wann dies passiert ist und ob der Zeitpunkt mit einem sichtbaren Problem der Website übereinstimmt.

Entry Processes entsprechen nicht der Zahl deiner Besucher. Auch ein CPU-Wert von 100 % innerhalb der Ressourcenanzeige bedeutet nicht automatisch, dass der gesamte Hosting-Server vollständig ausgelastet ist.

Kurze Lastspitzen können bei Importen, Backups, Cronjobs oder anderen Aufgaben normal sein. Wiederkehrende Limit-Ereignisse zusammen mit einer langsamen oder fehlerhaften Website sollten dagegen genauer untersucht werden.

Vergleiche Ressourcenereignisse mit Cronjobs, Updates, Traffic, Error Logs und anderen Aktivitäten zum selben Zeitpunkt. Ändere anschließend immer nur eine mögliche Ursache und kontrolliere, ob sich das Verhalten verbessert.

Die wichtigste Regel lautet: Nicht den höchsten Wert suchen, sondern das tatsächliche Limit-Ereignis mit Zeitpunkt und verursachender Aktivität in Verbindung bringen.