Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux

Tempo di lettura ca.: 18 minuti

Se il tuo sito web mostra temporaneamente il messaggio Limite delle risorse raggiunto mostra, il tuo account di hosting ha raggiunto un limite di risorse gestito da CloudLinux.

Il messaggio non significa automaticamente che l'intero server di hosting sia sovraccarico. CURIAWEB utilizza CloudLinux per isolare gli account di hosting l'uno dall'altro e fornire loro risorse definite. Se viene raggiunta una di queste cifre, CloudLinux può limitare l'ulteriore utilizzo delle risorse dell'account in questione.

In questa guida ti mostriamo come scoprire, quale limite di risorse è stato raggiunto, quando è successo e quale applicazione o attività potrebbe esserne responsabile.

Importante: Non cercare di risolvere il messaggio di errore apportando modifiche casuali a PHP, WordPress o cPanel. Apri prima l'utilizzo delle risorse di CloudLinux e verifica quale limite è stato effettivamente raggiunto.

Cosa significa „Resource Limit Is Reached“? #

CloudLinux gestisce diverse risorse di un account di hosting. A seconda della configurazione del server, queste includono, tra le altre:

  • Prestazioni della CPU
  • memoria fisica
  • Prestazioni di I/O
  • processi di inserimento simultanei
  • Numero totale di processi in esecuzione

Se viene raggiunta una soglia corrispondente, l'ulteriore trattamento può essere limitato.

A seconda della risorsa interessata e della richiesta in fase di elaborazione, la cosa può manifestarsi in modo diverso.

I possibili sintomi includono, ad esempio:

  • Il sito web risponde in modo insolitamente lento
  • singole pagine non caricano
  • Il backend risponde a intermittenza
  • I processi PHP impiegano insolitamente molto tempo
  • Le richieste falliscono sotto carico
  • Limite di risorse 508 raggiunto viene visualizzato

Un errore 508 non è automaticamente un sovraccarico del server #

Una distinzione tecnica importante è:

L'account di hosting ha raggiunto il limite di CloudLinux
≠
l'intero server di hosting è sovraccarico

CloudLinux utilizza i cosiddetti limiti delle risorse LVE per separare i singoli account di hosting l'uno dall'altro.

Se il tuo account raggiunge un limite, ciò riguarda quindi anzitutto le risorse assegnate al tuo account.

Breve spiegazione: Il messaggio di errore dice inizialmente: „Questo account di hosting richiede al momento una quantità maggiore di una determinata risorsa rispetto a quella disponibile entro il limite attuale.“ Non dice ancora perché questo accada.

1. Annotare data e ora dell'errore #

Se il messaggio compare solo sporadicamente, il momento esatto della diagnosi è particolarmente importante.

Si prega di notare:

Data
Ora
Dominio interessato
URL interessato
Azione eseguita
Messaggio di errore visibile

Esempio:

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

Da questo momento in poi puoi esaminare le risorse di CloudLinux.

2. Apri l'utilizzo delle risorse di CloudLinux #

Accedi al tuo cPanel di CURIAWEB e apri:

Valori misurati → Utilizzo delle risorse

L'interfaccia CloudLinux mostra l'utilizzo delle risorse del tuo account di hosting e può indicare se sono stati raggiunti i limiti delle risorse.

Una spiegazione dettagliata di ciascun valore di misura è disponibile alla pagina Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.

3. Selezionare il periodo di tempo adatto #

Seleziona un intervallo di tempo che includa il momento del problema.

Se l'errore si è verificato ad esempio alle 14:37, ti interessa in particolare l'utilizzo delle risorse intorno a quel momento.

Il superamento di un limite di ieri sera normalmente non spiega un errore di oggi pomeriggio.

4. Verificare quale limite è stato raggiunto #

Ora arriva il passo più importante: stabilisci, quale risorsa ha effettivamente raggiunto il suo limite.

A seconda della configurazione di CloudLinux, ad esempio, potrebbero essere rilevanti i seguenti valori:

RisorsaSignificato
CPUpotenza di calcolo disponibile
Memoria fisicaMemoria di lavoro dei processi dell'account
I/Ovelocità di trasmissione dei dati nelle operazioni di I/O
IOPSNumero di operazioni di I/O
Processi di ingressoprocessi simultanei o elaborati contemporaneamente
Numero di processiNumero totale dei processi in esecuzione dell'account

Quale misura sia opportuno adottare dipende essenzialmente da, quale di questi limiti è interessato.

5. Controllare guasti ed eventi limite #

Nell'analisi di CloudLinux, presta particolare attenzione ai cosiddetti Guasti rispettivamente eventi limite documentati.

Un valore elevato da solo non significa automaticamente che il limite sia stato superato o raggiunto.

Per la diagnosi è quindi importante:

Quale limite?
        ↓
Quando è stato raggiunto?
        ↓
Con che frequenza?
        ↓
Cosa era in esecuzione in quel momento?

Consiglio pratico: Un guasto nello stesso identico momento del tuo problema al sito web è molto più significativo di un qualsiasi carico elevato diverse ore prima.

Limite CPU raggiunto #

Se viene raggiunto il limite della CPU, il tuo account di hosting necessita in quel momento interamente della potenza di calcolo a sua disposizione.

CloudLinux può limitare ulteriormente l'utilizzo della CPU di conseguenza. I processi potrebbero quindi richiedere più tempo.

Le cause tipiche possono essere:

  • molte chiamate a siti web dinamici
  • processi PHP complessi
  • plugin inefficienti
  • operazioni di database estese
  • Importazioni o esportazioni
  • Cronjob
  • Processi di backup o di manutenzione
  • Bot o un numero insolitamente alto di accessi

Limite della CPU raggiunto solo brevemente #

Un singolo breve picco della CPU non rappresenta necessariamente un problema.

Ad esempio, se stai eseguendo un grosso import, l'utilizzo della CPU potrebbe aumentare temporaneamente in modo significativo.

Diventa più interessante quando:

  • il limite della CPU viene raggiunto regolarmente
  • il sito web rallenta contemporaneamente
  • la situazione si verifica senza un'attività avviata manualmente
  • il comportamento è riproducibile

Limite della CPU regolarmente alla stessa ora #

Se, ad esempio, la CPU raggiunge il suo limite circa alla stessa ora ogni giorno, controlla le attività pianificate.

I candidati tipici sono:

  • Cronjob
  • Importo
  • Esporta
  • Sincronizzazioni
  • Attività di manutenzione
  • Backup delle applicazioni

Spieghiamo come analizzare i cronjob difettosi o ad alta intensità di risorse su Cronjob non funziona: cause e soluzioni.

Avviare più cronjob contemporaneamente #

Quando più attività a elevato consumo di risorse si avviano contemporaneamente, il loro fabbisogno di risorse può sommarsi.

Esempio:

02:00 → Importazione prodotti
02:00 → Sincronizzazione dati
02:00 → Esportazione
02:00 → Processo di manutenzione

Se le applicazioni lo consentono, può essere utile distribuire tali attività nel corso del tempo.

Tuttavia, non modificare alcun cronjob impostato da un'applicazione senza conoscerne la funzione.

Limite di memoria fisica raggiunto #

Se il limite di CloudLinux per Memoria fisica viene raggiunto, i processi in esecuzione dell'account utilizzano troppa memoria all'interno del limite di risorse disponibile.

Le cause tipiche possono essere, ad esempio:

  • molti processi PHP in esecuzione simultanea
  • importazioni ad alto consumo di memoria
  • Elaborazione delle immagini
  • applicazioni estese
  • diversi processi in background paralleli
  • codice applicativo difettoso o inefficiente

La memoria fisica non è il limite di memoria di PHP #

Questi due valori vengono spesso confusi.

Il PHP-limite di memoria e il limite di CloudLinux per la memoria fisica operano a livelli diversi.

In sintesi:

PHP memory_limit
→ limite massimo di memoria di un processo PHP

CloudLinux Physical Memory
→ consumo di memoria dei processi dell'account all'interno della LVE

Se viene raggiunto il limite di memoria di CloudLinux, dovresti quindi non basta semplicemente aumentare il limite di memoria di PHP.

Spieghiamo come funzionano i limiti di PHP su Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.

Attenzione: Un limite di memoria PHP più alto non assegna automaticamente più memoria CloudLinux al tuo account di hosting.

„Allowed memory size exhausted“ ist ein anderer Fehler #

Wenn im Error Log eine Meldung wie:

Dimensione di memoria consentita di ... byte esaurita

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 #

Processi di ingresso rispettivamente 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:

Limite di risorse 508 raggiunto

verificarsi.

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.

In sintesi:

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? #

Le possibili cause includono, ad esempio:

  • viele gleichzeitige dynamische Anfragen
  • lenta elaborazione PHP
  • langsame Datenbankoperationen
  • ungecachte dynamische Seiten
  • Bot o accessi automatizzati
  • 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 rispettivamente Numero di processi definito.

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
  • Attività in background
  • 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
  • Backup
  • Decompressione di archivi di grandi dimensioni
  • umfangreiche Importe
  • viele Schreibvorgänge
  • Generazione della cache

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 Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

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:

LimitTypische erste Prüfpunkte
CPUPHP, Plugins, Cronjobs, Importe, Traffic
Memoria fisicaspeicherintensive und parallele Prozesse
Processi di ingressogleichzeitige beziehungsweise langsame dynamische Anfragen
Numero di processiHintergrundprozesse, Cronjobs, parallele Aufgaben
I/OBackups, Dateioperationen, Archive, Importe
IOPSsehr 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.

Verifica ad esempio:

  • 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:

Valori misurati → Errore

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

Wie du diese Einträge liest, erklären wir unter Leggere il log degli errori di cPanel e trovare gli errori del sito web.

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
  • Aggiornamento del plugin
  • 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 Identificare e risolvere i conflitti tra plugin e temi WordPress.

WP-Cron und Hintergrundaufgaben berücksichtigen #

WordPress verwendet eigene geplante Ereignisse für verschiedene Hintergrundaufgaben.

I plugin possono, ad esempio, fare in modo che:

  • E-Mails verarbeiten
  • Sincronizza dati
  • 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.

Questi possono includere, ad esempio:

  • Carrello
  • Cassa
  • Conto cliente
  • Ordini
  • Importazioni di prodotti
  • Sincronizzazioni
  • 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
  • Crawler SEO
  • Servizi di monitoraggio
  • Preis- oder Content-Crawler
  • scanner automatizzati

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 Valori misurati usare.

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.

Verifica la cache #

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.

Puoi trovare ulteriori informazioni su AccelerateWP in cPanel spiegato.

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:

  • cronjob difettosi
  • 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.

Spieghiamo la procedura su Attivare e gestire le estensioni PHP in cPanel.

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 o limite di memoria 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 Controllare lo spazio di archiviazione e la larghezza di banda in cPanel.

Mehrere Websites im Account berücksichtigen #

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

Questo significa:

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
  • Memoria RAM

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.

Esempio:

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.

Importante: „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.

Esempi:

  • grande importazione una tantum
  • 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.

Verifica:

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
  • se la memorizzazione nella cache degli oggetti (object caching) viene utilizzata in modo sensato
  • 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.

Esempi:

  • 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.

Verifica:

  • Changelog und Systemanforderungen
  • Compatibilità PHP
  • 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
  • Plugin e temi
  • estensioni PHP richieste
  • Registro degli errori
  • 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:

  • Versione PHP
  • Estensioni PHP
  • Cronjob
  • Configurazione della cache
  • alte absolute Pfade
  • Errore di applicazione
  • 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 #

Se tu contemporaneamente:

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.

Esempio:

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. Apri Valori misurati → Utilizzo delle risorse.
  3. Wähle den passenden Zeitraum.
  4. Prüfe, welches Limit erreicht wurde.
  5. Kontrolliere Faults beziehungsweise Limit-Ereignisse.
  6. Confronta il loro momento con il problema del sito web.
  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. In caso di errori del sito web, controlla anche il log degli errori.
  11. Prüfe ungewöhnlichen Traffic beziehungsweise Bots.
  12. Modifica una sola possibile causa alla volta.
  13. Teste anschließend erneut.
  14. Vergleiche die CloudLinux-Werte vor und nach der Änderung.

Was du nicht tun solltest #

Evita in particolare:

  • PHP Memory Limit ohne Diagnose extrem erhöhen
  • installare più plugin di cache contemporaneamente
  • Cambiare le versioni di PHP a caso
  • 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

Regola fondamentale: 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.

Le possibili cause includono, ad esempio:

  • Errore PHP
  • Problemi di database
  • servizi esterni
  • DNS
  • SSL
  • Plugin- oder Theme-Fehler
  • Browser- beziehungsweise Frontend-Probleme

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

Quando dovresti contattare il supporto di CURIAWEB? #

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.

Sono particolarmente utili:

  • dominio interessato
  • betroffene URL oder Funktion
  • Data e ora esatte
  • messaggio di errore visibile
  • betroffenes CloudLinux-Limit
  • angezeigte Faults beziehungsweise Limit-Ereignisse
  • Häufigkeit des Problems
  • modifiche recenti
  • cron job in esecuzione, importazioni o attività in background
  • voci di registro degli errori rilevanti

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

Riepilogo #

Die Meldung Limite delle risorse raggiunto 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 Valori misurati → Utilizzo delle risorse 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-limite di memoria 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.

La regola più importante è: 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.

Ultimo aggiornamento 28 agosto 2026
Questo articolo è stato utile?
Contenuto
Consenso ai cookie con Real Cookie Banner