Proszę odnotować czas szczytu i porównać CPU, pamięć, PHP workers, bazę danych oraz access log. Żądania należy pogrupować według URL, statusu, IP lub user agenta i sprofilować najbardziej kosztowny scenariusz. Trzeba ograniczyć szkodliwe źródło, poprawić zapytanie lub zadanie, skonfigurować cache, a dopiero potem podjąć decyzję o zwiększeniu zasobów.
Wysokie użycie CPU lub pamięci przez WordPress to nie diagnoza, lecz sygnał, że serwer wykonuje więcej pracy, niż jest w stanie lub niż powinien. Przyczyną może być legalny ruch, bot, nieudany cron, wolne zapytanie, zewnętrzny timeout, generowanie obrazów lub nieskończona pętla. Natychmiastowy upgrade serwera może dać trochę czasu, ale bez pomiarów ten sam problem powróci na większą skalę.
Dochodzenie łączy przebieg czasowy infrastruktury z access logiem, procesami PHP, bazą danych i zdarzeniami aplikacji. Trzeba ustalić, czy źródłem jest wiele tanich żądań, czy kilka skrajnie kosztownych. Po ustabilizowaniu sytuacji przygotowuje się reprodukcję i poprawkę, a następnie odpowiedni zapas pojemności. Poniższa procedura jest read-only tam, gdzie najpierw zbiera się dowody.
Określ czas, źródło i rodzaj wyczerpania
Warto przejrzeć wykresy CPU, pamięci, load average, dyskowego I/O, swapu, połączeń z bazą danych i workerów PHP w tej samej strefie czasowej. Krótki szczyt po wdrożeniu różni się od stopniowego wycieku pamięci czy codziennego zadania cron. Należy odnotować początek, czas trwania i powrót do normy. Trzeba też sprawdzić ewentualne limity hostingu i throttling.
Odróżnij wyczerpanie zasobów PHP od problemów z bazą danych, serwerem WWW lub połączeniem zewnętrznym. Pełna kolejka workerów może wynikać z tego, że każdy z nich czeka na API, a nie z braku procesów. Zdarzenie OOM może zabić proces bez czytelnego błędu WordPressa. Dlatego logi serwera i systemu należą do danych aplikacyjnych.
Pogrupuj żądania z access logu
Dla obserwowanego okna czasowego ustal najczęstsze URL, metody, kody statusu, adresy źródłowe, user agenty i czas odpowiedzi. Duży wolumen żądań do logowania, XML-RPC, wyszukiwania, endpointu REST lub losowe błędy 404 mogą sygnalizować automatyzację. Nie blokuj legalnej wyszukiwarki wyłącznie na podstawie nazwy user agenta; w miarę możliwości weryfikuj zachowanie i pochodzenie.
Wolny URL o małej liczbie wywołań może zużywać tyle samo zasobów co wiele szybkich. Monitoruj percentyle czasu i rozmiar odpowiedzi, a nie tylko liczbę. W przypadku cache rozróżniaj hit i miss. Dodaj identyfikator korelacji, jeśli request trafia dalej do kolejki lub zewnętrznego API. Logi redaguj i przechowuj w odpowiednim zakresie, ponieważ URL może zawierać wrażliwy parametr.
- URL i metoda
- Liczba, czas i status odpowiedzi
- Cache hit lub miss
- Bot, użytkownik czy zaplanowane zadanie
Profiluj PHP, bazę danych i wywołania zewnętrzne
Na stagingu lub za pomocą bezpiecznego profilera produkcyjnego należy ustalić funkcje, hooki i wtyczki zużywające czas i pamięć. Warto obserwować powtarzające się zapytania, duże kolekcje bez paginacji i pętle po metadanych. Slow log bazy danych pokaże zarówno zapytanie, jak i plan wykonania. Nie należy optymalizować wyłącznie pliku widocznego na szczycie stosu, jeśli jedynie czeka on na głębszą zależność.
Zewnętrzne wywołania HTTP powinny mieć timeout i nie mogą blokować każdego wyświetlenia. Wynik proszę cache’ować lub przenieść synchronizację do kolejki. Podczas importu należy przetwarzać partie z punktami kontrolnymi (checkpoint), a nie cały katalog w jednym żądaniu. Proszę nie zwiększać limitu pamięci jako jedynej poprawki, dopóki nie wiadomo, czy obiekt rośnie zasadnie, czy wycieka w nieskończonej pętli.
Ustabilizuj działanie bez utraty dowodów
Podczas aktywnego incydentu można wprowadzić rate limit dla konkretnego nadużywanego endpointu, włączyć przygotowaną pamięć podręczną, wstrzymać wadliwe zadanie lub tymczasowo ograniczyć kosztowną funkcję. Każde działanie musi mieć właściciela i warunek wycofania. Całkowite zablokowanie całego ruchu lub restartowanie w pętli może ukryć wzorzec i zaszkodzić zamówieniom.
Przed zakończeniem procesu proszę zachować logi, metryki i stan kolejki. W przypadku błędu crona lub Action Schedulera nie należy podejmować kolejnych ręcznych prób bez idempotencji. Jeśli zwiększą Państwo liczbę workerów, trzeba monitorować połączenia z bazą danych i pamięć; większa współbieżność może przyspieszyć awarię. Należy poinformować zespół operacyjny, która funkcja jest tymczasowo ograniczona.
- Ukierunkowany rate limit
- Tymczasowe wstrzymanie błędnego hooka
- Zachowane metryki i logi
- Czasowo ograniczony środek awaryjny
Napraw przyczynę źródłową i ustaw rezerwę przepustowości
Poprawką może być indeks, paginacja, usunięcie zduplikowanego hooka, cache obiektowy, krótszy timeout lub przeniesienie pracy do kolejki. Porównajcie ten sam scenariusz przed interwencją i po niej oraz przeprowadźcie test funkcjonalny. Test obciążeniowy wykonujcie w odpowiednim środowisku, z realistyczną mieszanką żądań i po uzgodnieniu z dostawcą, a nie w sposób niekontrolowany na produkcji.
Dopiero po optymalizacji ustal liczbę workerów, pamięć i skalowanie na podstawie zwykłego ruchu i oczekiwanego szczytu. Monitoring powinien ostrzegać o trendzie, zanim zostanie osiągnięty twardy limit, a runbook łączy metrykę z pierwszymi krokami kontrolnymi. Po incydencie zapisz przyczynę, skutki, czas wykrycia i działanie zapobiegawcze. Zasoby i wydajny kod uzupełniają się, a nie zastępują.
Najczęstsze pytania
Czy pomoże zwiększenie PHP memory_limit?
Może tymczasowo pozwolić dokończyć uzasadnione, wymagające zadanie, ale nie rozwiąże nieskończonej pętli, dużego nieograniczonego zapytania ani wycieku. Najpierw należy zmierzyć, co zajmuje pamięć, a zwiększenie limitu zweryfikować w odniesieniu do wydajności wszystkich workerów.
Jak sprawdzić, czy CPU zużywa bot?
W godzinach szczytu proszę pogrupować access log według URL, IP, user agenta, liczby żądań i czasu odpowiedzi. Proszę sprawdzić, czy żądania omijają cache i mają zautomatyzowany wzorzec. User agent można sfałszować, dlatego warto korzystać z wielu sygnałów.
Czy rozwiązaniem jest wydajniejszy hosting?
Jeśli zwykłe, uzasadnione obciążenie przekracza dostępną wydajność – tak. W przypadku błędu w kodzie lub ataku jedynie odsunie to osiągnięcie limitu i zwiększy koszty. Najpierw należy ustabilizować system i go sprofilować, a następnie połączyć optymalizację z odpowiednią rezerwą.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
