Türkei (Türkisch)
Germany (German)
Worldwide (English)
EPGleichzeitige Web-Login-Prozesse
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
508-Fehler zeigt an, dass die CloudLinux-LVE-Schicht des cPanel-Kontos eine der CPU-, physischen Speichergrenzen, Entry-Processes, NPROC-, IO- oder IOPS-Grenzen erreicht hat. Diese Anleitung findet heraus, welche Grenze erreicht wurde und erhöht die Grenze nur, um die tatsächliche Lastursache zu lösen.
508 Resource Limit Is Reached
The website is temporarily unable to service your request
CloudLinux LVE fault detected
EPf: 24 PMf: 3 NprocF: 0CloudLinux führt jedes Hosting-Konto in einem isolierten Ressourcenbereich namens LVE aus. Wenn das Konto die definierte Grenze überschreitet, können Anfragen verlangsamt oder eine 508-Seite angezeigt werden, um andere Kunden zu schützen.
Entry Processes, gleichzeitige dynamische Anfragen, die durch Apache oder LiteSpeed-Konto eintreten, beziehen sich auf gleichzeitige dynamische Anfragen, die durch das Konto eintreten. Langsame PHP-Code oder Bot-Verkehr kann dazu führen, dass jede Anfrage lange Zeit offen bleibt und die EP-Grenze überschreitet.
PMEM ist die physische Speicherung der Prozesse des Kontos. Während PHP memory_limit eine einzelne PHP-Anfrage begrenzt, umfasst CloudLinux PMEM die gesamte physische Speicherung, die von allen Prozessen im gleichen Konto verwendet wird.
NPROC kann Webanfragen neben cron, SSH, PHP, Node.js und anderen Prozessen abdecken. In einer gesunden Konfiguration sollte der NPROC-Wert ausreichend hoch von EP sein; nur die Gleichsetzung der beiden Grenzwerte kann zu einer vorzeitigen Prozessbeendigung führen.
CPU-, IO- und IOPS-Grenzwerte verlangsamen Anfragen oft anstelle von direkt beenden. Verlangsamte Anfragen können sekundär EP- oder NPROC-Fehler verursachen.
Die Erhöhung der Obergrenze kann erforderlich sein; jedoch ermöglicht die Erhöhung der Obergrenze bei anormalen Bot-Verkehr, WP-Cron-Sturm, schlecht geschriebenen Abfragen oder Malware-Anwesenheit nur, dass das Problem mehr Ressourcen verbraucht.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Ihr Konto hat eine der von CloudLinux definierten Ressourcenlimits erreicht.
Mögliche Ursache: EP-, PMEM-, NPROC-, CPU-, IO- oder IOPS-Verbrauch.
Bedeutung: Gleichzeitige dynamische Webanforderungszahl hat die EP-Grenze erreicht
Mögliche Ursache: Bot-Traffic, langsam PHP, Remote-API, Datenbank-Wartezeit oder niedriges EP-Limit
Bedeutung: Der Gesamt-Speicherbedarf Ihres Kontos hat das PMEM-Grenzwert erreicht.
Mögliche Ursache: Zu viele PHP-Prozesse, hoher memory_limit, Erweiterungslühe oder große Import.
Bedeutung: Die Gesamtzahl der Prozesse/Threads Ihres Kontos hat das NPROC-Grenzwert erreicht.
Mögliche Ursache: Cron-Verbreitung, festgefahrene PHP-Prozesse, Shell/Node-Prozesse oder niedriger NPROC-Wert.
Bedeutung: Das Konto verbraucht kontinuierlich die definierte CPU-Kapazität.
Mögliche Ursache: Schwere PHP, schlechte Abfrage, Crawler-Bot, Cron oder Malware.
Bedeutung: Anzeigt, dass Ihr Konto seine zweite Ebene des Disk-Read-/Write-Bandbreitenlimits erreicht hat.
Mögliche Ursache: Backup für große Imports, Cache-Schreibvorgänge, E-Mail-Operationen oder starke Datenbankdateizugriffe.
Bedeutung: Die pro Sekunde limitierte Disk-Operation ist erreicht worden.
Mögliche Ursache: Viele kleine Dateien, Sitzung/Cachefiles, Antiviren-Scans oder E-Mail-Warteschlangen.
Bedeutung: Alte oder benutzerdefinierte Konfigurationen können virtuelle Speicherlimit erreicht haben.
Mögliche Ursache: Prozesse mit hoher virtueller Adressraumgröße oder alte LVE-Einstellungen.
Bedeutung: CPU/IO-Drosselung tritt auf, produziert aber möglicherweise keine Fehlergrenze.
Mögliche Ursache: Konto arbeitet seit langem in der Grenze oder es gibt eine Verzögerung in der Datenbank/Global-Server.
Bedeutung: Periodische Verkehr oder geplante Aufgabenressourcen verbrauchen den gleichen Zeitrahmen.
Mögliche Ursache: wp-cron, Backup, XML-Import, Bot-Welle oder Kampagnenverkehr.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
lveinfo --period=1h --by-fault=any --display-username --show-allEs zeigt, welcher Benutzer welche Grenzwertfehler hat.
lveinfo --user=USERNAME --period=24h --display-username --show-allUSERNAME zeigt die letzten 24 Stunden Ressourcenverwendung und Fehlerwerte des Kontos an.
lvetopÜberwacht CPU-, Speicher-, EP-, Prozess- und IO-Nutzung in Echtzeit.
lvectl list-user USERNAME
cloudlinux-limits get --username USERNAME 2>/dev/nullZeigt die derzeitigen LVE-Begrenzungen für Ihr Konto an.
ps -u USERNAME -o pid,ppid,%cpu,%mem,rss,etime,cmd --sort=-%cpu | head -n 40Listet Benutzerprozesse basierend auf CPU, RAM und langer Laufzeit.
awk '{print $1}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | head
awk '{print $7}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | headFinden Sie die IP-Adressen und URLs mit den meisten Anfragen.
crontab -u USERNAME -l
journalctl --since '2 hours ago' | grep -Ei 'CROND.*USERNAME' | tail -n 100Identifiziert Cron-Aufgaben, die während der Spitzenzeiten laufen.
ps -u USERNAME -f
find /home/USERNAME/public_html -type f -mtime -2 -name '*.php' -ls 2>/dev/null | head -n 100Zeigt unerwartete Prozesse und kürzlich geänderte PHP-Dateien an.
Die richtige Lösung besteht nicht darin, den Limit zufällig zu erhöhen, indem man die Fehlerseite betrachtet; es handelt sich um die Übereinstimmung des Fehler-Typs, der Zeit und der Last mit der URL oder dem Prozess.
Finden Sie heraus, welche der EPf, PMf, NprocF, CPUf oder IOf-Spalten zunimmt. Die Datums- und Uhrzeitinformationen sind für die nachfolgende Log-Matching erforderlich.
lveinfo --user=USERNAME --period=24h --display-username --show-allFinden Sie den Prozess, IP-Adresse und URL, die die Last während des fortgesetzten Fehlers mit iis, ps und Domain-Zugriffs-Log erstellt haben.
lvetop
ps -u USERNAME -o pid,ppid,%cpu,%mem,rss,etime,cmd --sort=-%cpu | headOptimieren oder zeitplanen Sie Grüden wie WordPress Cron, Sicherheits-Scan, XML-Import, langsamer Abfrage, Remote-API oder intensiver Bot-URL.
wp cron event list --path=/home/USERNAME/public_html 2>/dev/null | headBlockiere wiederholte Bot- oder Angriffsanfragen mit Cloudflare, WAF, ModSecurity oder Anwendungsgrenzwertbegrenzung. Betrobe den realen Besucher nicht mit einer Bulk-IP-Blockierung.
awk '{print $1}' /usr/local/apache/domlogs/ALANADI | sort | uniq -c | sort -nr | headNach der Optimierung, wenn die tatsächliche Last das aktuelle Paket überschreitet, erhöhen Sie die Grenzen basierend auf RAM und Serverkapazität, entweder auf Paket- oder Benutzerebene.
lvectl set-user USERNAME --speed=200% --pmem=2G --nproc=150 --maxEntryProcs=40 --save-all-parametersFolgen Sie dem neuen Fehler, dass nicht auftritt, die Quellkurve normalisiert und die 508-Seite nicht wiederholt.
lveinfo --user=USERNAME --period=24h --display-username --show-allAnfragen können auf eine Ressource warten, ohne CPU zu verbrauchen. Es werden Remote-API, Datenbank-Sperre, lange HTTP-Anfrage oder PHP-Sitzungssperre überprüft.
ps -u USERNAME -o pid,stat,wchan:24,etime,cmd | head -n 50Gehen Sie davon aus, dass ein einzelner schwerer Prozess oder mehrere kleine PHP-Prozesse den Speicher belegen. Beachten Sie, dass memory_limit und LVE PMEM nicht die gleiche Grenze darstellen.
ps -u USERNAME -o pid,rss,%mem,etime,cmd --sort=-rss | head -n 30Cron, Shell, Node.js oder festgefahrene PHP-Prozesse können die Gesamtzahl füllen. Der NPROC-Wert sollte im Vergleich zu EP vernünftig hoch sein.
ps -u USERNAME --no-headers | wc -l
pstree -ap USERNAME | head -n 80Bestimmen Sie die am intensivsten verwendeten IP- und URL-Adressen und wenden Sie auf Cloudflare/WAF gezielte Rate-Limits an. Verifizierte Suchmaschinen wie Googlebot blockieren Sie nicht versehentlich.
grep "$(date '+%d/%b/%Y')" /usr/local/apache/domlogs/ALANADI | awk '{print $1,$7}' | sort | uniq -c | sort -nr | headBereite den gemeinsamen Produktprozess in kleinere Abschnitte auf, verwende echte Cron, starte WP-Cron nicht bei jedem Besuch und optimiere die Abfrage/Cachestruktur.
wp cron event list --path=/home/USERNAME/public_html --fields=hook,next_run_gmt,recurrence | head -n 50zeigt an, dass das cPanel-Konto mindestens einen der von CloudLinux definierten CPU, PMEM, EP, NPROC, IO- oder IOPS-Ressourcen zugreifen hat.
In WHM LVE Manager wird der Faults-Bereich oder über SSH die EPf, PMf, NprocF- und andere Fehlerzeilen in der lveinfo-Ausgabe überprüft.
Die Anzahl der dynamischen Anfragen zum Webserverkonto gleichzeitig vom Webserver ist.
Nein. Die PHP-Einstellung memory_limit ist die Obergrenze für die verwendbare physische Speichergröße, die ein einzelnes PHP-Prozess verwenden kann. CloudLinux PMEM hingegen umfasst die Gesamtspeichergröße aller Prozesse, die einem Konto zugeordnet sind.
Wenn der echte Traffic das Paket überschreitet, kann es gelöst werden. Wenn es ein Bot, Malware oder langsames Code ist, ermöglicht es nur dem Problem, mehr Ressourcen zu konsumieren und ist vorübergehend.
Es gibt keine einzelne universelle Zahl. Sie sollte auf der Anwendungstruktur Ihres Kontos basierend und normalerweise sollte sie hoch genug sein, um größer als der EP-Wert zu sein; die Gesamtkapazität des Servers sollte ebenfalls berücksichtigt werden.
Googlebot kann bei wiederholten 508 Antworten die Durchsuchung und den Benutzererlebnis negativ beeinflussen. Der Fehler sollte während der Spitzenzeiten nicht wiederholt werden.
Wenn die nach der Optimierung geteilten Paketgrenzen überschritten werden, ist ein VPS/VDS vernünftig. Zuerst müssen Toleranz gegen Fehlertoleranz und Anwendungsdurchsatz gemessen werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.