Jeżeli strona zwalnia albo okresowo zwraca błędy, najpierw ustal, który limit hostingu został faktycznie osiągnięty. W hostingu współdzielonym osobno mogą być ograniczane procesor, pamięć, szybkość operacji dyskowych, liczba procesów i liczba równoczesnych wejść do aplikacji. Ten sam objaw w przeglądarce może więc mieć różne przyczyny. Osobne ograniczenia połączeń i pracy bazy omawia poradnik o limity MySQL na hostingu. To ścieżka diagnostyczna dla działającego konta po wystąpieniu objawu, nie checklista zakupowa. Osobnym ograniczeniem jest limit liczby plików (inode). Limity PHP dotyczą jeszcze innej warstwy konfiguracji.
Najbardziej użyteczny punkt wyjścia to historia wykorzystania zasobów z momentu problemu. Na serwerach z CloudLinux panel może pokazywać bieżące lub historyczne zużycie, limity oraz — dla części zasobów i konfiguracji — faults, czyli zdarzenia raportowane przy osiąganiu limitu. Przy CPU ważne są przede wszystkim dojście do limitu, czas trwania, zbieżność z problemem strony i powtarzalność; brak licznika faults nie wyklucza dławienia procesora. CloudLinux udostępnia osobne statystyki i pola limitów między innymi dla CPU, pamięci, I/O, IOPS, procesów i entry processes.
Jakie limity hostingu mogą ograniczać działanie strony?
Nazwy widoczne w panelu zależą od operatora i konfiguracji serwera. W CloudLinux podstawowy zestaw obejmuje między innymi CPU, pamięć fizyczną, I/O, IOPS, NPROC i EP; są to odrębne limity, ponieważ ograniczają inne elementy działania konta.
| Limit | Co ogranicza | Co może być widoczne przy osiąganiu limitu |
|---|---|---|
| CPU / SPEED | Czas procesora dostępny dla konta | Wolniejsze wykonywanie skryptów i dłuższe odpowiedzi, gdy konto jest dławione |
| PMEM | Pamięć fizyczną używaną przez procesy konta | Problemy z uruchomieniem lub utrzymaniem procesów po wyczerpaniu pamięci |
| I/O | Przepustowość odczytu i zapisu na dysku | Wolniejsze operacje wymagające intensywnego dostępu do plików |
| IOPS | Liczbę operacji odczytu i zapisu wykonywanych w jednostce czasu | Przestoje przy wielu małych operacjach dyskowych mimo niewielkiej liczby przesyłanych MB |
| NPROC | Liczbę procesów działających w obrębie konta | Brak możliwości uruchomienia kolejnych procesów, gdy limit został wykorzystany |
| EP | Liczbę równoczesnych wejść aplikacji do środowiska konta | Problemy z obsługą kolejnych równoczesnych żądań; dokładny objaw zależy od używanego serwera i jego konfiguracji |
W CloudLinux I/O jest limitem przepustowości dyskowej: po jego osiągnięciu procesy są spowalniane, a nie automatycznie zabijane. IOPS dotyczy natomiast liczby operacji dyskowych. Z tego powodu dwa konta przesyłające podobną ilość danych mogą zachowywać się inaczej, jeśli jedno wykonuje bardzo dużo małych odczytów i zapisów. I/O i IOPS są definiowane jako dwa różne ograniczenia.
Gdzie sprawdzić, czy limit został osiągnięty?
W cPanel na serwerze z CloudLinux operator może udostępnić ekran CPU and Concurrent Connection Usage lub odpowiadającą mu sekcję wykorzystania zasobów. cPanel zaznacza, że ten interfejs zależy od CloudLinux i może być włączony albo wyłączony przez dostawcę hostingu. Brak tej pozycji w menu nie oznacza więc, że konto nie ma limitów.
Do diagnozy zapisz przede wszystkim czas wystąpienia problemu, nazwę zasobu, jego limit i maksymalne wykorzystanie. Jeżeli panel pokazuje również faults dla danego parametru, zanotuj je jako dodatkową informację. Jeżeli możesz zmieniać zakres dat, zacznij od krótkiego przedziału obejmującego zdarzenie. Średnia z całego dnia może ukryć kilkuminutowy szczyt, podczas którego strona rzeczywiście przestała odpowiadać.
Brak faults nie kończy diagnostyki. Oznacza tylko, że w badanym widoku nie ma takiego potwierdzenia dla obserwowanych limitów. Strona może nadal zwalniać z powodu dławienia CPU, aplikacji, bazy danych, zewnętrznej usługi albo ograniczenia raportowanego w inny sposób.
Gdy operator nie pokazuje historii zasobów, poproś pomoc techniczną o dane dla konkretnego czasu. CloudLinux udostępnia administratorowi statystyki użycia i limitów, a dla części zasobów także liczniki faults, więc odpowiedź nie musi kończyć się na ogólnym „strona zużywa za dużo zasobów”. Narzędzia CloudLinux przewidują osobne pola między innymi dla CPU, PMEM, NPROC, I/O, IOPS i EP.
CPU jest na 100% — czy trzeba kupić droższy pakiet?
Nie na podstawie samego pojedynczego odczytu. Osiągnięcie limitu CPU oznacza, że konto w danym momencie wykorzystało cały dostępny przydział procesora. Dla decyzji ważniejsze są czas trwania, zbieżność z problemem strony i powtarzalność niż sam fakt, że wykres dotknął 100%.
Hipotetycznie 100% CPU przez 20 sekund podczas jednorazowego generowania miniatur nie musi uzasadniać stałej zmiany pakietu. Inaczej wygląda 100% utrzymujące się przez wiele minut przy zwykłym ruchu i powtarzające się kilka razy dziennie równocześnie ze spowolnieniem witryny. To nie jest uniwersalny próg czasowy, lecz przykład pokazujący, dlaczego ten sam procent może prowadzić do innej decyzji.
Jeżeli CPU dochodzi do limitu podczas zwykłego ruchu i sytuacja powtarza się w wielu podobnych okresach, większy przydział może być jednym z rozwiązań. Jeżeli szczyt występuje tylko podczas jednego zadania — na przykład importu, generowania miniatur albo zadania cyklicznego — najpierw ustal, czy problemem jest stałe zapotrzebowanie strony, czy sposób wykonania tej jednej operacji.
Do porównania ofert potrzebna jest więc nie tylko liczba „100% CPU”, ale jej znaczenie u danego operatora. W CloudLinux parametr SPEED może być określony jako procent pojedynczego rdzenia albo odpowiednia wartość częstotliwości; 100% SPEED odpowiada jednemu rdzeniowi w tym modelu limitów. Etykieta „200% CPU” w ofercie nie powinna być interpretowana bez sprawdzenia, jak dostawca mapuje ją na rzeczywisty limit konta.
RAM i NPROC — dlaczego to nie jest ten sam limit?
PMEM ogranicza pamięć fizyczną, a NPROC liczbę procesów. Konto może więc mieć jeszcze wolną pamięć, ale nie móc uruchomić kolejnego procesu, albo odwrotnie — procesów jest niewiele, lecz ich łączne zużycie pamięci dochodzi do limitu.
To ważne przy WordPressie z zadaniami uruchamianymi w tle, skryptami CLI i harmonogramami. Jeden problematyczny proces może zużywać dużo pamięci, a duża liczba lekkich procesów może wcześniej wykorzystać NPROC. Dlatego prośba o „więcej RAM-u” nie rozwiązuje automatycznie problemu, jeśli panel pokazuje faults właśnie dla liczby procesów.
PMEM i NPROC są w CloudLinux niezależnymi ograniczeniami z osobnymi licznikami faults; limit pamięci fizycznej i limit liczby procesów konfiguruje się oddzielnie.
EP, PHP workers i błąd 508 — czego nie utożsamiać?
EP, czyli Entry Processes, nie jest po prostu liczbą odwiedzających stronę. Ten limit kontroluje, ile wejść aplikacji może być równocześnie obsługiwanych w środowisku konta; w CloudLinux parametr nazywa się Entry Processes. Przy Apache nowe żądanie CGI/PHP może zwiększać ten licznik. W tym modelu przekroczenie EP może prowadzić do odpowiedzi 508 Resource Limit Reached. Implementacja EP różni się między Apache i LiteSpeed.
Nie przenoś więc automatycznie do EP marketingowego określenia PHP workers. Operator może posługiwać się własnym limitem procesów PHP, konfiguracją PHP-FPM albo innym sposobem kontrolowania współbieżności. Jeżeli oferta podaje „10 PHP workers”, a panel wykorzystania zasobów pokazuje EP lub NPROC, poproś operatora o wyjaśnienie, jak te wartości są ze sobą powiązane w jego konfiguracji.
Sam kod błędu nie powinien zastępować danych o zasobach. W CloudLinux 508 jest związany z EP, ale dokładny objaw zależy od używanego serwera WWW i jego konfiguracji. Przy ograniczeniu pamięci lub liczby procesów mogą pojawić się błędy 500/503, natomiast CPU i I/O są typowo dławione i mogą przede wszystkim wydłużać czas odpowiedzi. Skutki tych limitów są opisane oddzielnie.
I/O i IOPS — kiedy problem nie leży w procesorze?
Strona może mieć zapas CPU i RAM, a mimo to zwalniać podczas operacji intensywnie korzystających z dysku. I/O ogranicza ilość danych przesyłanych do i z dysku w jednostce czasu, a IOPS — liczbę operacji. Różnicę widać szczególnie przy zadaniach wykonujących wiele drobnych zapisów albo odczytów.
Do takich sytuacji mogą należeć importy, rozpakowywanie dużej liczby plików, generowanie miniatur, praca z cache zapisującym dużo małych obiektów czy tworzenie lokalnego archiwum. Nie oznacza to, że każde takie zadanie wyczerpie I/O lub IOPS. Jeżeli w czasie problemu wykorzystanie dochodzi do odpowiedniego limitu, a panel dodatkowo pokazuje faults dla I/O lub IOPS, masz mocniejszy techniczny kierunek dalszej diagnozy.
Warto odróżnić ten przypadek od braku miejsca na dysku. Pojemność mówi, ile danych można przechowywać, a I/O i IOPS — z jakim ograniczeniem wykonywane są operacje dyskowe. Sposób obliczenia potrzebnej przestrzeni opisuje poradnik o pojemności strony i poczty; własne dane możesz policzyć w kalkulatorze potrzebnej przestrzeni.
Jak znaleźć przyczynę, gdy problem pojawia się tylko czasami?
Najpierw zapisz konkretny moment i czynność: otwarcie strony, zapis w panelu, uruchomienie importu, wykonanie zadania cron albo wzrost ruchu. Następnie zestaw ten czas z wykresem zasobów, limitami i — jeśli są dostępne — licznikami faults. Dopiero wtedy sprawdź log aplikacji i serwera dla tego samego przedziału.
| Co widzisz | Od czego zacząć |
|---|---|
| CPU powtarzalnie dochodzi do limitu w czasie spowolnienia | Ustal, która operacja zużywa procesor, jak długo trwa ograniczenie i czy występuje przy normalnym ruchu czy tylko podczas zadania administracyjnego |
| Faults EP w chwili błędu 508 | Sprawdź równoczesne żądania i czas ich obsługi; ustal z operatorem model EP/PHP dla używanego serwera |
| Faults NPROC | Sprawdź liczbę procesów, zadania cron, procesy CLI i inne równoległe prace na koncie |
| Faults PMEM | Ustal, który proces lub operacja zwiększa zużycie pamięci i czy problem jest powtarzalny |
| Faults I/O lub IOPS | Sprawdź operacje dyskowe wykonywane w tym czasie, np. import, backup, cache lub dużą liczbę plików |
| Brak faults, ale strona nadal jest wolna | Nie zakładaj problemu pakietu; sprawdź aplikację, bazę, zewnętrzne usługi i czas odpowiedzi poszczególnych żądań |
Najważniejszy jest związek czasowy. Fault sprzed kilku godzin nie wyjaśnia automatycznie obecnego błędu, a pojedynczy skok podczas ręcznego importu nie dowodzi, że codzienny ruch wymaga większego pakietu. Nawet równoczesne osiągnięcie limitu i błąd strony są przede wszystkim technicznie uzasadnionym kierunkiem diagnozy; przy złożonej aplikacji mogą współistnieć także inne problemy.
Jakie dane wysłać operatorowi zamiast pytania „dlaczego strona jest wolna?”
Jeżeli panel nie daje pełnej odpowiedzi, przekaż operatorowi konkretny przypadek. Dzięki temu może sprawdzić zasoby i logi dla właściwego momentu.
Strona zwolniła lub zwróciła błąd około [godzina i data] podczas [konkretna czynność lub zwykłe wejście użytkownika]. Proszę wskazać, czy konto osiągnęło wtedy któryś z limitów CPU, pamięci, I/O, IOPS, EP lub NPROC. Jeśli tak, proszę podać limit, maksymalne użycie i liczbę zdarzeń jego osiągnięcia oraz wyjaśnić, który parametr wyższego pakietu zwiększyłby właśnie ten zasób. Jeżeli problem dotyczy innego limitu niż wymienione, proszę podać jego nazwę i znaczenie.
Jeśli operator odpowie tylko nazwą droższego planu, poproś o powiązanie tej zmiany z wykrytym ograniczeniem. Informacja „pakiet ma więcej zasobów” jest mniej użyteczna niż wskazanie, że przykładowo rośnie limit pamięci albo współbieżności, który był osiągany w czasie problemu.
Kiedy większy pakiet ma techniczne uzasadnienie?
Zmiana pakietu ma mocną podstawę wtedy, gdy właściwy limit jest osiągany powtarzalnie przy normalnym, potrzebnym sposobie korzystania ze strony. Zbieżność czasu, powtarzalność i dodatkowe dane — w tym faults, jeśli są dostępne — dają konkretny parametr do dalszego porównania. Nadal jest to diagnoza oparta na dowodach, a nie automatyczne stwierdzenie, że każdy problem strony powodował właśnie ten limit.
Inaczej wygląda jednorazowa operacja administracyjna. Jeśli limit został osiągnięty podczas importu wykonywanego raz w roku, zakup wyższego abonamentu na stałe nie jest jedynym możliwym rozwiązaniem. Można najpierw ustalić, czy zadanie da się wykonać inaczej albo zlecić operatorowi. Wniosek zależy od tego, czy dodatkowy zasób jest potrzebny stale, okresowo czy tylko przy konkretnej pracy.
Przy porównaniu ofert zachowaj również inne wymagania strony: pojemność, backup, wersje PHP, pocztę i koszt odnowienia. Większy limit CPU nie rekompensuje zbyt małej skrzynki lub braku potrzebnej funkcji. Pakiety możesz zestawić w porównywarce hostingu, a szacowane koszty zmiany sprawdzić w kalkulatorze opłacalności zmiany hostingu. Jeżeli dopiero wybierasz usługę, zacznij od checklisty limitów przed zakupem.
Najpierw nazwij ograniczenie, które rzeczywiście wystąpiło, a dopiero potem dobieraj większy pakiet. Informacja „o 14:32 konto trzykrotnie osiągnęło limit EP” albo „podczas importu I/O było dławione przez kilka minut” daje technicznie uzasadniony kierunek diagnozy i konkretny parametr oferty do porównania. Po zmianie można sprawdzić, czy ten sam objaw i ograniczenie nadal występują.