Strona działała prawidłowo, a po chwili zamiast jej zawartości pojawił się komunikat „508 Resource Limit Is Reached”? Taka sytuacja nie musi oznaczać awarii serwera ani trwałego uszkodzenia witryny. Najczęściej informuje o tym, że konto hostingowe chwilowo wykorzystało maksymalną ilość przydzielonych zasobów i nie może obsłużyć kolejnego żądania.
Błąd 508 może pojawić się zarówno podczas nagłego wzrostu ruchu, jak i wtedy, gdy pojedynczy skrypt, wtyczka, zadanie cykliczne lub zapytanie do bazy danych działa zbyt długo. Dlatego samo odświeżenie strony nie wystarcza do znalezienia przyczyny. Potrzebna jest analiza wykorzystania zasobów, procesów, logów oraz aktywności aplikacji.
Co oznacza błąd 508 i dlaczego pojawia się na hostingu?
Na hostingu wykorzystującym CloudLinux błąd 508 najczęściej oznacza przekroczenie limitu procesów wejściowych EP, określanych również jako Entry Processes. Limit ten kontroluje liczbę równoczesnych wejść do odizolowanego środowiska konta podczas obsługi żądań związanych między innymi ze skryptami PHP lub CGI.
Jeżeli wszystkie dostępne procesy wejściowe są zajęte, następne żądania nie mogą zostać od razu obsłużone. Użytkownik może wówczas zobaczyć komunikat „508 Resource Limit Is Reached”. Po zakończeniu części procesów dostępne miejsca zostają zwolnione, dlatego problem często znika po kilku sekundach lub minutach.
Limity stosowane na hostingu współdzielonym nie są wyłącznie ograniczeniem. Pełnią również funkcję ochronną. Dzięki odizolowaniu kont jedna przeciążona witryna nie powinna zużyć wszystkich zasobów serwera i spowodować niedostępności stron innych klientów.
Do typowych sytuacji prowadzących do błędu należą:
- gwałtowny wzrost liczby użytkowników;
- intensywna aktywność robotów i skanerów;
- uruchomienie importu, eksportu lub kopii zapasowej;
- wolno działające zapytania do bazy danych;
- błędnie skonfigurowane zadania cykliczne;
- nieoptymalna wtyczka albo skrypt;
- przeciążenie zewnętrznego API, na którego odpowiedź czeka aplikacja.
Warto przy tym odróżnić komunikat CloudLinux od standardowego kodu HTTP 508 „Loop Detected”. Ten drugi dotyczy operacji WebDAV przerwanej z powodu wykrycia nieskończonej pętli. Numer statusu jest taki sam, ale jego rzeczywiste znaczenie wynika z treści komunikatu oraz konfiguracji serwera.
Które limity zasobów serwera mogą prowadzić do błędu 508?
Bezpośrednią przyczyną komunikatu 508 w CloudLinux jest zazwyczaj osiągnięcie limitu EP. Pozostałe ograniczenia mogą jednak pośrednio zwiększyć prawdopodobieństwo jego wystąpienia. Gdy aplikacja otrzymuje mniej czasu procesora albo wolniej odczytuje dane z dysku, każde żądanie trwa dłużej i później zwalnia zajmowany proces wejściowy.
Najważniejsze parametry, które warto sprawdzić, to:
- EP, czyli Entry Processes – liczba jednoczesnych wejść do środowiska konta podczas obsługi żądań. Po osiągnięciu limitu kolejne żądania mogą otrzymać odpowiedź 508.
- CPU – dostępna moc obliczeniowa. Długotrwałe wykorzystanie limitu spowalnia wykonywanie PHP, przez co żądania pozostają aktywne przez dłuższy czas.
- IO – przepustowość operacji dyskowych. Ma znaczenie podczas odczytywania dużej liczby plików, zapisywania cache, generowania kopii czy przetwarzania danych.
- IOPS – liczba operacji odczytu i zapisu wykonywanych w ciągu sekundy przez procesy objęte limitem konta. Niski limit jest szczególnie odczuwalny podczas pracy na wielu niewielkich plikach, intensywnego zapisywania pamięci podręcznej, rozpakowywania archiwów lub generowania dużej liczby plików. Obciążenie MySQL lub MariaDB należy analizować osobno, ponieważ zależnie od konfiguracji hostingu może być ono mierzone i ograniczane przez odrębny mechanizm, na przykład MySQL Governor.
- PMEM – ilość pamięci fizycznej dostępnej dla procesów konta.
- NPROC – maksymalna liczba procesów i wątków działających w obrębie środowiska.
Przekroczenie pamięci lub liczby procesów częściej prowadzi do błędów 500 albo 503 niż do komunikatu 508. Nie należy więc zakładać, że każde naruszenie limitu zasobów daje ten sam kod odpowiedzi.
W panelu hostingowym warto porównać nie tylko aktualne zużycie, lecz także wartości oznaczone jako „faults”. Pokazują one, ile razy konkretny limit został faktycznie osiągnięty. Krótki skok widoczny na wykresie może nie mieć znaczenia, jeżeli nie spowodował naruszenia limitu. Powtarzające się faulty EP, CPU lub IO są już wyraźnym sygnałem, że konto wymaga analizy.
Jak zdiagnozować proces lub usługę przeciążającą konto hostingowe?
Skuteczna diagnoza zaczyna się od ustalenia dokładnego czasu wystąpienia błędu. Dzięki temu można zestawić incydent z wykresami zasobów, logami dostępu, zadaniami cyklicznymi oraz operacjami wykonywanymi w panelu administracyjnym strony.
Pierwszym miejscem kontroli powinna być sekcja dotycząca wykorzystania zasobów, dostępna w wielu panelach hostingowych jako „Resource Usage” lub pod podobną nazwą. Należy sprawdzić:
- który parametr osiągnął ustawiony limit;
- czy problem dotyczył pojedynczego skoku, czy powtarzał się przez dłuższy czas;
- o której godzinie pojawiły się naruszenia;
- czy wzrost EP wystąpił razem ze wzrostem CPU, IO albo liczby procesów;
- czy podobne zdarzenia pojawiają się o stałych porach.
Jeżeli hosting udostępnia migawki procesów, warto sprawdzić komendy, identyfikatory PID oraz wykorzystanie procesora i pamięci. Migawka może również zawierać informacje o aktywnych zapytaniach HTTP i operacjach wykonywanych w bazie danych. Pozwala to połączyć przekroczenie limitu z konkretnym adresem URL, skryptem albo zapytaniem SQL.
Kolejnym źródłem wiedzy są logi dostępu. Można w nich sprawdzić, czy w czasie wystąpienia błędu jeden adres IP nie wykonywał setek powtarzalnych żądań albo czy duża część ruchu nie skupiała się na kosztownym adresie, takim jak wyszukiwarka, filtr produktów, endpoint API, panel logowania czy koszyk.
Logi błędów PHP i serwera mogą natomiast ujawnić:
- przekroczenie czasu wykonywania skryptu;
- problemy z pamięcią;
- nieudane połączenia z bazą danych;
- wielokrotnie ponawiane zadania;
- błędy komunikacji z usługą zewnętrzną;
- pętlę przekierowań albo powtarzające się wywołania funkcji.
Warto porównać czas błędu również z harmonogramem kopii zapasowych, importów, eksportów, skanów bezpieczeństwa i zadań cron. Jeżeli przeciążenie występuje codziennie o tej samej godzinie, przyczyny należy szukać raczej w automatycznym procesie niż w zachowaniu zwykłych użytkowników.
Jak wzrost ruchu i aktywność botów wpływają na zużycie zasobów?
O obciążeniu hostingu nie decyduje wyłącznie liczba odsłon. Równie ważne są równoczesność żądań i koszt wygenerowania każdej odpowiedzi. Tysiąc wejść na statyczny plik może zużyć mniej zasobów niż kilkadziesiąt równoczesnych wywołań rozbudowanego filtra produktów, raportu lub wyszukiwarki.
Nagły wzrost zainteresowania ofertą powoduje większą liczbę uruchomień PHP, zapytań do bazy danych i operacji dyskowych. Jeżeli strona nie korzysta z odpowiednio skonfigurowanej pamięci podręcznej, niemal każde wejście może wymagać ponownego wygenerowania całego widoku. Procesy pozostają wtedy zajęte dłużej, a limit EP szybciej się wyczerpuje.
Podobny efekt wywołują boty. Nie każdy ruch automatyczny jest jednak szkodliwy. Roboty wyszukiwarek pomagają indeksować treści, natomiast skanery bezpieczeństwa, scrapery, automatyczne próby logowania czy agresywne narzędzia monitorujące mogą generować dużą liczbę kosztownych żądań.
Szczególnie obciążające bywają odwołania do:
- formularzy logowania;
- wyszukiwarek wewnętrznych;
- filtrów i sortowania produktów;
- dynamicznych adresów API;
- koszyka i procesu składania zamówienia;
- nieistniejących podstron obsługiwanych przez system CMS;
- adresów omijających pełny cache strony.
Reakcja nie powinna polegać na bezwarunkowym blokowaniu całego ruchu botów. Lepszym rozwiązaniem jest zastosowanie zapory aplikacyjnej, ograniczenia częstotliwości żądań oraz reguł chroniących szczególnie kosztowne ścieżki. Progi powinny wynikać z rzeczywistego profilu ruchu, aby zabezpieczenia nie blokowały klientów podczas legalnego wzrostu zainteresowania.
Pomocne może być również użycie sieci CDN. Statyczne zasoby, takie jak obrazy, arkusze stylów czy pliki JavaScript, są wówczas dostarczane z infrastruktury pośredniczącej, co zmniejsza liczbę żądań kierowanych bezpośrednio do hostingu. CDN nie zastępuje jednak optymalizacji PHP, bazy danych i dynamicznych elementów serwisu.
Wpływ wtyczek, skryptów, systemu CMS i bazy danych na obciążenie hostingu
Każdy dynamiczny widok może uruchamiać kod PHP, wykonywać zapytania SQL, odczytywać pliki oraz komunikować się z zewnętrznymi usługami. Im więcej operacji trzeba przeprowadzić przed wyświetleniem strony, tym dłużej zajęte są zasoby konta.
Problemy często zaczynają się po instalacji nowej wtyczki, zmianie motywu albo aktualizacji systemu CMS. Nie oznacza to automatycznie, że aktualizacja jest wadliwa. Może jednak ujawnić konflikt rozszerzeń, zmianę sposobu wykonywania zapytań albo większe zapotrzebowanie na zasoby.
Źródłem przeciążenia może być rozszerzenie, które:
- wykonuje dziesiątki dodatkowych zapytań przy każdej odsłonie;
- odpytuje wolne zewnętrzne API;
- generuje obrazy w momencie wejścia użytkownika;
- uruchamia skan całej witryny;
- przelicza statystyki w czasie rzeczywistym;
- tworzy wiele równoległych zadań;
- zapisuje nadmierną liczbę danych w bazie.
W WordPressie uwagę warto zwrócić również na WP-Cron. Mechanizm sprawdza kolejkę zaplanowanych zdarzeń podczas wizyt na stronie. Przy dużym ruchu, błędnej konfiguracji lub nagromadzeniu zaległych zadań może generować dodatkowe obciążenie. W rozbudowanych serwisach lepszym rozwiązaniem bywa wyłączenie automatycznego uruchamiania WP-Cron podczas odsłon i zastąpienie go systemowym harmonogramem wykonywanym w kontrolowanych odstępach.
Równie istotny jest stan bazy danych. Rozrośnięte tabele, brak właściwych indeksów oraz zapytania przetwarzające zbyt duże zbiory danych wydłużają czas odpowiedzi. W rezultacie proces PHP dłużej oczekuje na wynik, a liczba zajętych procesów wejściowych rośnie.
Cache stron może znacząco ograniczyć liczbę uruchomień PHP i zapytań do bazy dla publicznych, powtarzalnych widoków. Nie rozwiązuje jednak każdego problemu. Panel administracyjny, koszyk, konto klienta, wyszukiwarka, filtry oraz spersonalizowane treści zazwyczaj wymagają dynamicznej obsługi.
Testowanie wpływu wtyczek i skryptów najlepiej przeprowadzać na środowisku testowym. Wyłączanie rozszerzeń bezpośrednio na działającej stronie może przerwać sprzedaż, formularze lub inne istotne funkcje. Na kopii serwisu można bezpiecznie porównać czas wykonywania, liczbę zapytań, wywołania zewnętrzne i obciążenie po każdej zmianie.
Jak usunąć błąd 508 i zapobiegać ponownemu przekroczeniu limitów?
Pierwszym celem jest przywrócenie dostępności strony, ale samo chwilowe zmniejszenie obciążenia nie usuwa przyczyny. Jeżeli proces, bot albo źle skonfigurowane zadanie nadal działa, błąd 508 szybko powróci.
Działania doraźne mogą obejmować:
- zatrzymanie importu, eksportu, kopii lub innego ciężkiego procesu;
- tymczasowe wyłączenie wadliwej wtyczki albo skryptu;
- ograniczenie agresywnego ruchu automatycznego;
- przesunięcie zadań cyklicznych poza godziny największego ruchu;
- sprawdzenie, czy kilka ciężkich operacji nie uruchamia się równolegle;
- kontakt z administratorem hostingu, jeżeli panel nie udostępnia wystarczających danych.
Po ustabilizowaniu strony należy przejść do optymalizacji. Najczęściej obejmuje ona uruchomienie cache stron i obiektów, ograniczenie liczby zapytań do bazy, optymalizację tabel, redukcję zbędnych wywołań zewnętrznych oraz poprawę działania zadań cron.
Warto także:
- aktualizować system CMS, motyw i rozszerzenia;
- usuwać nieużywane wtyczki zamiast jedynie je wyłączać;
- optymalizować obrazy przed umieszczeniem ich na stronie;
- rozłożyć ciężkie zadania w czasie;
- kontrolować częstotliwość skanów i kopii;
- zabezpieczyć formularze oraz panel logowania;
- obserwować czas odpowiedzi i liczbę faultów po każdej zmianie.
Masowe wyczyszczenie pamięci podręcznej nie zawsze pomaga. Po usunięciu cache strona musi ponownie wygenerować wszystkie treści, co może chwilowo jeszcze bardziej zwiększyć zużycie zasobów. Operację warto wykonywać tylko wtedy, gdy istnieje podejrzenie uszkodzenia cache albo po zmianach, które rzeczywiście wymagają jego odświeżenia.
Zwiększenie limitów może być uzasadnione, gdy zoptymalizowana strona obsługuje coraz większy, wartościowy ruch. Jeżeli jednak przyczyną jest wadliwy skrypt, wolna baza albo niekontrolowana aktywność botów, wyższy pakiet jedynie odsunie problem w czasie.
W Rapid DC pomagamy dobrać środowisko hostingowe do rzeczywistych wymagań strony, sklepu lub aplikacji. Analiza wykorzystania zasobów i charakteru ruchu pozwala ocenić, czy wystarczy optymalizacja obecnej konfiguracji, czy potrzebny jest pakiet z wyższymi limitami albo rozwiązanie zapewniające większą kontrolę nad zasobami.