Przed zmianą wtyczek, motywu lub kodu sprawdź 15 limitów zasobów serwera. Analizuj CPU, RAM, PHP, I/O, dysk i bazę danych. Wykonuj pomiary w kilku punktach czasu i zapisuj datę, godzinę, obciążenie oraz komunikaty o limitach. Powtarzalne wyniki pomagają odróżnić problem aplikacji od przeciążenia hostingu.
Spis treści
Jak przygotować powtarzalny audyt zasobów
Wybierz okres, w którym strona działa wolno albo zwraca błędy. Zapisz odczyty z czasu normalnego ruchu, szczytu oraz wystąpienia problemu. Dla każdego parametru zanotuj:
- datę i godzinę pomiaru,
- wartość odczytu,
- informację o osiągnięciu limitu lub throttlingu,
- adres strony albo zadanie, które działało w tym czasie.
Nie wyciągaj wniosków z jednego krótkiego skoku. Powtarzające się odczyty w czasie spowolnienia są bardziej przydatne niż pojedynczy pomiar.
15 limitów do sprawdzenia
- Wykorzystanie CPU. Sprawdź, czy procesor jest długo obciążony. Utrzymujące się użycie CPU powyżej 80% w czasie szczytu oraz częste skoki do 100% są sygnałem przeciążenia. Mogą też powodować wzrost wartości load average, czyli średniego obciążenia systemu.
- Throttling CPU. Sprawdź, czy system ogranicza czas procesora przydzielony stronie. Powtarzające się ograniczenia w tym samym czasie co spowolnienia wskazują, że aplikacja nie otrzymuje pełnej dostępnej mocy CPU.
- Load average. Zapisz wartość obciążenia systemu razem z użyciem CPU. Wysokie load average przy częstych skokach CPU do 100% oznacza, że procesy konkurują o czas procesora.
- Pamięć RAM. Sprawdź, czy zużycie pamięci rośnie do limitu podczas ładowania strony, importu danych lub pracy z panelem CMS. Powtarzające się zbliżenie do limitu wskazuje na presję pamięci, a niekoniecznie na błąd wtyczki.
- Swap. Zobacz, czy system korzysta z pamięci wymiany. Jeśli użycie swapu pojawia się razem ze spowolnieniem, sprawdź najpierw pamięć RAM i procesy działające w tym samym czasie.
- Procesy PHP. Sprawdź liczbę aktywnych procesów PHP. Jeżeli procesy pozostają zajęte, nowe żądania mogą czekać na wykonanie. Zapisz, czy sytuacja powtarza się przy konkretnych adresach lub zadaniach.
- PHP workers. Sprawdź limit równoległych pracowników PHP, czyli procesów obsługujących żądania skryptów. Osiąganie limitu podczas ruchu oznacza, że kolejne żądania mogą oczekiwać na wolnego workera.
- Entry processes. Sprawdź liczbę jednocześnie rozpoczynanych żądań. Wartość przy limicie może wskazywać na nagły ruch, ciężkie żądania albo zadania wykonywane w tle.
- Połączenia równoległe. Zapisz liczbę aktywnych połączeń do serwera. Stały wzrost podczas niedostępności lub opóźnień wymaga porównania z ruchem oraz procesami PHP.
- Disk I/O. Sprawdź wykorzystanie operacji wejścia i wyjścia dysku. Długi czas wysokiego I/O może opóźniać odczyt plików, zapis sesji oraz operacje bazy danych.
- I/O wait. Zapisz czas oczekiwania procesora na operacje dyskowe. Wysoki odczyt przy jednoczesnym wzroście Disk I/O kieruje diagnostykę w stronę operacji na dysku, a nie samego kodu strony.
- Przestrzeń dyskowa. Sprawdź zajęte miejsce na pliki, kopie, logi i dane aplikacji. Zbliżanie się do limitu może utrudnić zapis nowych danych i plików tymczasowych.
- Inody. Sprawdź liczbę plików i katalogów. Limit inodów może zostać osiągnięty także wtedy, gdy pozostała przestrzeń dyskowa nie jest całkowicie zajęta. Szczególną uwagę zwróć na dużą liczbę małych plików.
- Transfer i przepustowość. Porównaj bieżący transfer z okresem szczytowego ruchu. Nietypowy wzrost może wynikać z większej liczby odwiedzin, dużych plików albo intensywnej pracy w tle. Zapisz godzinę i czas trwania zdarzenia.
- Obciążenie bazy danych i zadania cykliczne. Sprawdź, czy wzrost zapytań do bazy występuje razem z wolniejszą stroną. Zapisz także godziny zadań cyklicznych, takich jak importy, aktualizacje lub generowanie raportów. Jeśli spowolnienia powtarzają się o tych samych porach, porównaj oba pomiary.
Jak odróżnić problem CMS od problemu zasobów
Jeśli CPU, pamięć, PHP workers, procesy wejściowe, I/O lub transfer zbliżają się do limitu w czasie problemu, najpierw przeanalizuj obciążenie serwera. Jeżeli zasoby pozostają stabilne, a opóźnienia dotyczą tylko określonej funkcji, adresu lub zadania CMS, sprawdź tę część aplikacji.
Porównuj zawsze te same przedziały czasu. Sam fakt wystąpienia błędu nie pokazuje jeszcze jego przyczyny. Znaczenie ma zgodność czasowa: limit powinien pojawić się w tym samym okresie co spowolnienie, błąd lub niedostępność.
Co zrobić po audycie
- Optymalizuj stronę, gdy zasoby nie są stale wyczerpane, a problem wiąże się z konkretną funkcją, zapytaniem lub zadaniem CMS.
- Ogranicz ruch lub pracę w tle, gdy skoki występują podczas importów, raportów, zadań cyklicznych albo nietypowego wzrostu odwiedzin.
- Skontaktuj się z dostawcą hostingu, gdy powtarzają się throttling, osiąganie limitów lub wysokie I/O. Przekaż znaczniki czasu i zapisane wartości.
- Rozważ zwiększenie zasobów, gdy obciążenie jest powtarzalne, wynika z rzeczywistego ruchu i nie znika po ograniczeniu pracy w tle oraz optymalizacji aplikacji.
W Elastycznym Web Hostingu zasoby mogą dopasowywać się do aktualnego ruchu i obciążenia strony. Przy większym ruchu system może zwiększać moc CPU, pamięć RAM i przestrzeń, a po spadku obciążenia wracać do poziomu bazowego. Odczyty z kilku momentów nadal są potrzebne, aby ustalić, czy problem ma charakter aplikacyjny, czy wynika z powtarzającego się zapotrzebowania na zasoby.