Przekroczony limit transferu lub procesora na hostingu. Jak ustalić, co go zużywa?

Wiadomość od dostawcy hostingu o przekroczonym limicie przychodzi zwykle w najgorszym momencie: strona zwalnia, wyświetla błąd albo zostaje czasowo wyłączona, a w treści powiadomienia pada tylko ogólne stwierdzenie, że konto zużyło za dużo transferu lub mocy procesora. Nie wiadomo wtedy, czy winny jest wzrost zainteresowania ofertą, wadliwa wtyczka, natarczywy robot, czy może włamanie.

Ten tekst jest instrukcją dla osób, które prowadzą stronę firmową lub sklep na hostingu współdzielonym i chcą samodzielnie ustalić, co zużywa zasoby konta.

Po lekturze czytelnik będzie umiał odróżnić limit transferu od limitu procesora, znaleźć w panelu miejsce, w którym widać zużycie, wskazać podstronę, plik, robota albo wtyczkę odpowiedzialną za problem, wprowadzić naprawę i sprawdzić, czy przyniosła skutek. Nazwy funkcji podaję według dokumentacji panelu cPanel i systemu CloudLinux, ponieważ to zestaw często spotykany na hostingach współdzielonych. W panelach własnych dostawców te same funkcje noszą inne nazwy, ale zasada działania jest taka sama.

Po czym poznać, który limit został przekroczony?

Pod hasłem „przekroczony limit” kryją się dwie zupełnie różne sytuacje. Limit transferu dotyczy ilości danych wysłanych z serwera w okresie rozliczeniowym, najczęściej w miesiącu. Limit procesora i pozostałych zasobów dotyczy tego, ile mocy obliczeniowej, pamięci i jednoczesnych połączeń konto może zużywać w danej chwili. Naprawa w obu przypadkach wygląda inaczej, dlatego pierwszym zadaniem jest ustalenie, z którym z nich ma się do czynienia.

Najpewniejszym źródłem jest wiadomość od dostawcy oraz to, co pokazuje przeglądarka po wejściu na stronę. Objawy układają się zwykle w następujący sposób:

• strona działa przez większość miesiąca, a pod jego koniec zostaje wyłączona do pierwszego dnia kolejnego okresu rozliczeniowego – to typowy obraz wyczerpanego transferu, często z komunikatem o kodzie 509,
• strona działa, lecz w niektórych godzinach otwiera się bardzo powoli – według dokumentacji CloudLinux tak zachowuje się konto ograniczane z powodu procesora albo operacji dyskowych,
• co pewien czas pojawia się błąd 508 z opisem „Resource Limit Is Reached” – oznacza to przekroczenie liczby jednoczesnych połączeń obsługiwanych przez skrypty,
• pojawiają się błędy 500 lub 503 – tak kończy się zwykle przekroczenie limitu pamięci albo liczby procesów,
• dostawca przysyła ostrzeżenie, choć strona działa poprawnie – konto zbliża się do progu albo przekracza go krótkimi skokami.

Czym różni się limit transferu od limitu procesora i pamięci?

Transfer to suma danych, które serwer wysłał odwiedzającym, robotom i programom pocztowym. Limit jest miesięczny, więc o jego wyczerpaniu decyduje to, co działo się przez całe tygodnie, a nie w jednej chwili.

Limity procesora i pokrewnych zasobów działają odwrotnie: liczy się chwila. System CloudLinux, stosowany na wielu hostingach współdzielonych, zamyka każde konto w osobnym, odgrodzonym środowisku i pilnuje, aby jedna strona nie zabrała mocy pozostałym klientom serwera. W panelu widać kilka skrótów, które dobrze jest rozumieć:

• CPU albo SPEED – dopuszczalne obciążenie procesora, liczone w odniesieniu do jednego rdzenia,
• PMEM – pamięć operacyjna rzeczywiście zajęta przez procesy konta,
• EP, czyli „Entry Processes” – liczba żądań obsługiwanych przez skrypty w tej samej chwili, nazywana też liczbą jednoczesnych połączeń,
• NPROC – łączna liczba procesów uruchomionych na koncie,
• IO oraz IOPS – szybkość i liczba operacji odczytu i zapisu na dysku,

Ważna uwaga dotyczy parametru EP. Nie jest to liczba osób przeglądających stronę. Żądanie zajmuje miejsce tylko przez czas, w którym serwer przygotowuje odpowiedź, więc przy szybkiej stronie nawet niewielki limit wystarcza na spory ruch. Kłopot zaczyna się wtedy, gdy strona odpowiada wolno: żądania czekają w kolejce, miejsca się kończą i pojawia się błąd 508.

Wyczerpany transfer oznacza, że serwer wysyła za dużo danych, więc szuka się dużych plików i nadmiernego ruchu. Przekroczony procesor oznacza, że serwer za ciężko pracuje nad każdą odpowiedzią albo dostaje zbyt wiele żądań naraz, więc szuka się wolnych skryptów, robotów i ataków. O tym, jak czytać takie parametry jeszcze przed zakupem konta, piszę w osobnym tekście o tym, jak rozpoznać realne ograniczenia konta w ofercie hostingu.

Gdzie w panelu hostingu widać zużycie transferu?

W panelu cPanel służy do tego funkcja „Bandwidth” w grupie „Metrics”. W polskiej wersji panelu i w panelach własnych dostawców nazwa bywa przetłumaczona, najczęściej jako transfer lub przepustowość. Dokumentacja cPanel zastrzega, że funkcja jest widoczna tylko wtedy, gdy dostawca ją udostępnił, więc w razie jej braku należy poprosić o dane dział pomocy.

1. Po zalogowaniu do panelu hostingu należy odszukać grupę „Metrics” i otworzyć „Bandwidth”.
2. Na górze widoczne są wykresy „Past 24 hours”, „Past week” i „Past year”. Pierwszy pokazuje krótkie skoki ruchu w ciągu doby, drugi powtarzające się wzorce z ostatnich siedmiu dni, trzeci sumę danych z dwunastu miesięcy.
3. Niżej znajdują się miesięczne wykresy kołowe. Każdy pokazuje, jaką część transferu zużyły poszczególne usługi i domeny.
4. Kliknięcie wykresu wybranego miesiąca otwiera szczegóły, a w nich tabelę „Bandwidth by Day” z liczbą megabajtów wysłanych każdego dnia.
5. Kliknięcie konkretnego dnia w tabeli pokazuje rozkład ruchu w ciągu tej doby.

Wykresy dzielą transfer na kategorie. HTTP to ruch na stronie internetowej, FTP to przesyłanie plików, SMTP to poczta wysłana ze skrzynek na koncie, a POP3 i IMAP to poczta pobierana z serwera przez programy pocztowe. Ostatnia pozycja, „Total (all services)”, jest sumą wszystkich pozostałych.

Już samo spojrzenie na wykres kołowy rozstrzyga pierwszą wątpliwość: czy transfer zużywa strona, czy poczta. Jeżeli największy wycinek należy do SMTP, przyczyną jest wysyłka wiadomości, na przykład masowa korespondencja z dużymi załącznikami albo skrzynka, do której hasło poznał ktoś niepowołany. Jeżeli dominuje HTTP, trzeba przyjrzeć się ruchowi na stronie.

Dokumentacja wymienia też rzeczy, których ten licznik nie obejmuje: przesyłanie plików przez menedżer plików w panelu, pocztę przychodzącą z innych serwerów, ruch związany z DNS oraz aktywność sieciową zadań cron. Dostawca może przy tym liczyć transfer według własnych zasad opisanych w regulaminie. Druga wskazówka z dokumentacji: tabelę dzienną najlepiej oglądać po upływie 24-48 godzin od interesującego dnia, bo system potrzebuje czasu na przetworzenie danych.

Jak ustalić, które pliki i jacy odwiedzający zużywają transfer?

Wykres mówi, kiedy i przez którą usługę uciekają dane. Odpowiedź na pytanie „co dokładnie” dają trzy inne funkcje z tej samej grupy: „Awstats”, „Visitors” i „Raw Access”.

Statystyki AWStats: szybki przegląd miesiąca

Po otwarciu „Awstats” należy kliknąć „View” przy wybranej domenie. Program pokazuje średnie miesięczne, dzienne i godzinowe, kody odpowiedzi HTTP, przeglądarki i kraje pochodzenia ruchu. Dla szukającego przyczyny najcenniejsze są zestawienia robotów oraz najczęściej pobieranych adresów i typów plików wraz z ilością przesłanych danych. Jeden film, katalog w formacie PDF albo archiwum na czele listy oznacza, że źródło problemu jest znalezione.

Funkcja „Visitors”: ostatnie wejścia wiersz po wierszu

„Visitors” pokazuje najnowsze wpisy z dziennika serwera w postaci tabeli. Po kliknięciu ikony lupy przy domenie widać kolumny „IP”, „URL”, „Time”, „Size (bytes)”, „Referring URL” i „User Agent”. Ikona koła zębatego pozwala dołączyć kolumny „Status”, „Method” i „Protocol”. Sortowanie po rozmiarze od razu wskazuje najcięższe pliki, a pole „Search” pozwala wyszukać wszystkie żądania z jednego adresu IP lub od jednego robota.

Surowy dziennik dostępu: pełny obraz

Gdy potrzebny jest dłuższy okres, należy sięgnąć po pełny dziennik. W funkcji „Raw Access”, w części „Download Current Raw Access Logs”, wystarczy kliknąć nazwę domeny, aby pobrać spakowany plik z rozszerzeniem .gz. Po rozpakowaniu jest to zwykły plik tekstowy, w którym każdy wiersz opisuje jedno żądanie: adres IP, czas, adres pliku, kod odpowiedzi, liczbę wysłanych bajtów, stronę odsyłającą i podpis przeglądarki lub robota.

W tej samej funkcji, w części „Configure Logs”, dobrze jest zaznaczyć pole archiwizowania dzienników w katalogu domowym. Bez tego starsze wpisy znikają i przy następnym kłopocie nie będzie czego analizować. Sposób czytania takich wpisów opisuję dokładniej w tekście o tym, gdzie znaleźć dzienniki dostępu i błędów na hostingu.

Na co patrzeć w dzienniku?

W praktyce przyczyną wyczerpanego transferu jest jedna z kilku sytuacji. Każdą da się rozpoznać po charakterystycznym śladzie:

• ten sam podpis robota przy tysiącach żądań w krótkim czasie – serwis jest intensywnie przeglądany przez automat,
• wiele żądań o zdjęcia, przy których w kolumnie strony odsyłającej widnieje obca domena – ktoś wyświetla obrazy z serwera na własnej stronie,
• pojedyncze pliki o rozmiarze wielu megabajtów pobierane raz po raz – na serwerze leżą filmy, katalogi lub archiwa,
• zdjęcia o bardzo dużym rozmiarze przy zwykłych podstronach – grafiki nie zostały zmniejszone przed publikacją,
• jedna podstrona odwiedzana wielokrotnie częściej niż pozostałe – trwa kampania, treść została gdzieś udostępniona albo adres jest celem ataku.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Przejmę sprawę: przejrzę statystyki i dzienniki konta, wskażę, co dokładnie zużywa transfer lub procesor, i wprowadzę poprawki, po których strona wraca do normalnej pracy.

Gdzie sprawdzić zużycie procesora, pamięci i jednoczesnych połączeń?

Na serwerach z systemem CloudLinux w panelu cPanel dostępna jest funkcja „CPU and Concurrent Connection Usage”, opisywana w dokumentacji także jako „Resource Usage”. Ta sama wtyczka działa w panelach Plesk i DirectAdmin. Jeżeli dostawca korzysta z własnego panelu, odpowiednika należy szukać pod nazwami typu zużycie zasobów, obciążenie albo statystyki konta.

1. W grupie „Metrics” należy otworzyć „CPU and Concurrent Connection Usage”.
2. Pierwsza karta, „Dashboard”, pokazuje ogólny stan konta. Jeżeli strona była ograniczana, widać tu informację, którego zasobu dotyczyło ograniczenie.
3. Kliknięcie „Details” albo przejście na kartę „Current Usage” otwiera wykresy i tabele dla procesora, pamięci, operacji dyskowych, połączeń i procesów.
4. Filtr nad wykresami pozwala wybrać okres i jednostkę czasu: dzień, godzinę lub minutę. Dobrze jest zacząć od dłuższego okresu, a potem zawęzić widok do dnia, w którym przyszło ostrzeżenie.
5. W tabeli „Usage” należy odczytać kolumny: „A” to średnie zużycie, „L” to limit, „F” to liczba przekroczeń, w dokumentacji nazywanych „faults”.
6. Karta „Snapshot” pokazuje, co działo się na koncie dokładnie w chwili przekroczenia.

Kolumna „F” jest ważniejsza od średniej. Średnie zużycie procesora może wyglądać niewinnie, a mimo to konto wiele razy dziennie osiąga limit na kilka sekund. Wykresy mają legendę kolorów: zielony oznacza średnie zużycie, czerwony limit, a osobny wykres „Faults” zbiera przekroczenia wszystkich zasobów.

Jak czytać migawki z chwili przekroczenia?

Migawka powstaje samoczynnie, gdy konto przekracza limit. Zawiera listę działających wtedy procesów, listę zapytań do bazy danych oraz listę żądań HTTP. Na karcie „Snapshot” wybiera się datę i konkretną migawkę z listy. Dla jednego zdarzenia system tworzy ich kilka.

W liście żądań HTTP należy szukać powtarzającego się adresu. Jeżeli w każdej migawce widnieje wp-login.php albo xmlrpc.php, ktoś próbuje odgadnąć hasło. Jeżeli powtarza się admin-ajax.php, winna jest zwykle wtyczka, która stale odpytuje serwer. Jeżeli widać wp-cron.php, przyczyną są zadania okresowe. Adresy wyszukiwarki wewnętrznej, filtrów sklepu i koszyka wskazują na robota, który wędruje po nieskończonych kombinacjach parametrów.

Lista zapytań do bazy podpowiada, która tabela jest przeciążona, a nazwa tabeli zwykle wskazuje wtyczkę, która ją utworzyła.

Co najczęściej obciąża procesor na stronie z WordPressem i jak to naprawić?

Po analizie migawek przyczyna prawie zawsze mieści się w jednej z poniższych grup. Przed każdą zmianą w plikach należy wykonać kopię zapasową, a pliki konfiguracyjne edytować ostrożnie, bo jeden błędny znak potrafi wyłączyć całą stronę.

Brak pamięci podręcznej

Bez pamięci podręcznej WordPress przy każdym wejściu buduje stronę od zera: uruchamia PHP, wykonuje dziesiątki zapytań do bazy i dopiero wtedy wysyła wynik. Wtyczka pamięci podręcznej zapisuje gotową stronę i podaje ją kolejnym odwiedzającym bez angażowania procesora. To pojedyncza zmiana o największym wpływie na limity CPU i EP.

Ciężka albo wadliwa wtyczka

Jeżeli migawki wskazują na admin-ajax.php lub na zapytania do tabel konkretnego dodatku, należy go sprawdzić. Najprostsza metoda polega na wyłączaniu podejrzanych wtyczek po kolei i obserwowaniu wykresu w panelu przez kilka godzin po każdej zmianie. Na działającym sklepie lepiej robić to na kopii testowej. Szerzej opisuję to w tekście o tym, jak sprawdzić, co spowalnia WordPressa.

Zadania okresowe uruchamiane przy każdym wejściu

WordPress domyślnie sprawdza listę zadań okresowych przy wejściach na stronę. Przy dużym ruchu lub przy natarczywych robotach plik wp-cron.php jest wywoływany bardzo często. Rozwiązaniem jest wyłączenie tego mechanizmu i uruchamianie zadań o stałych porach przez panel hostingu.

1. W menedżerze plików należy otworzyć do edycji plik wp-config.php z głównego katalogu strony.
2. Przed wierszem z komentarzem informującym o końcu edycji wpisuje się: define('DISABLE_WP_CRON', true);
3. Po zachowaniu pliku należy przejść w panelu do funkcji zadań cron i utworzyć nowe zadanie, na przykład co 15 minut.
4. Jako polecenie wpisuje się wywołanie pliku zadań, z własną domeną w miejscu przykładowej: wget -q -O - https://przyklad.pl/wp-cron.php?doing_wp_cron >/dev/null 2>&1
5. Po godzinie należy sprawdzić, czy zaplanowane wpisy publikują się o czasie, a kopie zapasowe i wysyłki wiadomości nadal działają.

Dokładny opis formularza zadań znajduje się w tekście o tym, jak dodać zadanie cron w panelu hostingu. Niektórzy dostawcy wymagają innej postaci polecenia, opisanej na ich stronie pomocy.

Próby logowania i ataki na plik xmlrpc.php

Automaty zgadujące hasła potrafią wysyłać setki żądań na minutę. Każde takie żądanie uruchamia PHP i zajmuje jedno miejsce w limicie EP. Pomaga ograniczenie liczby prób logowania wtyczką zabezpieczającą, długie hasła oraz zapora dostępna u dostawcy hostingu lub w usłudze CDN.

Plik xmlrpc.php można zablokować w pliku .htaccess następującym zapisem dla serwera Apache w wersji 2.4:

<Files xmlrpc.php>
Require all denied
</Files>

Ta blokada ma skutki uboczne: przestaje działać aplikacja mobilna WordPressa oraz dodatki, które łączą się ze stroną tą drogą, między innymi Jetpack. Jeżeli firma z nich korzysta, bezpieczniej jest poprzestać na zaporze i ograniczeniu prób logowania.

Roboty wędrujące po filtrach i wyszukiwarce

Sklep z filtrami tworzy praktycznie nieskończoną liczbę adresów. Robot, który zacznie je odwiedzać, zmusza serwer do budowania tysięcy niepotrzebnych stron. W pliku robots.txt należy zablokować adresy z parametrami filtrów, sortowania i wyszukiwarki wewnętrznej, a przy okazji koszyk i panel klienta. Zbyt szeroka reguła ukryje jednak przed wyszukiwarką wartościowe podstrony, więc wymaga to precyzji.

Zainfekowana strona

Wysokie zużycie procesora w nocy, wysyłka poczty, której nikt nie zlecał, nieznane pliki PHP w katalogach z grafikami i procesy o dziwnych nazwach w migawkach to sygnały włamania. Należy wtedy zmienić wszystkie hasła, przeskanować pliki i usunąć złośliwy kod, a najlepiej odtworzyć stronę z kopii sprzed infekcji i od razu zaktualizować wszystkie składniki.

Jak zmniejszyć zużycie transferu?

Gdy analiza pokazała, że kłopotem jest ilość wysyłanych danych, naprawa polega na odchudzeniu tego, co serwer wysyła, i na odcięciu ruchu, który firmie nic nie daje.

Zdjęcia i inne ciężkie pliki

Zdjęcie wgrane prosto z aparatu lub telefonu waży wielokrotnie więcej, niż potrzeba do wyświetlenia na stronie. Należy zmniejszyć wymiary grafik do faktycznie używanych, zapisać je w oszczędnym formacie, na przykład WebP, i włączyć opóźnione wczytywanie obrazów położonych niżej na stronie.

Filmy nie powinny leżeć na hostingu współdzielonym. Jeden kilkuminutowy film odtworzony kilkaset razy potrafi zużyć miesięczny transfer małego konta. Lepiej umieścić go w serwisie wideo i osadzić na stronie. Duże katalogi i archiwa do pobrania dobrze jest przenieść do zewnętrznego magazynu plików.

Obrazy wyświetlane na cudzych stronach

Jeżeli w dzienniku przy zdjęciach widnieją obce domeny jako strony odsyłające, ktoś korzysta z grafik firmy, a rachunek za transfer płaci firma. W panelu cPanel służy do tego funkcja „Hotlink Protection” w grupie „Security”. Po jej włączeniu wpisuje się listę własnych domen, którym wolno wyświetlać pliki, oraz rozszerzenia chronionych plików. Na liście muszą znaleźć się obie wersje własnej domeny, z przedrostkiem www i bez niego, a także adres usługi CDN, jeżeli strona z niej korzysta.

Roboty, które pobierają za dużo

Roboty wyszukiwarek są potrzebne, ale w sieci krąży też wiele automatów zbierających dane dla narzędzi analitycznych i systemów sztucznej inteligencji. Robotom, które szanują plik robots.txt, można zakazać wstępu albo spowolnić je dyrektywą opóźnienia. Przykładowy zapis dla jednego robota wygląda następująco:

User-agent: NazwaRobota
Disallow: /

Trzeba przy tym wiedzieć o dwóch rzeczach. Po pierwsze, Google nie uwzględnia dyrektywy Crawl-delay, więc wobec robota Google ten zapis nic nie zmieni. To, ile danych pobiera Googlebot, widać w Google Search Console w raporcie „Statystyki indeksowania”, dostępnym w sekcji „Ustawienia”. Po drugie, roboty nieuczciwe ignorują plik robots.txt w całości. Na nie działa tylko blokada adresów IP w panelu hostingu albo zapora w usłudze CDN.

Blokowania robotów wyszukiwarek bez rozeznania stanowczo odradzam. Zakaz dla Googlebota oznacza stopniowe znikanie strony z wyników wyszukiwania, co kosztuje firmę nieporównanie więcej niż wyższy pakiet hostingu.

Pamięć podręczna przeglądarki i usługa CDN

Poprawnie ustawione nagłówki pamięci podręcznej sprawiają, że przeglądarka stałego klienta nie pobiera przy każdej wizycie tych samych zdjęć, arkuszy stylów i skryptów. Zwykle wystarczy włączyć odpowiednią opcję we wtyczce pamięci podręcznej. Usługa CDN przejmuje wysyłanie plików statycznych na własne serwery, więc z konta hostingowego wychodzi tylko niewielka część danych.

Poczta

Gdy na wykresie dominuje SMTP, należy sprawdzić, która skrzynka wysyła najwięcej. Masową wysyłkę ofert lepiej przenieść do wyspecjalizowanego narzędzia do korespondencji seryjnej, a duże pliki przekazywać odnośnikiem zamiast załącznikiem. Jeżeli nikt w firmie nie wysyłał tylu wiadomości, należy natychmiast zmienić hasła do skrzynek i sprawdzić formularze na stronie, bo niezabezpieczony formularz bywa wykorzystywany do rozsyłania spamu.

W jakiej kolejności działać, gdy strona właśnie przestała działać?

W sytuacji awaryjnej łatwo zacząć od przypadkowych zmian. Lepiej trzymać się stałej kolejności, bo każdy krok opiera się na wyniku poprzedniego.

Najpierw ustala się rodzaj limitu, potem otwiera właściwy raport w panelu, odszukuje dzień i godzinę przekroczenia, a dla tej chwili ogląda migawki lub dziennik dostępu. Dopiero mając wskazany adres, plik lub robota, wprowadza się jedną poprawkę i obserwuje wykres.

Jeżeli strona została całkowicie wyłączona z powodu transferu, analiza może potrwać dłużej niż cierpliwość klientów. Wtedy rozsądnie jest poprosić dostawcę o jednorazowe zwiększenie limitu lub dokupić pakiet transferu, a przyczyny szukać już przy działającej stronie.

Po czym poznać, że naprawa zadziałała, i co zrobić, gdy nie pomogła?

Skuteczność poprawek ocenia się w tych samych raportach, w których szukało się przyczyny. Dla zasobów chwilowych miarodajna jest kolumna „F” w tabeli „Usage”: po udanej naprawie liczba przekroczeń spada do zera albo do pojedynczych przypadków, a na karcie „Dashboard” znika informacja o ograniczaniu konta. Nowe migawki przestają się pojawiać.

Dla transferu trzeba poczekać dłużej. W tabeli „Bandwidth by Day” dzienne wartości powinny wyraźnie spaść w porównaniu z dniami sprzed zmiany. Średnie dzienne zużycie pomnożone przez liczbę dni w miesiącu powinno mieścić się w limicie z wyraźnym zapasem.

Do raportów dobrze jest zajrzeć ponownie po tygodniu i po miesiącu. Wtyczka zużycia zasobów wysyła powiadomienia o przekraczaniu limitów i radzę ich nie wyłączać, bo to najprostszy sposób, aby o następnym kłopocie dowiedzieć się przed klientami.

Co zrobić, gdy limity nadal są przekraczane?

Jeżeli po poprawkach wykresy wyglądają tak samo, są dwie możliwości: przyczyna została wskazana błędnie albo strona potrzebuje już większego konta. Pierwszą sprawdza się, pisząc do działu pomocy dostawcy, który widzi więcej niż klient w panelu. Zgłoszenie powinno być konkretne. Można użyć takiej treści:

Dzień dobry, konto [nazwa konta] z domeną [adres] otrzymało powiadomienie o przekroczeniu limitu [transferu / procesora / jednoczesnych połączeń]. Proszę o wskazanie: w jakich godzinach dochodziło do przekroczeń, które skrypty, adresy lub adresy IP odpowiadały za największe zużycie oraz jakie limity obowiązują na moim koncie. Proszę też o informację, czy w tym czasie odnotowano ruch o charakterze ataku.

Odpowiedź na takie pytania zwykle pozwala zamknąć sprawę. Jeżeli okaże się, że ruch jest prawdziwy, a strona po optymalizacji nadal potrzebuje więcej zasobów, pora zmienić pakiet.

Przed zmianą dobrze jest porównać limity CPU, PMEM, EP i transferu w obecnym i nowym pakiecie, zamiast kierować się samą nazwą oferty. Wyższy pakiet u tego samego dostawcy jest najprostszy, bo nie wymaga przenoszenia strony.

Jakich błędów unikać?

Wiele szkód po przekroczeniu limitów wynika nie z samego przekroczenia, lecz z nerwowych działań podjętych tuż po nim.

• Zmiana pakietu na wyższy bez szukania przyczyny – zainfekowana strona albo natarczywy robot zużyje każdy limit, tylko nieco później.
• Wprowadzanie kilku poprawek jednocześnie – nie wiadomo wtedy, która pomogła, a która coś zepsuła.
• Edycja plików wp-config.php i .htaccess bez kopii – błąd w jednym wierszu kończy się niedziałającą stroną.
• Blokowanie całych krajów lub wszystkich robotów – razem z niechcianym ruchem odcina się klientów i wyszukiwarki.
• Instalowanie kilku wtyczek pamięci podręcznej naraz – zakłócają się nawzajem i zwiększają obciążenie zamiast je zmniejszać.
• Usuwanie dzienników, aby zwolnić miejsce – znika jedyny materiał, na podstawie którego da się ustalić przyczynę.
• Ignorowanie ostrzeżeń od dostawcy – powtarzające się przekroczenia mogą skończyć się zawieszeniem konta zgodnie z regulaminem usługi.

Najczęstsze pytania

Czy przekroczenie limitu procesora oznacza, że strona ma dużo odwiedzających?

Niekoniecznie. Bardzo często za obciążenie odpowiadają roboty, próby odgadnięcia hasła albo jedna wadliwa wtyczka, a liczba prawdziwych odwiedzających pozostaje bez zmian. Dlatego przed zakupem wyższego pakietu należy obejrzeć migawki i dziennik dostępu, które pokazują, kto naprawdę wysyła żądania.

Co oznacza błąd 508 „Resource Limit Is Reached”?

Według dokumentacji CloudLinux serwer zwraca ten błąd, gdy liczba żądań obsługiwanych przez skrypty w tej samej chwili przekracza limit „Entry Processes”. Błąd znika samoczynnie, gdy kolejka się rozładuje. Jeżeli wraca regularnie, strona odpowiada zbyt wolno albo otrzymuje zbyt wiele żądań od automatów.

Czy po wyczerpaniu transferu strona wróci sama?

Licznik transferu zeruje się z początkiem kolejnego okresu rozliczeniowego, więc strona zwykle zaczyna wtedy działać ponownie. Czekanie rzadko jest jednak dobrym wyjściem, bo każdy dzień przestoju oznacza utracone zapytania. Dostawcy przeważnie umożliwiają dokupienie transferu albo zmianę pakietu w trakcie miesiąca.

Dlaczego dostawca reklamuje transfer bez limitu, a mimo to ogranicza konto?

Brak limitu transferu nie oznacza braku pozostałych ograniczeń. Konto nadal ma określony przydział procesora, pamięci i jednoczesnych połączeń, a regulamin zwykle opisuje zasady uczciwego korzystania z serwera. Rzeczywiste możliwości konta wyznaczają właśnie te parametry, dlatego należy ich szukać w specyfikacji oferty.

Czy usługa CDN rozwiązuje problem z procesorem?

Częściowo. Usługa CDN przejmuje wysyłanie zdjęć, stylów i skryptów, więc przede wszystkim obniża transfer. Na procesor wpływa wtedy, gdy przechowuje także gotowe strony albo zatrzymuje szkodliwy ruch swoją zaporą. Wolnej wtyczki ani przeciążonej bazy danych sama usługa CDN nie naprawi.

Czy roboty Google mogą wyczerpać limity konta?

Zdarza się to rzadko i dotyczy głównie dużych sklepów z ogromną liczbą adresów tworzonych przez filtry. W takiej sytuacji należy uporządkować adresy z parametrami i zablokować je w pliku robots.txt, zamiast odcinać robota od całej strony. Skalę jego aktywności pokazuje raport „Statystyki indeksowania” w Google Search Console.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Szukanie przyczyny w wykresach i dziennikach wymaga spokoju, a tego najbardziej brakuje, gdy strona firmy właśnie przestała działać. Chętnie zajmę się tym od początku do końca: sprawdzę, który limit został przekroczony, przejrzę statystyki, migawki i dzienniki konta, wskażę wtyczkę, plik lub robota odpowiedzialnego za zużycie, wprowadzę poprawki i przez kolejne dni będę obserwować, czy problem nie wraca. Na koniec przekażę zrozumiały opis tego, co zostało zrobione, i podpowiem, czy obecny pakiet hostingu wystarczy na przyszłość.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać, co się dzieje ze stroną. Odpowiem, od czego zacznę i czego będę potrzebować, aby strona jak najszybciej wróciła do normalnej pracy.