Limity hostingu współdzielonego: CPU, RAM, I/O – jak je czytać i co realnie spowalnia stronę?

Limity na hostingu współdzielonym brzmią jak coś „dla adminów”, dopóki strona nie zacznie łapać zadyszki. Nagle rośnie TTFB, panel WordPressa działa jak w zwolnionym tempie, a w losowych momentach wyskakuje 503 albo 504. Wtedy większość osób robi dwa błędy: albo od razu zmienia plan hostingowy „na szybszy”, albo przeciwnie – zaczyna optymalizować wszystko naraz (obrazy, wtyczki, CDN), bez pewności, co naprawdę jest wąskim gardłem.

CPU, RAM i I/O to trzy różne typy ograniczeń i dają różne symptomy. CPU dotyczy mocy obliczeniowej, RAM – pamięci potrzebnej do wykonania kodu i operacji, a I/O – tego, jak szybko serwer jest w stanie czytać i zapisywać dane (pliki i często pośrednio bazę). Co ważne: strona może być wolna nawet bez uderzania w limity, np. przez ciężkie zasoby na froncie albo zewnętrzne skrypty. Ale jeśli problemem są limity, zobaczysz charakterystyczne „piki” i sytuacje, w których wszystko zwalnia naraz.

W tym artykule pokażę Ci, jak czytać typowe limity na hostingu współdzielonym i jak po objawach rozpoznać, czy dusi Cię CPU, RAM czy I/O. Dostaniesz też praktyczne metody sprawdzenia: co kliknąć w panelu hostingu, co sprawdzić w WordPressie, jakie logi otworzyć i jakie testy wykonać, żeby nie zgadywać.

Dodatkowo uporządkujemy temat tak, żeby nie mieszać hostingu z „wydajnością strony” w ogóle. Innymi słowy: odróżnimy problem serwera od problemu aplikacji. To oszczędza czas i pieniądze, bo często wystarczy zmiana ustawień cache, harmonogramu zadań albo jedna konkretna wtyczka do poprawy, zamiast migracji.

Jeśli dopiero wybierasz usługę i chcesz rozumieć parametry „z oferty”, dobrze będzie równolegle przeczytać poradnik jak wybrać hosting.

Co oznaczają limity na hostingu współdzielonym i skąd się biorą

Na hostingu współdzielonym wiele kont korzysta z tej samej infrastruktury. Żeby jedna strona nie „zjadła” całej maszyny, dostaje przydział zasobów: CPU, pamięci i przepustowości operacji na dysku. To nie jest kara, tylko mechanizm stabilizacji. Dzięki temu hosting działa przewidywalnie dla większości użytkowników i nie wywraca się przez jeden skrypt, który wpadł w pętlę.

W praktyce limity bywają opisane różnie: CPU w procentach albo jako ułamek rdzenia, RAM jako pamięć procesu albo konta, I/O jako MB/s lub IOPS. To powoduje, że dwie oferty z pozoru nieporównywalne mogą mieć podobną realną wydajność – tylko inaczej nazwaną.

Ważne jest też to, że limity mogą działać „twardo” albo „miękko”. Twardy limit kończy się błędem (np. proces PHP ubity, 503, 508). Miękki limit to throttling: serwer spowalnia Twoje procesy, żeby nie przekroczyły przydziału. Dla użytkownika wygląda to jak losowe spowolnienia – rano jest szybko, po południu „muli”, a w panelu WordPress czasem nie da się nic zapisać.

Na tym etapie dobrze mieć w głowie różnicę między „wydajnością hostingu” a „wydajnością strony”. Hosting może być OK, a problemem jest front (ciężkie grafiki, zewnętrzne trackery). Z drugiej strony strona może być lekka, a mimo to dostaje zadyszki, bo w tle działa import, backup albo cron. Jeśli chcesz zebrać podstawowe kryteria oceny usługi, kontekst daje tekst o tym, czym jest najlepszy hosting.

CPU na hostingu współdzielonym: procenty, rdzenie, procesy i throttling w praktyce

CPU to „siła obliczeniowa”: ile pracy może wykonać kod PHP (WordPress), ile zapytań i logiki przejdzie w danym czasie, jak szybko policzy się generowanie strony. Na hostingu współdzielonym CPU najczęściej limituje się jako udział w czasie procesora, a nie jako „fizyczny rdzeń na stałe”. Gdy w panelu widzisz 100% CPU, to zwykle oznacza „tyle możesz maksymalnie dostać”, a nie „zawsze masz pełne 100% jednego rdzenia”.

Dla WordPressa CPU jest krytyczne wtedy, gdy strona generuje się dynamicznie: brak cache, dużo wtyczek, ciężki motyw, builder, rozbudowane filtry produktów, wyszukiwarka po treści, albo integracje (API), które wykonują się podczas ładowania strony. Do tego dochodzą zadania w tle: backupy, skanery bezpieczeństwa, generowanie miniaturek, importy CSV, synchronizacje magazynu.

Objawy limitu CPU są dość charakterystyczne: rośnie TTFB, a czasem też rośnie odsetek błędów 502/503, bo procesy PHP nie nadążają. Strona „startuje” długo, zanim w ogóle zacznie pobierać zasoby. Często widać, że problem jest mocno zależny od pory dnia lub skoków ruchu: jedna wizyta nic nie pokaże, dopiero seria wejść ujawnia problem.

W throttlingu kluczowe jest to, że wszystko „działa, ale wolniej”. To może mylić, bo wygląda jak problem z optymalizacją frontu. Różnica jest taka, że front zwykle psuje LCP/CLS, a throttling podbija TTFB i powoduje „zanim coś się pojawi, jest cisza”.

RAM i limity pamięci: czym różni się RAM konta od memory_limit w PHP

RAM jest podstępny, bo słowo „pamięć” może oznaczać kilka rzeczy naraz. Jest limit pamięci dla konta (albo kontenera), limit pamięci procesu, a w dodatku w samym PHP masz memory_limit. Możesz mieć sytuację, w której hosting ma zapas RAM, ale memory_limit jest za niski – i WordPress wysypuje się przy konkretnej operacji. Albo odwrotnie: memory_limit jest ustawiony wysoko, ale konto jest ograniczone, więc procesy zaczynają być ubijane pod obciążeniem.

Typowe objawy limitu pamięci to błędy 500, białe ekrany i komunikaty typu „Allowed memory size exhausted” w logach PHP. Często pojawia się to nie na stronie głównej, tylko w panelu: edycja wpisu w builderze, import produktów, generowanie raportu, instalacja/aktualizacja wtyczki, regeneracja miniaturek. To są operacje, które ładują dużo danych i wykonują dłuższy kod.

RAM ma też powiązanie z cache. Jeśli hosting ma mechanizmy cache na poziomie serwera (OPcache, object cache), to brak pamięci może powodować, że cache działa gorzej albo wcale, a wtedy CPU dostaje dodatkową robotę. W efekcie objawy przypominają limit CPU, choć źródłem jest pamięć i „zrzucanie” rzeczy z pamięci.

W praktyce, gdy strona „czasem działa, a czasem losowo sypie błędami” przy operacjach administracyjnych, to RAM i limity PHP są pierwszym tropem. Warto wtedy sprawdzić, czy problem dotyczy konkretnych akcji (np. tylko eksport, tylko zapis ustawień wtyczki), a nie całego serwisu.

I/O, IOPS i „dysk”: kiedy wąskim gardłem są odczyty i zapisy plików

I/O to zdolność systemu do szybkiego czytania i zapisywania danych. Na hostingu współdzielonym to bardzo częsty, a jednocześnie niedoceniany limit. Bo strona nie „wygląda” jak coś, co dużo zapisuje na dysku – dopóki nie przypomnisz sobie o cache plikowym, logach, sesjach, uploadach, generowaniu miniaturek, backupach i wtyczkach, które zapisują dane co kilka sekund.

I/O może być limitowane jako MB/s (przepustowość), jako IOPS (liczba operacji na sekundę), albo jako mieszanka obu. Najgorszy scenariusz to tysiące małych odczytów i zapisów: dużo plików, dużo małych requestów, częste operacje na katalogach cache. Wtedy nawet szybki dysk nie pomaga, bo wąskim gardłem jest liczba operacji, nie ich „waga”.

Objawy I/O są inne niż CPU. Często widzisz, że proces „stoi”, ale nie dlatego, że liczy, tylko dlatego, że czeka na dysk. W WordPressie przekłada się to na wolne ładowanie panelu (bo czyta dużo plików PHP), wolne wgrywanie mediów, wolne generowanie miniaturek i dziwne zawieszki podczas aktualizacji wtyczek/motywu. Przy dużej liczbie wejść problem potrafi uderzyć również we frontend, bo cache i pliki statyczne zaczynają być czytane wolniej.

Jeśli temat I/O pojawia się w kontekście SEO (np. TTFB, stabilność crawl), to warto pamiętać, że hosting i ograniczenia zasobów mogą mieć wpływ na indeksację i „zdrowie” serwisu. Zobacz też nasz wpis – hosting a SEO.

Baza danych a limity: dlaczego wolne zapytania wyglądają jak brak CPU?

W praktyce WordPress jest tak szybki, jak szybkie są jego zapytania do bazy. Problem w tym, że wolna baza potrafi wyglądać jak limit CPU albo I/O, bo PHP czeka: na wynik zapytania, na blokadę tabeli, na zapis transakcji, na odczyt indeksów. Jeśli do tego dochodzi wysoki ruch i dużo równoległych zapytań, serwer zaczyna przypominać zakorkowane skrzyżowanie.

Wolne zapytania często biorą się z konkretnych rzeczy: rozrośniętego wp_options (autoload), dużych tabel od wtyczek, filtrowania po meta danych w sklepach, wyszukiwarki bez indeksów, albo rozbudowanych raportów w panelu. Wtedy sama zmiana limitu CPU może niewiele dać, bo problemem nie jest „brak mocy”, tylko „zła praca do wykonania”.

Dodatkowo baza lubi mieszać się z I/O. Gdy MySQL intensywnie czyta/zapisuje na dysku, a hosting ma niski limit I/O, całość siada. Objaw: w panelu hostingu widzisz I/O na granicy, ale w aplikacji wygląda to jak „wszystko się wiesza” – bo czeka zarówno PHP, jak i baza.

Dlatego diagnoza limitów powinna zawsze uwzględniać bazę: nie w sensie „rób tuning jak DBA”, tylko w sensie zauważenia, że jeden plugin potrafi generować setki zapytań na request i to jest prawdziwe źródło problemu.

Objawy i diagnostyka: po czym poznasz, czy dusi Cię CPU, RAM czy I/O

Najłatwiej zacząć od pytania: kiedy jest wolno? Jeśli wolno jest tylko pod obciążeniem (np. po publikacji, po kampanii, po wejściu botów), CPU i limity procesów są podejrzane. Jeśli wolno lub błędnie działa przy konkretnych operacjach w panelu (import, edycja ciężkich stron, raporty), RAM i memory_limit są częstym winowajcą. Jeśli wolno jest przy operacjach na plikach (media, aktualizacje, cache, backup), I/O jest na krótkiej liście.

Dalej patrzysz na charakter spowolnienia. CPU-limit zwykle podbija TTFB i powoduje, że serwer długo „myśli”, zanim cokolwiek wyśle. I/O-limit częściej daje wrażenie „zawieszek”, a niekoniecznie stałego wydłużenia każdego requestu. RAM-limit bywa brutalny: błędy 500, ubijane procesy, a czasem „losowo” – bo zależy od tego, co akurat trafiło do pamięci w danym requestcie.

Trzeci krok to korelacja z zadaniami w tle. Bardzo często limity nie są przekraczane przez normalne wejścia użytkowników, tylko przez crony i automaty: backup o 12:00, skan bezpieczeństwa co godzinę, import z hurtowni co 10 minut, wysyłka maili, generowanie feedu produktowego. Jeśli spowolnienia są cykliczne, to prawie zawsze jest „coś, co odpala się samo”.

Na koniec dochodzą boty i crawl. Jeśli widzisz okresy intensywnego skanowania (Googlebot lub inne boty), to hosting może wyglądać jak „za słaby”, choć problemem jest brak cache i brak limitowania botów.

Jak sprawdzić zużycie zasobów krok po kroku: panel hostingu, WordPress, logi

Najpierw zbierz dane z panelu hostingu. Szukaj sekcji typu „użycie zasobów”, „limity”, „statystyki CPU/RAM/I/O”, „resource usage”. Interesują Cię wykresy w czasie, nie pojedyncza liczba. Pojedynczy „peak” nic nie mówi, ale powtarzalny wzór (np. zawsze 10:05 i 22:30) to złoto diagnostyczne.

Drugi krok to logi: log błędów PHP, logi serwera WWW (access/error) i – jeśli jest – log „resource limit reached”. Szukasz słów kluczowych: memory exhausted, killed, throttled, timeout, 508, 503. Ważne: notuj godzinę i porównuj ją z wykresami w panelu. Jeśli o 14:12 jest spike CPU i w logach o 14:12 masz timeouts, to układanka zaczyna się składać.

Trzeci krok to WordPress. W praktyce są dwa szybkie tropy:

• Włącz logowanie błędów (jeśli masz taką możliwość w środowisku) i zobacz, czy błędy są powtarzalne przy konkretnej akcji.
• Użyj wtyczki typu Query Monitor (diagnostycznie, na czas testów) i sprawdź, czy masz kosmiczną liczbę zapytań, długie zapytania albo wolne hooki. To nie jest „must have” na stałe, ale do diagnozy jest bezcenne.

Czwarty krok to testy obciążeniowe „z głową”. Nie musisz robić profesjonalnego load testu, żeby zauważyć problem. Wystarczy:

• odpalić 20–50 wejść na tę samą stronę (np. narzędziem online lub prostą pętlą w przeglądarce) i obserwować TTFB,
• porównać stronę z cache (pierwsze wejście po czyszczeniu cache) i kolejne wejścia,
• sprawdzić, czy problem dotyczy tylko wybranych podstron (np. filtr produktów vs zwykły wpis).

Jeśli na tym etapie widzisz, że Twoja strona „umiera” na wejściach, a jednocześnie to WordPress, wraca pytanie: czy masz hosting „pod WP” i czy Twoje środowisko jest ustawione sensownie.

Jak odciążyć stronę bez zmiany hostingu: cache, optymalizacja, harmonogramy

Największa dźwignia na hostingu współdzielonym to cache. Nie chodzi o „plugin do cache, bo wszyscy mają”, tylko o to, że cache zmienia profil zużycia CPU. Zamiast generować stronę dynamicznie dla każdego wejścia, serwujesz gotowy HTML (albo przynajmniej skracasz ścieżkę). To często kasuje problem limitów CPU przy normalnym ruchu.

Druga dźwignia to ograniczenie zadań tła w godzinach szczytu. Backup w południe, skan bezpieczeństwa co 15 minut, importy w środku dnia – to proszenie się o I/O i CPU spikes. Jeśli masz wpływ na harmonogram, ustaw te rzeczy na noc lub rozbij na mniejsze paczki. W sklepach to potrafi zmienić „strona nie działa w poniedziałek” w „wszystko stabilne”.

Trzecia dźwignia to porządek w wtyczkach. Na hostingu współdzielonym nie ma miejsca na wtyczkę, która robi ciężkie raporty przy każdym wejściu albo dokleja 20 zapytań do bazy „bo tak”. Nie chodzi o to, żeby mieć minimalną liczbę wtyczek, tylko żeby nie mieć wtyczek, które robią nieproporcjonalnie dużo pracy w kluczowych miejscach.

Czwarta dźwignia to ograniczenie operacji na plikach. Jeśli cache zapisuje tysiące małych plików, a hosting ma niskie IOPS, to prędzej czy później zobaczysz „mulenie”. Czasem zmiana metody cache (np. z plikowej na inną dostępna w danym środowisku) robi większą różnicę niż podbicie CPU.

Na koniec: jeśli dopiero wybierasz usługę i budżet jest ważny, pamiętaj, że „tani” hosting nie musi być zły, ale musi pasować do Twojego profilu.

Najczęstsze błędy i jak je naprawić

Błąd 1: Diagnoza po jednym teście („u mnie szybko, więc hosting OK”)
Jedno wejście, zwłaszcza po ciepłym cache, potrafi wyglądać świetnie nawet na przeciętnym środowisku. Limity wychodzą pod obciążeniem, przy cold cache albo w godzinach, gdy dzieją się crony i automaty. Naprawa jest prosta: testuj w serii, notuj TTFB i porównuj wyniki z i bez cache oraz w różnych porach. Jeśli problem jest cykliczny, szukaj korelacji z zadaniami tła.

Błąd 2: Podbijanie memory_limit bez zrozumienia limitu konta
Podniesienie memory_limit w PHP czasem pomaga, ale jeśli hosting limituje pamięć konta/kontenera, to tylko przesuwasz problem w inne miejsce. Nagle kilka równoległych requestów zaczyna ubijać procesy i pojawiają się błędy 500/503. Naprawa: sprawdź najpierw, czy problem to stricte błąd „Allowed memory size exhausted”, czy raczej ubijanie procesów przy równoległym obciążeniu. Jeśli to drugie, walcz cache i ogranicz równoległe ciężkie operacje (np. raporty, importy), zamiast pompować pamięć.

Błąd 3: Backup i skany bezpieczeństwa w środku dnia (I/O spike jako „tajemnicze mulenie”)
Wtyczki backupu potrafią czytać i zapisywać tysiące plików, a skanery bezpieczeństwa potrafią przejść cały katalog WordPressa. Na hostingu współdzielonym to gotowy przepis na limit I/O i „zawieszki”. Naprawa: przenieś backup na godziny nocne, zmniejsz częstotliwość skanów, wyklucz katalogi cache i uploadów ze skanowania, a duże backupy rób przyrostowo.

Błąd 4: Brak cache na stronach, które dostają najwięcej ruchu
Często ktoś ma cache „jakieś”, ale wyłączone dla strony głównej, kategorii, filtrów albo stron produktu „bo dynamiczne”. Efekt: najczęściej odwiedzane miejsca generują się w PHP przy każdym wejściu, CPU rośnie, a hosting zaczyna throttling. Naprawa: zacznij od cache tam, gdzie jest największy ruch i gdzie treść nie zmienia się co sekundę. Dla elementów dynamicznych używaj fragmentów (np. koszyk, stan magazynowy) zamiast wyłączania cache dla całej strony.

Błąd 5: „Wolno = trzeba zmienić hosting”, bez sprawdzenia, co realnie spowalnia stronę
Najdroższy błąd finansowo. Jeśli problemem jest jedna wtyczka generująca ciężkie zapytania, to zmiana hostingu kupi Ci trochę czasu, ale nie rozwiąże przyczyny. Naprawa: zrób szybki przegląd objawów (TTFB vs frontend), sprawdź logi PHP, odpal diagnostykę zapytań (choćby na chwilę), porównaj zachowanie podstron. Dopiero potem podejmuj decyzję o zmianie planu.

Kiedy zmiana planu lub typu hostingu ma sens i jak wybrać rozsądnie?

Zmiana planu ma sens wtedy, gdy widzisz powtarzalne dobicie do limitów mimo sensownej konfiguracji aplikacji. Jeśli masz cache, zadania tła ustawione rozsądnie, brak ewidentnie „toksycznych” wtyczek, a mimo to CPU/RAM/I/O regularnie dobija do sufitu przy normalnym ruchu – to znak, że profil strony przerósł plan.

Nie myl jednak „ruchu normalnego” z „ruchem przypadkowym”. Jeśli dobicie do limitów dzieje się tylko wtedy, gdy boty skanują stronę albo gdy odpalasz ręcznie import 20 tys. produktów w godzinach pracy, to w pierwszej kolejności naprawiasz proces, a dopiero potem rozważasz upgrade.

W wyborze nowego planu najważniejsze jest dopasowanie parametrów do wąskiego gardła. Jeśli problemem jest CPU, patrz na realny przydział i throttling. Jeśli RAM, patrz na limity procesu i konta oraz możliwości konfiguracji PHP. Jeśli I/O, pytaj o IOPS i przepustowość, a nie tylko „NVMe”.

FAQ – Najczęściej zadawane pytania

Angelika Dąbrowska

30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.