Błąd 508 Resource Limit Is Reached oznacza przekroczenie limitu zasobów konta hostingu. Skąd się bierze, jak znaleźć przyczynę w logach i jak go naprawić.
Autor: McProdukt · Opublikowano: · Aktualizacja:
Błąd 508 Resource Limit Is Reached oznacza, że Twoja strona przekroczyła limit zasobów konta hostingowego - konkretnie limit żądań do PHP obsługiwanych w tej samej chwili. Serwer odrzuca wtedy kolejne żądania, żeby jedna strona nie spowolniła pozostałych kont. Typowe przyczyny to boty, ataki na logowanie, ciężkie wtyczki i WP-Cron. Poniżej wyjaśniamy, skąd bierze się ten błąd, jak znaleźć jego przyczynę w logach i jak go naprawić.
Ten komunikat zwracają serwery z systemem CloudLinux OS, który zamyka każde konto hostingowe w osobnym środowisku z limitami zasobów, zwanym LVE. Dzięki temu jedna przeciążona strona nie zajmie całego procesora, pamięci ani wszystkich procesów serwera WWW. Błąd 508 pojawia się, gdy strona przekroczy limit tzw. procesów wejściowych (entry processes, EP), czyli żądań obsługiwanych w tej samej chwili.
Liczba procesów wejściowych to nie liczba odwiedzających. Według dokumentacji CloudLinux proces „wchodzi" do LVE przy każdym nowym żądaniu HTTP do skryptu PHP lub CGI i zajmuje miejsce, dopóki się nie zakończy. Obrazki, pliki CSS i JavaScript nie uruchamiają PHP, więc nie liczą się do tego limitu. Dlatego nawet przy niewielkim ruchu strona może dostać błąd 508, jeśli żądania do PHP trwają długo albo przychodzą seriami.
CloudLinux ogranicza kilka zasobów naraz, a tylko jeden z nich kończy się błędem 508. Pozostałe objawiają się inaczej:
| Limit | Co ogranicza | Co się dzieje po przekroczeniu |
|---|---|---|
| EP (entry processes) | liczbę jednoczesnych żądań do PHP i CGI | błąd 508 Resource Limit Is Reached |
| SPEED (procesor) | moc procesora dostępną dla konta | strona działa, ale wolniej |
| PMEM (pamięć) | pamięć fizyczną procesów konta | część procesów zostaje zamknięta, pojawiają się błędy 500 i 503 |
| NPROC (procesy) | liczbę wszystkich procesów konta | nowe procesy nie startują, możliwe błędy 500 lub 503 |
| IO i IOPS | przepustowość dysku i liczbę operacji na sekundę | operacje dyskowe zwalniają albo czekają do następnej sekundy |
Konkretne wartości limitów zależą od dostawcy i pakietu. Co oznaczają inne ograniczenia, np. inody, wyjaśniamy w tekście limity hostingu: inody, procesy, pamięć, a pozostałe kody błędów - w poradniku o błędach HTTP 403, 404, 500, 502 i 503.
wp-login.php i xmlrpc.php. Dokumentacja WordPressa zwraca uwagę, że nawet nieudane ataki potrafią zalać stronę żądaniami, a xmlrpc.php jest częstym celem.wp-login.php, xmlrpc.php, admin-ajax.php, wp-cron.php czy stron z parametrami filtrów.Jeśli masz dostęp do terminala (SSH), adresy IP z największą liczbą żądań wyświetlisz poleceniem (zamień access.log na nazwę pliku z logiem swojej domeny):
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20a najczęstsze user-agenty - poleceniem:
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20Najpierw usuń przyczynę - boty, ataki, ciężkie zadania - a dopiero potem oceniaj, czy potrzebujesz więcej zasobów. Poniżej kolejne kroki, od najprostszych.
Strona podana z cache nie uruchamia PHP, więc nie zajmuje procesu wejściowego. To pierwszy krok przy każdym skoku ruchu - zasadę działania opisujemy w tekście cache - co to jest i jak przyspiesza stronę.
Boty, które respektują robots.txt, zatrzymasz wpisem Disallow dla ich nazwy. Nie blokuj Googlebota ani Bingbota, bo stracisz widoczność w wyszukiwarkach. Przy Googlebocie nie pomoże też dyrektywa crawl-delay - Google jej nie obsługuje.
Boty, które ignorują robots.txt, zablokuj regułą w pliku .htaccess. Serwer OpenLiteSpeed, na którym działa hosting McProdukt, wykonuje z .htaccess reguły przepisywania adresów (RewriteRule), ale nie dyrektywy dostępu, więc Deny from, Allow from czy Require nie zadziałają. Blokadę zapisz tak:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (NazwaBota1|NazwaBota2) [NC]
RewriteRule .* - [F,L]W miejsce NazwaBota1 i NazwaBota2 wpisz charakterystyczne fragmenty user-agenta z Twoich logów - serwer odrzuci takie żądania, zanim trafią do PHP. Więcej przykładów reguł znajdziesz w poradniku .htaccess w praktyce.
Dokumentacja WordPressa zaleca wprost: jeśli nie korzystasz z XML-RPC, wyłącz go. Na OpenLiteSpeed zrobisz to regułą:
RewriteEngine On
RewriteRule ^xmlrpc\.php$ - [F,L]Uważaj, bo z XML-RPC korzystają m.in. Jetpack i aplikacje mobilne - wtedy zamiast blokady ogranicz liczbę żądań. Konta administratorów zabezpiecz silnymi hasłami i logowaniem dwuskładnikowym. Wtyczki blokujące ataki też działają w PHP i zużywają zasoby, dlatego lepiej, gdy ataki zatrzymuje już serwer: na hostingu McProdukt firewall blokuje ataki na hasła, a ruch filtruje WAF ModSecurity z regułami OWASP CRS.
Dopisz w pliku wp-config.php linię:
define( 'DISABLE_WP_CRON', true );a w panelu hostingu ustaw zadanie cron, które co kilkanaście minut wywoła wp-cron.php. Zadania przestaną startować przy wejściach odwiedzających i zaczną działać w stałym rytmie. Krok po kroku pokazujemy to w tekście WP-Cron - jak działa i jak zastąpić go prawdziwym cronem.
Wyłącz nieużywane wtyczki, a te, które najbardziej spowalniają stronę, zamień na lżejsze. Importy, eksporty i regenerację miniatur uruchamiaj poza godzinami ruchu i dziel na mniejsze partie.
Jeśli ruch jest prawdziwy, strona ma cache, a błąd wciąż wraca w szczytach, potrzebujesz więcej zasobów: większego pakietu albo serwera VPS. Porównaj pakiety w cenniku hostingu, a jeśli kusi Cię oferta „bez limitu", sprawdź najpierw, co naprawdę oznacza hosting bez limitu.
Zwykle tak - gdy liczba jednoczesnych żądań spadnie poniżej limitu, strona znów działa. Jeśli błąd wraca regularnie, jego przyczyna (bot, atak, wtyczka, cron) nadal działa i trzeba ją usunąć.
Na serwerach z CloudLinux 508 oznacza przekroczenie limitu jednoczesnych żądań do PHP. Błąd 503 może pojawić się m.in. po przekroczeniu limitu pamięci lub liczby procesów, ale też z innych przyczyn po stronie serwera.
Tak. Liczy się liczba jednoczesnych żądań do PHP, a nie liczba odwiedzających. Mała strona bez cache, atakowana przez boty albo z ciężkim zadaniem cron może przekroczyć limit przy niewielkim ruchu.
Tylko wtedy, gdy przyczyną jest prawdziwy ruch. Jeśli stronę obciążają boty, ataki albo źle ustawiony cron, większy pakiet jedynie odsunie problem w czasie.
Na hostingu z CloudLinux zajrzyj do statystyk zużycia zasobów w panelu (sekcja Resource Usage) - zobaczysz wykresy i liczbę przekroczeń poszczególnych limitów. Jeśli panel ich nie pokazuje, poproś wsparcie o dane z godziny wystąpienia błędu.
Wszystkie poradniki z kategorii: Szybkość i wydajność