Resource Limit Is Reached: Identify and Fix CloudLinux Limits

If your website temporarily shows the message Resource Limit Is Reached shows, your hosting account has reached a resource limit managed by CloudLinux.

The message does not automatically mean that the entire hosting server is overloaded. CURIAWEB uses CloudLinux to isolate hosting accounts from each other and provide them with defined resources. If one of these limits is reached, CloudLinux can restrict the further resource usage of the account in question.

In this guide we show you how to find out, which resource limit was reached, when that happened, and which application or task might be responsible for it.

Important: Do not try to fix the error message by making random changes to PHP, WordPress, or cPanel. First, open CloudLinux Resource Usage and determine which limit was actually reached.

Resource Limit Is Reached #

CloudLinux manages various resources of a hosting account. Depending on the server configuration, these include, among others:

• CPU performance
• physical memory
• Input/Output Performance
• concurrent entry processes
• Total number of running processes

If a corresponding limit is reached, further processing can be restricted.

Depending on which resource is affected and which request is currently being processed, this can manifest in different ways.

Possible symptoms include, for example:

• Website is responding unusually slowly
• individual pages are not loading
• Backend is intermittently not responding
• PHP processes are taking an unusually long time
• Requests fail under load
• 508 Resource Limit Is Reached is displayed

A 508 error is not automatically a server overload #

An important technical distinction is:

Hosting account reaches CloudLinux limit
≠
entire hosting server is overloaded

CloudLinux uses so-called LVE resource limits to isolate individual hosting accounts from one another.

If your account reaches a limit, this initially affects the resources assigned to your account.

Briefly explained: The error message initially says: „This hosting account currently needs more of a specific resource than is available within its current limit.“ It does not yet say why this is happening.

1. Note the date and time of the error #

If the message only appears sporadically, the exact time is particularly important for the diagnosis.

Take as many notes as possible:

Date
Time
Affected domain
Affected URL
Executed action
Visible error message

Example:

08/28/2026
02:37 PM
example.ch
/wp-admin/
508 Resource Limit Is Reached

From this point on, you can then examine the CloudLinux resources.

2. Open CloudLinux Resource Usage #

Log in to your CURIAWEB cPanel and open:

Metrics → Resource Usage

The CloudLinux interface displays the resource usage of your hosting account and can indicate whether resource limits have been reached.

You can find a detailed explanation of the individual measured values under Understanding CloudLinux Resource Usage in cPanel.

3. Select suitable time period #

Select a time period that includes the time of the issue.

If the error occurred at 2:37 PM, for example, you are particularly interested in the resource utilization around that time.

A limit violation from last evening normally does not explain an error from this afternoon.

4. Check which limit was reached #

Now comes the most important step: determine, which resource has actually reached its limit.

Depending on the CloudLinux configuration, for example, the following values may be relevant:

Resource	Meaning
CPU	available computing power
Physical Memory	Memory of the account processes
I/O	Input/output data rate
IOPS	Number of input/output operations
Entry Processes	simultaneously occurring or processed procedures
Number of Processes	Total number of running processes of the account

Which measure makes sense depends largely on, which of these limits is affected.

5. Check faults or limit events #

Pay special attention in the CloudLinux evaluation to so-called Faults or documented limit events.

A high value alone does not automatically mean that the limit has been exceeded or reached.

Therefore, the following is important for the diagnosis:

Which limit?
↓
When reached?
↓
How often?
↓
What was running at that time?

Practical Tip: A fault at the exact same time as your website problem is much more meaningful than any random high load several hours beforehand.

CPU limit reached #

When the CPU limit is reached, your hosting account requires the processing power available to it in full at that time.

CloudLinux can limit further CPU usage accordingly. As a result, processes may take longer.

Typical causes can be:

• many dynamic website requests
• complex PHP processes
• inefficient plugins
• extensive database operations
• Imports or exports
• Cron jobs
• Backup or maintenance processes
• Bots or an unusually high number of requests

CPU limit reached only briefly #

A single short CPU spike does not necessarily have to represent a problem.

For example, if you are currently running a large import, the CPU usage can temporarily increase significantly.

It gets more interesting when:

• the CPU limit is regularly reached
• the website is getting slow at the same time
• the situation occurs without a manually started task
• the behavior is reproducible

CPU limit regularly at the same time #

If, for example, the CPU reaches its limit at around the same time every day, check scheduled tasks.

Typical candidates are:

• Cron jobs
• Import
• Export
• Synchronizations
• Maintenance tasks
• Application backups

We explain how to investigate faulty or resource-intensive cron jobs at Cron job not working: Causes and solutions.

Start multiple cron jobs simultaneously #

When multiple resource-intensive tasks start at the same time, their resource requirements can add up.

Example:

02:00 → Product import
02:00 → Data synchronization
02:00 → Export
02:00 → Maintenance process

If the applications allow it, it can be useful to stagger such tasks over time.

However, do not change any cron jobs specified by an application without knowing their function.

Physical Memory Limit reached #

If the CloudLinux limit for Physical Memory is reached, the account's running processes are using too much memory within the available resource limit.

Typical causes may include, for example:

• many simultaneously running PHP processes
• memory-intensive imports
• Image processing
• extensive applications
• multiple parallel background processes
• faulty or inefficient application code

Physical Memory is not the PHP Memory Limit #

These two values are often confused.

The PHPmemory_limit and the CloudLinux limit for Physical Memory operate on different levels.

Simplified:

PHP memory_limit
→ maximum memory limit of a PHP process

CloudLinux Physical Memory
→ memory consumption of account processes within the LVE

Therefore, if the CloudLinux memory limit is reached, you should not simply increasing the PHP memory limit.

We explain how PHP limits work at Set PHP memory limit, upload size, and execution time.

Attention: A higher PHP memory limit does not automatically provide your hosting account with more CloudLinux memory.

„Allowed memory size exhausted“ is a different error #

If a message like the following appears in the error log:

Allowed memory size of ... bytes exhausted

appears, the PHP memory limit of a PHP process has been reached.

This is technically to be distinguished from a CloudLinux physical memory limit.

Check the specific error message before changing any settings.

Entry-Process-Limit reached #

Entry Processes or rather EP describe simplified processes entering or being processed in the CloudLinux LVE environment simultaneously.

The EP limit can become particularly relevant when there are many dynamic requests to be processed simultaneously.

If this limit is reached, additional requests cannot be processed normally.

In this context, in particular, a:

508 Resource Limit Is Reached

occur.

Entry processes are not your visitor count #

An EP limit of, for example, a specific value does not mean that only a corresponding number of people can visit your website at the same time.

Visitors and entry processes are different metrics.

Among other things, the crucial factor is how long dynamic requests are processed.

Simplified:

fast request
→ process completes quickly
→ resource becomes available again

slow request
→ process remains active longer
→ more concurrent processes can accumulate

Therefore, a slow application can strain the EP limit more heavily even with comparatively moderate traffic.

What can cause many entry processes? #

Possible causes include, for example:

• many simultaneous dynamic requests
• slow PHP processing
• slow database operations
• uncached dynamic pages
• Bots or automated access
• long-running application processes

Therefore, with WordPress or WooCommerce, not only the number of visitors is relevant, but also how efficiently individual requests are processed.

Number-of-Processes-Limit reached #

CloudLinux can additionally limit the total number of processes for a hosting account.

This value is often used as NPROC or rather Number of Processes referred to as.

Unlike entry processes, NPROC does not only consider web processes occurring simultaneously.

Other running processes of the account may also be relevant.

Examine many processes #

If the process limit is regularly reached, check in particular:

• concurrently running cron jobs
• long-running PHP processes
• Background tasks
• Import and export processes
• multiple applications within the same hosting account

Even an old test installation can run background tasks, even though it is no longer actively used.

I/O limit reached #

The I/O limit affects the speed at which processes can read or write data.

If the available I/O performance is fully utilized, dependent processes may slow down.

Typical triggers can be:

• large file operations
• Backups
• Extracting large archives
• extensive imports
• many write operations
• Cache generation

Distinguish between I/O limit and full storage space #

An I/O limit does not mean that your hosting storage is full.

I/O limit
→ Speed of file operations limited

Storage space full
→ No or insufficient space for additional data

You can check the actual memory consumption under Check disk space and bandwidth in cPanel.

IOPS limit reached #

If additionally in your CloudLinux evaluation IOPS displayed, this value describes the number of input/output operations per second.

Many small file operations can therefore consume an IOPS limit, even if the total amount of data transferred does not appear exceptionally large.

Which resource was reached? #

The following overview helps with the initial classification:

Limit	Typical initial inspection points
CPU	PHP, Plugins, Cronjobs, Imports, Traffic
Physical Memory	memory-intensive and parallel processes
Entry Processes	simultaneous or slow dynamic queries
Number of Processes	Background processes, cron jobs, parallel tasks
I/O	Backups, file operations, archives, imports
IOPS	very many individual file operations

Check what was running at the time of the error #

After identifying the affected limit, you should find out which activity took place at the same time.

Check, for example:

• Was an import performed?
• Did a cron job run?
• Was a backup created?
• Were there an unusual number of visitors?
• Were bots active?
• Has WordPress just been updated?
• Was a synchronization running?
• Was a large archive processed?

First, this connection between Limit + Time + Activity leads to a reliable diagnosis.

7. Check cPanel Error Log at the same time #

If the website simultaneously shows PHP or server errors, also open:

Measured values → Errors

Check there whether a matching error message was logged at the same time.

We explain how to read these entries at Read cPanel Error Log and find website errors.

CloudLinux limits and PHP errors can occur together #

A resource issue and an application error are not mutually exclusive.

For example, a faulty process can:

run unusually long
        ↓
consume a lot of CPU or memory
        ↓
reach CloudLinux limit

In this case, the resource limit is a consequence of the actual application problem.

Investigate WordPress as a cause #

In WordPress, plugins, themes, and background tasks can have a significant impact on resource consumption.

If the problem started immediately after a change, check in particular:

• newly installed plugin
• Plugin update
• Theme Update
• WordPress update
• new import function
• Backup plugin
• Security or statistics plugin
• custom code

We explain how to systematically investigate plugin and theme conflicts at Identify and resolve WordPress plugin and theme conflicts.

Consider WP-Cron and background tasks #

WordPress uses its own scheduled events for various background tasks.

Plugins can use this to, for example:

• Process emails
• Synchronize data
• Fetch feeds
• Create reports
• Clean data
• Run updates or other maintenance tasks

Therefore, a resource-intensive background task can occur even when you are not currently doing anything in the WordPress backend yourself.

Give special consideration to WooCommerce #

WooCommerce processes numerous dynamic operations and background tasks.

This may include, for example:

• Cart
• Checkout
• Customer account
• Orders
• Product imports
• Synchronizations
• scheduled actions of extensions

Therefore, in an online shop, you should check precisely which task was being executed at the time of the resource event.

Consider WordPress Action Scheduler #

WooCommerce and numerous WordPress extensions use the Action Scheduler for background tasks.

If a large number of pending or failing tasks have accumulated, this can contribute to recurring background activity.

If your resource problem occurs regularly, the queue of scheduled tasks within the application in question can therefore also be relevant.

Check for bots and crawlers as a cause #

Automated requests can cause significant resource consumption, especially when many dynamic URLs are accessed.

A bot doesn't necessarily have to be a malicious attacker.

Also:

• Search engines
• SEO crawler
• Monitoring services
• Price or content crawler
• automated scanners

can generate numerous requests.

Compare access statistics with the resource event #

If a limit coincides with unusually high traffic, you can additionally use the cPanel tools under Measurements use.

Depending on the evaluation, visitor, bandwidth, raw access, and statistical data, among others, are available there.

This allows you to better assess whether a peak load coincides with increased data traffic.

Traffic is not automatically the cause #

A resource limit during high traffic does not necessarily mean that the visitor count is exclusively the problem.

If individual dynamic pages are processed very slowly, even moderate traffic can lead to many simultaneously running processes.

Therefore, the efficiency of the application should always be examined as well.

Check caching #

For dynamic websites, appropriate caching can significantly reduce the number of PHP and database operations for recurring page views.

CURIAWEB provides AccelerateWP, a WordPress-oriented optimization solution.

You can find more information at AccelerateWP in cPanel explained.

Do not install multiple cache systems on top of each other #

When a resource limit is reached, a common erroneous reaction is to install multiple performance plugins at the same time.

This can:

• cause conflicts
• Manage cache contents inconsistently
• complicate troubleshooting
• impair dynamic functions

Therefore, use controlled optimization and check the result after each change.

Caching doesn't help with every cause #

Caching can be particularly helpful with repeated frontend calls.

However, it does not automatically solve, for example:

• faulty cron jobs
• resource-intensive imports
• Backend processes
• certain WooCommerce tasks
• faulty application code
• unusually large database operations

The cause must therefore continue to be identified.

Check PHP version #

A suitable PHP version supported by the application can be relevant for performance and stability.

At CURIAWEB, you generally manage the PHP version of your domain via the MultiPHP Manager.

However, do not blindly change the PHP version just because of a resource error.

Check first which versions your website, plugins, and themes support.

Check PHP extensions #

If error messages regarding missing PHP functions or classes occur at the same time, a required PHP extension may additionally be relevant.

We explain the procedure under Enabling and Managing PHP Extensions in cPanel.

Do not confuse PHP limits with CloudLinux limits #

PHP settings such as:

memory_limit
max_execution_time
upload_max_filesize
post_max_size

are no CloudLinux limits.

For example, if CloudLinux reports a CPU or Entry Process limit, this issue will not be resolved by you upload_max_filesize or memory_limit increase.

Check storage space #

A full hosting storage is also not a CloudLinux CPU limit.

If you experience writing, updating, or email problems at the same time, you should also check the available disk space.

You can find the procedure under Check disk space and bandwidth in cPanel.

Consider multiple websites in the account #

When multiple websites are operated within the same hosting account, they share the resources of that account.

This means:

Website A
Website B
Website C
Cron jobs
Background processes
        ↓
Shared account resources

Therefore, the resource problem does not necessarily have to be caused by the domain where you first saw the error message.

Don't forget old test installations #

An old WordPress test site can still be accessed by bots and execute background tasks.

Therefore, even installations that are no longer actively used can consume resources.

Check with recurring problems which applications are actually still present in the hosting account.

Staging websites can also execute processes #

Technically speaking, a staging copy is just another website.

If WordPress, plugins, cron jobs, or other background processes are active there, they can also use resources.

Therefore, also consider test and staging environments.

Critically review backup plugins #

Depending on the configuration, WordPress backup plugins can generate large amounts of data:

• read
• compress
• write
• transfer

This can affect CPU, I/O, memory, and process runtimes.

If resource issues occur regularly during a plugin backup, you should check its schedule and configuration.

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

Example:

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.

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

Examples:

• one-time large 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.

Check:

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
• whether caching is used sensibly
• 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.

Examples:

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

Check:

• Changelog und Systemanforderungen
• PHP compatibility
• 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 and Themes
• required PHP extensions
• 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 extensions
• Cron jobs
• Cache configuration
• alte absolute Pfade
• Application error
• 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 #

If you simultaneously:

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.

Example:

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. Open Metrics → Resource Usage.
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. Change only one possible cause at a time.
13. Teste anschließend erneut.
14. Vergleiche die CloudLinux-Werte vor und nach der Änderung.

Was du nicht tun solltest #

Avoid in particular:

• PHP Memory Limit ohne Diagnose extrem erhöhen
• mehrere Cache-Plugins gleichzeitig installieren
• Switch PHP versions randomly
• 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

Basic rule: 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.

Possible causes include, for example:

• PHP error
• Datenbankprobleme
• external services
• DNS
• SSL
• Plugin- oder Theme-Fehler
• Browser- beziehungsweise Frontend-Probleme

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

When should you contact CURIAWEB support? #

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.

Particularly helpful are:

• affected domain
• betroffene URL oder Funktion
• Date and exact time
• visible error message
• betroffenes CloudLinux-Limit
• angezeigte Faults beziehungsweise Limit-Ereignisse
• Häufigkeit des Problems
• recent changes
• running cron jobs, imports, or background tasks
• relevant error log entries

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

Summary #

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 Metrics → Resource Usage 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.

The most important rule is: 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.