Planowanie wydajności PHP-FPM: obliczanie liczby procesów roboczych, pamięci RAM i liczby jednoczesnych żądań

Co ogranicza proces roboczy PHP-FPM

PHP-FPM zarządza procesami PHP w pulach. Jeden Pracownik przetwarza po jednym zapytaniu; ustawienie puli pm.max_children ogranicza liczbę jednocześnie dostępnych procesów roboczych, a tym samym liczbę żądań PHP przetwarzanych jednocześnie przez tę pulę. W przypadku wielu pul ograniczenie to dotyczy danej puli, a nie automatycznie całego serwera.

Liczba ta nie odnosi się ani do liczby zalogowanych użytkowników, ani nie stanowi bezpośredniej wartości liczby żądań na sekundę. Jeden użytkownik może generować wiele żądań, podczas gdy zalogowany użytkownik nie zajmuje procesora między dwiema czynnościami. Z drugiej strony pojedyncze, wolno działające żądanie może zajmować procesor dłużej niż kilka krótkich żądań następujących po sobie.

Nie każde wywołanie strony dociera do PHP-FPM. Jeśli serwer WWW bezpośrednio dostarcza plik statyczny lub jeśli pamięć podręczna umieszczona przed serwerem w pełni obsługuje żądanie, w zależności od architektury nie jest do tego potrzebny procesor PHP. Z kolei nieudane próby odczytu z pamięci podręcznej, zalogowani użytkownicy oraz strony administracyjne mogą nadal generować żądania PHP i tymczasowo zwiększać obciążenie.

Dlatego też dla planowania wydajności kluczowe znaczenie mają dwie odrębne kwestie: ilu workerów zmieści się wraz z rezerwą w dostępnej pamięci RAM? I ilu workerów faktycznie potrzeba do obsługi ruchu napływającego do puli, aby żądania nie czekały zbyt długo? Wysoka wartość dla pm.max_children nie odpowiada samodzielnie na żadne z tych pytań.

Nawet jeśli dostępna jest wystarczająca ilość pamięci, procesor, baza danych lub usługi zewnętrzne mogą ograniczać rzeczywistą pojemność. Dodatkowe procesy robocze umożliwiają wprawdzie wykonywanie większej liczby zadań PHP równolegle, ale mogą jednocześnie zwiększyć obciążenie już i tak wolnej usługi. Wartość puli stanowi zatem limit operacyjny, a nie gwarancję wydajności.

Zrozumienie roli menedżera procesów i kolejki

Der Kierownik ds. procesów określa, kiedy PHP-FPM uruchamia procesy robocze. W przypadku static czy liczba procesów w rezerwie odpowiada wartości pm.max_children. Dzięki temu można dobrze zaplanować liczbę procesów, ale jednocześnie angażuje to zasoby nawet przy niewielkim obciążeniu. Sam limit musi nadal być dostosowany do dostępnej pamięci.

Na stronie dynamic FPM dostosowuje liczbę procesów: dodatkowo ustawia się liczbę początkową oraz minimalną i maksymalną liczbę wolnych procesów. W przypadku ondemand Procesy typu „worker” są uruchamiane dopiero w razie potrzeby i są zamykane po upływie skonfigurowanego czasu bezczynności. Pozwala to oszczędzać zasoby w przypadku rzadko wykorzystywanych pul; jednak w przypadku nagłego wzrostu obciążenia konieczne jest najpierw uruchomienie nowych mocy obliczeniowych.

Jeśli wszyscy pracownicy są zajęci, kolejne zapytania mogą być kierowane do Kolejka słuchaczy czekać na wolny proces. Status FPM pokazuje między innymi aktualną i maksymalną długość kolejki. Jednak sama wysoka wartość maksymalna nie pozwala stwierdzić, czy pula jest w danej chwili przeciążona; do tego potrzebny jest kontekst czasowy.

Dłuższa kolejka nie tworzy dodatkowych procesów roboczych ani nie przyspiesza działania wolnej bazy danych. Może ona tymczasowo przyjmować zapytania, ale jedynie przesuwa czas oczekiwania na etap poprzedzający przetwarzanie w PHP. Dlatego przy wyborze menedżera procesów należy wziąć pod uwagę zarówno typowy przebieg obciążenia, jak i skutki krótkotrwałych szczytów obciążenia.

Prawidłowe przypisanie pamięci typu „worker”

Wymagania pamięciowe jednego pracownika nie da się wiarygodnie określić wyłącznie na podstawie limitu konfiguracyjnego PHP. Do celów planowania bardziej przydatne są dane dotyczące procesów w odpowiednich warunkach obciążenia. Istotne jest przy tym, czy analizujesz pamięć rezydentną pojedynczego procesu, czy też chcesz oszacować zużycie pamięci przez całą grupę pracowników PHP-FPM.

RSS opisuje pamięć rezydentną procesu. Jeśli kilka procesów roboczych korzysta z tych samych stron pamięci, mogą one znajdować się w ich odpowiednich wartościach RSS. Jeśli zsumujesz wartości RSS wszystkich procesów roboczych, wspólnie używane strony mogą w niektórych przypadkach pojawić się wielokrotnie; suma ta nie stanowi zatem dokładnego odzwierciedlenia wspólnie zajmowanej pamięci fizycznej.

PSS rozdziela strony współużytkowane proporcjonalnie między uczestniczące procesy. Suma wartości PSS w grupie procesów jest zatem często bardziej przydatna do planowania pamięci niż suma wartości RSS. Pozostaje to jednak jedynie obrazem sytuacji w danym momencie: jeśli zmieni się liczba procesów współużytkujących strony, zmieniają się również ich odpowiednie udziały.

Rozważmy kilka procesów roboczych w przypadku typowych, a także żądania wymagających dużej ilości pamięci. Świeżo uruchomiony proces lub pojedyncza średnia mogą nie odzwierciedlać rzeczywistego zapotrzebowania w przyszłości. Całkowita wartość PSS puli przy różnych liczbach procesów roboczych i stanach obciążenia pomaga uzyskać ostrożne przybliżenie; ekstrapolacja na większą liczbę procesów roboczych pozostaje niepewna ze względu na zmienne udziały wspólne i prywatne.

PHP-memory_limit nie stanowi wiarygodnego wskaźnika całkowitej pamięci systemu operacyjnego zajmowanej przez proces FPM i nie zastępuje tej obserwacji. Pamięci współdzielonej, np. przez OPcache, nie należy ogólnie odejmować po raz drugi od limitu, jeśli jest ona już uwzględniona proporcjonalnie w wykorzystywanej puli PSS. Należy jednak uwzględnić inne usługi oraz rezerwę.

Obliczanie budżetu pamięci RAM i liczby pracowników

Punktem wyjścia jest faktycznie dostępna pamięć RAM: na hoście jest to pamięć dostępna dla usług, a w kontenerze – efektywny limit pamięci. Należy od tego odjąć zapotrzebowanie systemu operacyjnego, serwera WWW, ewentualnej lokalnej bazy danych oraz innych usług. W obliczeniach należy również uwzględnić inne pule FPM oraz rezerwę na wahania zużycia.

Pozostała część to Budżet na basen. Aby oszacować wartość dla pracownika, obserwuj sumę PSS pracowników w puli przy różnych liczbach procesów i stanach obciążenia. Weź pod uwagę zarówno typowe zapytania, jak i punkty końcowe wymagające dużej ilości pamięci. Podziel daną sumę przez rozpatrywaną liczbę pracowników i na podstawie kilku obserwacji wyznacz ostrożną wartość przybliżoną.

Poniższe obliczenia stanowią przykład ilustrujący sposób obliczeń, a nie wynik pomiaru. Przyjęte wartości służą wyłącznie do zilustrowania sposobu obliczeń; nie stanowią one zalecenia dotyczącego konkretnego zastosowania. Wynik jest zaokrąglany w dół do liczby całkowitej pracowników.

25 procesów typu „worker” nie gwarantuje bezpiecznego przydziału pamięci. System PSS rozdziela strony współdzielone proporcjonalnie, a ich liczba zmienia się wraz z liczbą procesów, które je współdzielą. Również inny skład żądań może wpłynąć na zapotrzebowanie na pamięć prywatną; dlatego też prognozę należy zweryfikować w odniesieniu do obserwowanego całkowitego zużycia i obowiązującego limitu.

Jeśli pamięć współdzielona, taka jak OPcache, jest już uwzględniona proporcjonalnie w wykorzystanej sumie PSS, nie należy jej ponownie odliczać ryczałtowo jako pełnej pozycji dodatkowej. Należy jednak uwzględnić rezerwę na te części pamięci, które nie zostały uwzględnione w analizie. Zwłaszcza w przypadku limitu kontenerów liczy się ostatecznie zużycie wszystkich procesów w ramach tego limitu, a nie tylko szacowana suma procesów roboczych.

Sam nowo uruchomiony procesor nie stanowi wystarczającej podstawy do oceny: być może nie przetworzył jeszcze żadnego wymagającego żądania. Dlatego należy porównać kilka momentów i odnotować, które punkty końcowe oraz ile procesów roboczych było w każdym z nich zaangażowanych. W ten sposób można sprawdzić, czy wybrana wartość przybliżona sprawdza się również w mniej korzystnych, ale realistycznych warunkach pracy.

Oszacowanie liczby potrzebnych pracowników na podstawie zapytań

Obliczenia dotyczące pamięci RAM określają, ilu pracowników prawdopodobnie zmieści się w puli. Natomiast zapotrzebowanie zależy od tego, ile żądań PHP faktycznie napływa do danej puli i jak długo zajmują one jednego pracownika. Jako pierwsze przybliżenie przyjmuje się: średnia liczba pracowników zajętych jednocześnie równa się liczbie żądań PHP na sekundę pomnożonej przez średni czas zajętości pracownika w sekundach.

Przykład obliczeniowy o charakterze ilustracyjnym, nieoparty na pomiarach: Przy założeniu 20 żądań PHP na sekundę i średnim czasie obsługi wynoszącym 0,25 sekundy średnio zajętych jest pięciu pracowników. Jest to średnia z rozpatrywanego okresu. Nie oznacza to ani tego, że zawsze działa dokładnie pięć procesów, ani tego, że pięć procesów wystarczy jako limit puli na krótkie okresy szczytowego obciążenia.

Licząc liczbę zapytań, nie należy uwzględniać wszystkich wyświetleń stron bez weryfikacji. Jeśli pamięć podręczna dostarcza wiele odpowiedzi bez wywoływania PHP, trafienia te nie obciążają puli. Z drugiej strony, nieudane próby odczytu z pamięci podręcznej, zalogowani użytkownicy oraz dostępy administracyjne mogą czasami generować większe obciążenie dla PHP, niż sugerowałaby średnia z całego dnia.

Die Czas pracy pracownika obejmuje również czasy oczekiwania w trakcie przetwarzania, na przykład na odpowiedź z bazy danych lub serwisu zewnętrznego. Nie należy jej automatycznie utożsamiać z czasem odpowiedzi widocznym w przeglądarce. Zgodnie z fastcgi_finish_request() PHP może już zakończyć wysyłanie odpowiedzi do klienta, a mimo to nadal wykonywać kolejne zadania w procesie roboczym.

Aby zapewnić akceptowalne czasy oczekiwania, potrzebujesz rezerwy powyżej średniego obciążenia. To, jak duża musi być ta rezerwa, zależy między innymi od wahań obciążenia, powolnych punktów końcowych oraz pożądanego docelowego czasu odpowiedzi. Pomnożenie szczytowej liczby żądań na sekundę przez wysoki percentyl opóźnienia może stanowić ostrożną analizę scenariusza, nie jest jednak precyzyjną prognozą dotyczącą kolejki.

Dlatego należy rozpatrywać poszczególne okresy osobno: krótki szczyt aktywności i spokojny ruch nocny mogą dać tę samą średnią dzienną, co bardziej równomierny ruch, ale stawiają różne wymagania. Jeśli czas zajętości wzrasta z powodu powolnego działania zaplecza, przy tej samej częstotliwości przybywania rośnie również średnia liczba zajętych pracowników. Zapotrzebowanie nie jest zatem wyłącznie funkcją natężenia ruchu odwiedzających.

Pobieranie ustawień puli z planu

Porównaj teraz górną granicę opartą na pamięci RAM z szacowanym zapotrzebowaniem, uwzględniając margines bezpieczeństwa. Jeśli zapotrzebowanie mieści się poniżej tej granicy, wybierz ostrożną wartość początkową dla pm.max_children, który nie musi wykorzystywać całego budżetu. W podanym przykładzie 25 stanowiłoby teoretyczny limit pamięci RAM, ale niekoniecznie byłoby to odpowiednie ustawienie; procesor i backend mogą wprowadzić ograniczenia już wcześniej.

Jeśli szacowane zapotrzebowanie przekracza limit pamięci RAM, zwiększenie tego limitu nie rozwiąże sprzeczności: może to spowodować obciążenie pamięci hosta lub kontenera. Z drugiej strony bardzo niski limit może powodować opóźnienia w obsłudze żądań. W takim przypadku należy na przykład poprawić czas wykonania lub wykorzystanie pamięci podręcznej oraz sprawdzić, czy konieczne jest zwiększenie zasobów lub ograniczenie obciążenia wejściowego.

Na stronie dynamiczny Oprócz górnego limitu należy określić liczbę początkową oraz minimalną i maksymalną liczbę wolnych procesów. Wartości początkowe i rezerwowe powinny być dostosowane do przewidywanego obciążenia i mieścić się w ramach limitu górnego. Zbyt mała rezerwa mocy obliczeniowej może w przypadku nagłego wzrostu obciążenia oznaczać konieczność uruchomienia dodatkowych procesów; z kolei stała obecność dużej liczby wolnych procesów zużywa zasoby.

Na stronie na żądanie Workery są tworzone dopiero w razie potrzeby; czas bezczynności do momentu ich zakończenia ustawia się osobno. Może to być przydatne w przypadku rzadko wykorzystywanych pul, wymaga jednak szczególnej uwagi w przypadku gwałtownych wzrostów obciążenia. Również w tym przypadku ogranicza pm.max_children liczba pracowników z puli dostępnych jednocześnie.

Kilka stron internetowych na tym samym serwerze nie otrzymuje niezależnie od siebie całej dostępnej pamięci RAM. Należy rozplanować ich potencjalne maksymalne limity puli wraz z pozostałymi usługami i rezerwą. Dodatkowo może obowiązywać ewentualnie skonfigurowany globalny limit procesów FPM, który jednak nie zastępuje ani poszczególnych limitów puli, ani weryfikacji wydajności procesora i bazy danych.

Po wprowadzeniu zmian sprawdź rzeczywiste obciążenie i czasy oczekiwania w odpowiednich przedziałach czasowych, zamiast traktować wartość początkową jako ostateczną. W przypadku hostingu zarządzanego dane procesowe lub ustawienia puli mogą nie być bezpośrednio dostępne; w takim przypadku należy skorzystać z wskaźników i udostępnionych opcji dostawcy. Dostępność poszczególnych ustawień zależy również od wersji PHP i środowiska operacyjnego.

Monitorowanie stanu FPM i pamięci

Strona stanu FPM pokazuje, czy zaplanowane instancje robocze są wystarczające przy rzeczywistym obciążeniu. Chroń punkt końcowy stanu przed dostępem publicznym: może ujawniać poufne informacje dotyczące zapytań i zasobów. Oddzielnie skonfigurowany moduł monitorujący stan może pozostać dostępny nawet w przypadku przeciążenia głównej puli; sprawdź jego dostępność i konfigurację dla swojej wersji PHP oraz konfiguracji serwera WWW.

Traktuj te wartości jako szeregi czasowe wraz z liczbą zapytań i czasem odpowiedzi. Dawna wartość szczytowa kolejki nie świadczy o aktualnym przeciążeniu; podobnie w przypadku liczników wzrost ich wartości od ostatniej obserwacji ma większe znaczenie niż sama wartość całkowita. Należy przy tym uwzględnić moment uruchomienia puli lub jej ponowne uruchomienie, które powodują zmianę okresu odniesienia.

W przypadku znanego modułu FPM w systemie Linux z dostępnym interfejsem proc można odczytać zagregowane wartości pamięci. Zastąp PID za pomocą rzeczywistego identyfikatora procesu; musisz posiadać odpowiednie uprawnienia dostępu. Powtórz obserwację dla kilku procesów roboczych i różnych stanów obciążenia, zamiast wyciągać wnioski o stałej wielkości puli na podstawie pojedynczego procesu.

cat /proc/PID/smaps_rollup

Analiza powolnych żądań i kolejek

Sklep może wyświetlać wiele aktywnych procesów roboczych, mimo że to nie samo wykonywanie kodu PHP stanowi pierwotne wąskie gardło. Jeśli żądania oczekują na powolne zapytania do bazy danych, procesy w tym czasie pozostają zajęte. W przypadku napływania kolejnych żądań kolejka słuchaczy może się wydłużyć, a czas odpowiedzi wydłużyć, nawet jeśli procesor nadal dysponuje wolnymi zasobami.

Wyższy limit liczby procesów roboczych może w tej sytuacji umożliwić jednoczesne przesłanie większej liczby zapytań do bazy danych. Może to spowodować, że Drukowanie w backendzie i jeszcze bardziej wydłużyć czas oczekiwania. Dlatego przed zwiększeniem limitu porównaj wykresy obciążenia FPM i kolejki z obciążeniem bazy danych, powolnymi zapytaniami oraz wywołaniami usług zewnętrznych.

Slowlog FPM pomaga zawęzić zakres długotrwałych wywołań PHP: w przypadku żądań przekraczających skonfigurowany próg FPM może zarejestrować ślad wykonania. Pokazuje on punkt wykonania i nie stanowi pełnego profilu całego żądania. Powtarzające się fragmenty można porównać z czasem trwania żądania i metrykami zaplecza; Instrukcja analizy pliku slowlog PHP-FPM wyjaśnia to dalsza analiza.

Również czas oczekiwania należy odróżnić od rzeczywistej przepustowości. W przypadku nginx określa się fastcgi_read_timeout dopuszczalny odstęp między kolejnymi operacjami odczytu z serwera FastCGI, a nie ogólny czas trwania żądania. Wyższa wartość może pozwolić na dłuższe oczekiwanie, ale nie tworzy dodatkowych procesów roboczych ani nie przyspiesza działania bazy danych.

Ograniczenia wydajności i kolejne kroki

Jeśli budżet pamięci RAM nie wystarcza na szacowane zapotrzebowanie, wyższe ustawienie dla pm.max_children Nie należy jednak zapominać o konflikcie celów: dodatkowe procesy również wymagają pamięci. Zamiast tego sprawdź, czy można zmniejszyć liczbę żądań PHP lub czas zajętości ich procesów roboczych. To, które rozwiązanie jest właściwe, zależy od tego, gdzie powstaje zaobserwowane obciążenie.

Lepiej wykorzystywana pamięć podręczna może przejmować powtarzające się wywołania, podczas gdy szybsze wykonywanie kodu PHP i dostęp do bazy danych pozwalają na wcześniejsze zwolnienie procesów roboczych. Odpowiednie zadania wykonywane w tle można przenieść poza bezpośrednią ścieżkę żądania; jednak również te zadania wymagają własnych zasobów. Ograniczenie obciążenia chroni backend w okresach szczytowego obciążenia, ale może również powodować, że żądania będą musiały czekać lub zostaną odrzucone.

Dodatkowa pamięć RAM może umożliwić zwiększenie liczby procesów roboczych, jeśli pamięć faktycznie stanowi decydujące ograniczenie. Jeśli procesor, baza danych lub usługa zewnętrzna są już w pełni obciążone, należy również uwzględnić ich wydajność. Dlatego sama większa ilość pamięci nie gwarantuje ani krótszych czasów odpowiedzi, ani większej przepustowości.

Jeśli zapotrzebowanie na pamięć poszczególnych procesów roboczych wzrośnie w trakcie ich cyklu życia, to pm.max_requests zadbać o ich regularną wymianę. Może to pomóc w radzeniu sobie z wyciekami pamięci w bibliotekach stron trzecich, ale nie eliminuje ich przyczyny. Po wprowadzeniu zmiany nadal obserwuj pamięć puli i zachowanie zapytań, zamiast traktować mechanizm ponownego uruchamiania jako substytut wyszukiwania błędów.

W celu podjęcia decyzji o szerszym zakresie architektury, Porównanie NGINX Unit i PHP-FPM Kontekst: Moduł NGINX Unit został zarchiwizowany i nie jest już rozwijany. Niezależnie od wybranej architektury, zmiany należy wprowadzać na podstawie szeregi czasowe Sprawdź: przy podobnej liczbie zapytań porównaj kolejkę, obciążenie procesorów, pamięć oraz czasy odpowiedzi. W ten sposób można ustalić, czy dostosowanie faktycznie wyeliminowało wąskie gardło, czy też jedynie je przeniosło.