Jak prawidłowo analizować plik slowlog PHP-FPM: skuteczne wykrywanie wąskich gardeł wydajności

Pokażę ci, jak Dziennik spowolnień PHP-FPM celowo analizujesz dane, prawidłowo interpretujesz ślady wykonania i na tej podstawie wyznaczasz jasne kroki zmierzające do zmniejszenia opóźnień. W ten sposób niezawodnie wykrywasz wąskie gardła wydajności, ustalasz priorytety działań i sprawiasz, że czasy ładowania stają się dla użytkowników odczuwalnie krótsze.

Punkty centralne

• Ślad kompilacji odczyt: Ramka #0 pokazuje aktualną klockę hamulcową.
• Limit czasu wybrać: najpierw ustawić na wysoki poziom, a następnie stopniowo obniżać.
• Korelacja z dziennikiem dostępu: pewna identyfikacja wolno działających adresów URL.
• Próbka liczyć: nadawać priorytet powtarzającym się funkcjom.
• Poprawki kodu wywnioskować: konkretne podejście do baz danych, interfejsów API, pętli i wtyczek.

Czym jest plik slowlog PHP-FPM?

W serwisie Slowlog w przypadku długich żądań zapisuje się Ślad kompilacji do pliku dziennika, rejestrując w ten sposób aktualny punkt wykonania bez przerywania żądania. Dzięki temu od razu widzę, który skrypt, jaki adres URL i która funkcja blokuje przepływ. Wpisy zawierają sygnaturę czasową, pulę, nazwę pliku skryptu, adres URI żądania oraz łańcuch wywołań funkcji. Dzięki temu slowlog wyraźnie różni się od klasycznych dzienników błędów, ponieważ dokumentuje wydajność, a nie błędy. W przypadku stron o dużym obciążeniu, takich jak zaplecze WordPressa, dostarcza on szybko przydatnych wskazówek dotyczących kosztownych zapytań, rozbudowanego renderowania lub blokujących operacji wejścia/wyjścia. Kto rozumie te migawki, może bardzo szybko Główna przyczyna określić zakres i zaplanować działania.

Tak działa Slowlog w codziennym życiu

Po włączeniu tej opcji PHP-FPM zapisuje, gdy przekroczony zostanie określony próg, plik Snapshot stosu do dziennika, podczas gdy żądanie jest nadal przetwarzane. Każdy wpis zaczyna się zazwyczaj od „#0“, czyli od miejsca, w którym właśnie dochodzi do utraty czasu. Pomiędzy blokami często dostrzegam puste wiersze, co ułatwia rozdzielenie zdarzeń. Metoda ta dostarcza próbki zamiast pełnych profili, ale za to zapewnia trafne wskazówki dotyczące rzeczywistych czynników spowalniających, takich jak rozbudowane ścieżki szablonów, osierocone haki lub powolne wywołania sieciowe. W fazach o dużym natężeniu ruchu łączę te wskazówki ze szczytami obciążenia, co pozwala mi na przejrzystą klasyfikację fragmentów kodu. Gdy tylko dostrzegam powtarzające się wzorce, dostosowuję na przykład pm.max_children i skorzystaj w tym celu z informacji zawartych w Prawidłowe ustawienie parametru pm.max_children.

Włączanie i konfigurowanie Slowlog

Włączam tę funkcję w odpowiedniej puli i ustalam ścieżkę, limit czasu oraz głębokość śledzenia, aby Ocena pozostaje w rozsądnych granicach. Następnie ponownie uruchamiam PHP-FPM i sprawdzam, czy plik dziennika jest zapisywalny z uprawnieniami użytkownika puli. Jako wartość początkową często ustawiam 5 sekund, aby najpierw wychwycić rażące odstępstwa, nie zalewając przy tym systemu danymi dziennika. Następnie stopniowo obniżam tę wartość, gdy tylko uporałem się z największymi problemami. Aby logi były przejrzyste, ograniczam głębokość śledzenia do 20–30 ramek, co w praktyce zazwyczaj wystarcza. W ten sposób utrzymuję Rozmiar pliku pod kontrolą i nie pomijam żadnych istotnych szczegółów.

Ustawienie	Cel	wartość początkowa	Uwagi
slowlog	Ścieżka do pliku dziennika	/var/log/php-fpm/www-slow.log	Sprawdź ścieżki w zależności od dystrybucji; uprawnienia do zapisu dla www-data zapewnić
request_slowlog_timeout	Próg dla prędkości „wolnej“	5 s	Najpierw wystartować wysoko, a potem obniżać (np. 2–3 s)
głębokość śledzenia dziennika spowolnień żądań	Maksymalna głębokość śladu odwrotnego	20–30	Dbaj o to, by ślady były czytelne, bez Najważniejsze informacje stracić

Znajdź plik dziennika i szybko go przejrzyj

Najpierw sprawdzam skonfigurowane ścieżki i otwieram plik dziennika za pomocą mniej lub sprawdź ostatnie wiersze za pomocą tail -40. Dzięki temu od razu widzę, czy pojawiają się nowe wpisy i które skrypty powtarzają się. Aby szybko zorientować się w sytuacji, zwracam uwagę na nazwy plików, powiązane pule oraz podejrzane adresy URI. Jeśli nie znajduję żadnych wpisów, aktywuję opcje w puli, odświeżam usługę i sprawdzam właścicieli oraz uprawnienia. W środowiskach zarządzanych sprawdzam również panel lub skrypty startowe, aby upewnić się, że dziennik spowolnień rzeczywiście działa równolegle.

Rozpoznawanie bloków i liczenie wzorów

Każdy wpis pojawia się w postaci bloku, często oddzielonego znakiem Pusta linia, co ułatwia liczenie. Kieruję się wierszami „#0“, ponieważ wskazują one aktualny punkt wykonania, w którym traci się czas. Za pomocą prostych potoków w powłoce wyodrębniam najważniejsze funkcje i sprawdzam, które miejsca najczęściej spowalniają działanie. W ten sposób celowo nadaję priorytet funkcjom, które łącznie pochłaniają najwięcej czasu. Następnie sprawdzam, czy te „gorące punkty” pojawiają się tylko w momentach szczytowego obciążenia, czy też stanowią problem przez cały czas. Ta klasyfikacja determinuje Sekwencja moich działań.

Przeglądanie wpisów: od ramki #0 do początku

Czytając wpisy, zaczynam od góry, od #0 i przechodzę krok po kroku w dół, aby zrozumieć ścieżkę od punktu wejścia do bieżącego miejsca. Długie łańcuchy szablonów wskazują na skomplikowane renderowanie, duża liczba hooków – na nadmiar wtyczek, a duża ilość zapytań SQL – na brak indeksów. Zaznaczam numery wierszy, nazwy funkcji i ścieżki do plików, aby móc szybko znaleźć kod. Jeśli stos wygląda na pętle oczekujące lub powtarzające się operacje, sprawdzam pamięć podręczną i buforowanie. Dzięki temu nie tracę czasu na Lokalizacja problemu w kodzie.

Korelacja Slowlogu z logami dostępu

Łączę Slowlog z logami serwera WWW, aby móc zidentyfikować powolne żądania konkretnego URL mogę przyporządkować. Na podstawie sygnatur czasowych i opcjonalnie identyfikatorów PID odnajduję odpowiednie wpisy w logach Nginx lub Apache. Dzięki temu rozpoznaję parametry, agenty użytkownika i czasy odpowiedzi poza PHP. Jeśli pojawiają się powtarzające się źródła wywołań lub identyczne ciągi zapytań, przeprowadzam test właśnie z tymi scenariuszami. W ten sposób szybko znajduję przypadki, które da się odtworzyć, i utrzymuję Czas analizy krótko mówiąc.

Stopniowe obniżanie wartości progowej

Zaczynam od szerokiego progu, najpierw usuwam największe Wartości odstające a następnie stopniowo zmniejszam. Taki sposób postępowania ogranicza objętość logów i pozwala mi skupić energię na wartościowych poprawkach. Po każdej rundzie optymalizacji wybieram niższy próg i ponownie zbieram zestawy danych. W ten sposób przechodzę od zgrubnej selekcji do precyzyjnego dostrajania, nie gubiąc się w szumie. Wynikiem tego są ukierunkowane poprawki i czysty Przegląd pozostałych wąskich gardeł.

Od „slowlogu” do rozwiązania: typowe sposoby naprawy

Jeśli górna ramka wyświetla funkcje bazy danych, sprawdzam zapytania SQL za pomocą WYJAŚNIENIE, dodaję brakujące indeksy i ograniczam zestawy wyników. W przypadku zdalnych usług skracam limity czasu, przetwarzam odpowiedzi asynchronicznie lub buforuję wyniki. Jeśli znajdę kosztowne pętle, upraszczam logikę, zmniejszam liczbę przebiegów i stosuję bardziej wydajne struktury. W WordPressie zaznaczam powtarzające się haki, wymieniam ciężkie rozszerzenia i stawiam na lżejszy motyw. Jeśli liczba procesów PHP blokuje przetwarzanie, monitoruję czasy oczekiwania i dodatkowo zapoznaję się z Ślady wykonania a także kolejki, na przykład za pośrednictwem Kolejkowanie żądań w PHP.

Praca ciągła: przejrzyste zarządzanie logami

Nie ustawiałem rejestracji na pełną moc na stałe, żeby Obciążenie wejść/wyjść pozostaje pod kontrolą. Zamiast tego pracuję etapami: najpierw aktywnie analizuję i optymalizuję, a potem wracam do umiarkowanego poziomu. Dzięki logrotate utrzymuję pliki w porządku i archiwizuję stare dane w postaci skompresowanej. Po zakończeniu analizy podnoszę próg lub tymczasowo wyłączam funkcję slowloggingu. Ponadto dokumentuję wnioski i poprawki, aby późniejsze audyty miały jasny ślad znaleźć.

Diagnoza hostingu: oddzielenie serwera od aplikacji

Duża liczba identycznych ramek Slowlog przy wysokim obciążeniu procesora wskazuje na Kod aplikacji, podczas gdy brakujące wpisy przy powolnej stronie wskazują raczej na problemy z wejściem/wyjściem, siecią lub serwerem bazy danych. W takich przypadkach porównuję TTFB, czasy PHP i opóźnienie upstream, aby zlokalizować wąskie gardło. Jeśli zauważę kolejki i długi czas oczekiwania przed wykonaniem, sprawdzam limity i liczbę procesów. Uzupełniam wtedy swoją diagnozę o informacje dotyczące przetwarzania żądań i biorę pod uwagę ewentualne limity, które spowalniają przetwarzanie. Aby uzyskać rzetelną ocenę sytuacji, oprócz logów analizuję również wskazówki dotyczące Prawidłowe ustawienie parametru pm.max_children lub artykuły dotyczące czasu oczekiwania, abym mógł Pojemność dostosuję to w sposób sensowny.

Przykład z praktyki: powolne działanie panelu administracyjnego WordPressa

Ustawiłem request_slowlog_timeout Najpierw ustawiam czas na 5 sekund, restartuję PHP-FPM i zbieram dane przez 30 do 60 minut przy rzeczywistym obciążeniu. Następnie zliczam najczęściej wywoływane funkcje „#0“ i szukam powtarzających się hooków lub kosztownych wywołań WP_Query. Jeśli pojawiają się usługi zewnętrzne, mierzę czasy odpowiedzi i celowo buforuję wyniki. Jeśli wyświetlanie stron jest spowalniane przez dostępy sesyjne, sprawdzam zachowanie blokad i, jeśli to możliwe, przenoszę operacje związane z sesją poza ścieżkę krytyczną. Szczególnie w przypadku logowania i działań administracyjnych testuję ustawienia i wyłączam powiadomienia. Blokowanie sesji PHP żeby mój Backend reaguje szybciej.

Projektowanie baz danych i prawa: solidna podstawa dla użytecznych slowlogów

Rozdzielam aplikacje na osobne baseny o jasnych nazwach (np. www, admin, api), ustaw jednoznaczne słuchać-gniazda i indywidualne slowlog-ścieżki. Dzięki temu łatwiej mi powiązać wpisy i uniknąć pomyłek. Ważna jest spójność Prawa do plików: Użytkownik puli (często www-data) musi mieć uprawnienia do zapisu w ścieżce logów i w katalogu. W konfiguracjach z kontenerami lub chroot sprawdzam, czy ścieżki istnieją w przestrzeni nazw i są trwałe – w przeciwnym razie logi znikną po ponownym uruchomieniu.

Szczegółowa analiza i automatyczna ocena wpisu w serwisie Slowlog

Zazwyczaj wpisy zaczynają się od sygnatury czasowej, puli, nazwy pliku skryptu i adresu URI żądania, a po nich następują ramki. Zliczam wiersze „#0“ i grupuję je według nazw funkcji, aby uwidocznić newralgiczne punkty. Za pomocą prostych operatorów pipe wyodrębniam elementy spowalniające:

grep -E "^#0|request.uri|script_filename" /var/log/php-fpm/www-slow.log | sed 's/  */ /g'

Albo wymienię najczęściej pojawiające się najlepsze klatki:

grep "^#0" /var/log/php-fpm/www-slow.log | awk -F": " '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head

Jeśli chcę dołączyć adres URL i plik, przygotowuję bloki za pomocą awk i zapisz mi najlepsze kombinacje funkcji, adresów URI i skryptów. W ten sposób ustalam priorytety poprawek, które przyniosą największe korzyści.

Mapa timeoutu: jak współdziałają Slowlog, PHP i serwer WWW

Aby postawić trafną diagnozę, zlecam wszystkie Limity czasu: request_slowlog_timeout uruchamia migawkę, max_execution_time ogranicza czas działania PHP w skrypcie, request_terminate_timeout może wymusić zamknięcie procesu FPM. Po stronie serwera WWW należy fastcgi– lub. proxy-limity czasu (np. fastcgi_read_timeout) oraz limity czasu po stronie klienta. Jeśli ustawię slowlog powyżej w przypadku przekroczenia limitu czasu serwera, tracę dane; jeśli w tym, uzyskuję przydatne migawki, zanim żądania przestaną napływać. Dlatego celowo zachowuję następującą kolejność: limit czasu serwera WWW > zakończenie działania PHP > dziennik spowolnień > opóźnienie docelowe.

Uwzględnienie statusu FPM, kolejki i zarządzania procesami

Slowlog pokazuje, gdzie traci się czas – status FPM wskazuje, dlaczego Czekają zapytania. Aktywuję punkt końcowy stanu, obserwuję bezczynność, aktywny oraz kolejka odsłuchu i porównuję je z sygnaturami czasowymi ze slowlogu. Jeśli kolejka rośnie, podczas gdy wielu pracowników utknie w tych samych funkcjach, to wąskim gardłem jest kod; jeśli kolejka rośnie bez wzrostu wpisów w slowlogu, oznacza to brak wydajności lub spowolnienie ze strony elementów wyższych w łańcuchu. Na tej podstawie dostosowuję pm-Ustawienia (dynamiczne/na żądanie), pm.max_children i w razie potrzeby. pm.max_requests, aby wykrywać wycieki pamięci lub fragmentację.

Szczególne cechy w kontenerach i środowiskach zarządzanych

W środowisku Docker/Kubernetes FPM często zapisuje logi w stdout/stderr lub do ścieżek gromadzonych przez agregatory logów. Świadomie decyduję się na a Aby uniknąć powtórzeń lub braków w wpisach. Z error_log = /proc/self/fd/2 oraz dedykowanym slowlog-W przypadku ścieżki wskazującej na wolumin trwały migawki pozostają dostępne. W konfiguracjach zarządzanych sprawdzam, czy dostawca usług hostingowych włączył lub ograniczył funkcję slowlogów – i dostosowuję interwały, aby nie kolidować z rotacjami.

Ochrona danych i bezpieczeństwo: logi bez ryzyka

Ślady wykonania mogą zawierać poufne Parametry, ścieżki do plików lub identyfikatory sesji. Minimalizuję ryzyko, zapisując ciągi zapytań w logach dostępu, wyłączając komunikaty debugowania w kodzie oraz ograniczając krąg osób uprawnionych do wglądu. W przypadku wymiany danych z podmiotami zewnętrznymi anonimizuję ścieżki i usuwam tokeny. W środowiskach produkcyjnych ustalam krótkie okresy przechowywania danych oraz wdrażam rotację i kompresję logów w całym systemie.

WordPress: szybkie rozpoznawanie powtarzających się wzorców

• WP_Query/WP_Meta_Query: Brak indeksów w postmeta lub jeśli filtrowanie odbywa się według pól nieindeksowanych, czas wykonania gwałtownie wzrasta. Ograniczam zapytania meta, korzystam z taksonomii lub tworzę ukierunkowane indeksy.
• Stany przejściowe i pamięć podręczna obiektów: Liczne podobne obliczenia wskazują na brak trwałej pamięci podręcznej. Włączam pamięć podręczną obiektów, optymalizuję klucze pamięci podręcznej i czasy TTL.
• Hooki/filtry: Długie łańcuchy w stosie wskazują na zbędne wtyczki. Sprawdzam najdroższe punkty zaczepienia i usuwam lub zastępuję rozszerzenia.
• Żądania HTTP: Wewnętrzne wywołania API (wp_remote_get) powinny korzystać z limitów czasu, funkcji keep-alive i buforowania; w miarę możliwości odpowiedzi nie powinny blokować wątku żądania.
• Renderowanie szablonów: Głębokość get_template_part-Kaskady z dostępem do plików korzystają z buforowania i mniejszej fragmentacji.

Jak uniknąć błędnych interpretacji: czego nie pokazuje Slowlog

Snapshot to Migawka. Nie opisuje on całego cyklu życia żądania, lecz stan w momencie jego wywołania. Typowe pułapki:

• Błąd selekcji próby: Rzadkie, ale niezwykle kosztowne ścieżki mogą zostać utracone, jeśli limit czasu jest zbyt niski lub faza była krótka.
• Wywołania systemowe powodujące zablokowanie: fopen, stat lub operacje wyszukiwania adresów DNS są przedstawiane jako funkcje PHP, podczas gdy rzeczywisty czas oczekiwania ma miejsce w jądrze systemu lub w sieci.
• Automatyczne ładowanie: Wiele małych plików dołączanych bez Opcache powoduje straty rozproszone, które w stosie wydają się niegroźne. Sprawdzenie wskaźnika trafień Opcache pomaga w ocenie sytuacji.

Śledzenie CLI, Cron i webhooków

Nie wszystkie problemy z wydajnością wynikają z działania FPM. Ciężkie Cronjobs (np. wp-cron), procesy kolejkowe lub webhooki blokują procesor, operacje wejścia/wyjścia lub bazę danych, co pośrednio pogarsza czasy odpowiedzi. Izoluję takie obciążenia w osobnych procesach, planuję je poza godzinami szczytu i sprawdzam, czy działają one za pośrednictwem HTTP wyzwalanego przez FPM zamiast CLI – w przeciwnym razie zniekształca to obraz w slowlogu.

Wdrażanie rotacji logów w praktyce

Aby zapobiec nadmiernemu rozrostowi plików slowlog, często je rotuję i kompresuję starsze zapisy. Typowa rotacja zachowuje kilka generacji, sygnalizuje FPM konieczność ponownego otwarcia i pozwala uniknąć luk. Ważne: po rotacji należy ponownie uruchomić FPM (HUP), aby nowe wpisy nie trafiały w otchłań. Konkretne ustawienia dostosowuję do ruchu, limitu czasu i głębokości śledzenia.

Lista kontrolna zapewniająca szybkie wyniki

• Włącz Slowlog dla każdego puli, sprawdź ścieżki i uprawnienia.
• Uruchom na 5 sekund, zbierz dane, policz najlepsze klatki.
• Korelacja z logami dostępu: znacznik czasu, URI, User-Agent.
• Należy sprawdzić limity czasu serwerów upstream i serwerów WWW.
• Monitorowanie stanu FPM i kolejki, pm-Dostosuj limity.
• Najpierw należy usunąć wąskie gardła: indeksy SQL, buforowanie, kosztowne haki, operacje we/wy.
• Stopniowo zmniejszać czas oczekiwania, a następnie ponownie dokonać pomiaru.
• Rotacja logów, dokumentowanie wniosków, śledzenie zmian.

W skrócie: Twoja droga do lepszych wyników

Włączam Slowlog, czytam Najlepsze ramki, porównuję dane z logami dostępu i najpierw eliminuję największe wartości odstające. Następnie obniżam próg, sprawdzam powtarzające się wzorce i wprowadzam ukierunkowane poprawki w kodzie, konfiguracji i buforowaniu. Dzięki rotacji logów i umiarkowanym limitom czasu utrzymuję niskie obciążenie systemowe. W przypadku WordPressa skupiam się na kosztownych zapytaniach, wtyczkach, hookach i ewentualnych blokadach sesji. W ten sposób niezawodnie znajduję prawdziwe Wąskie gardła i zapewnia zauważalnie szybsze odpowiedzi.