Nieedytowana wersja artykułu została pierwotnie opublikowana na i publikowana jest tutaj za zgodą jej .
W skrócie opiszę, jak najlepiej skonfigurować PHP-FPM, aby zwiększyć przepustowość, zmniejszyć opóźnienie i stabilniej wykorzystać zasoby procesora i pamięci. Domyślnie wartość PM (menedżera procesów) w PHP-FPM ma wartość dynamic, a jeśli brakuje Ci pamięci, lepiej ustawić ondemand. Porównajmy 2 opcje zarządzania na podstawie dokumentacji php.net i zobaczmy, czym różni się od nich mój ulubiony static pm dla dużego ruchu:
pm = dynamic — liczba procesów potomnych jest konfigurowana dynamicznie na podstawie następujących dyrektyw: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — procesy są tworzone na żądanie (w przeciwieństwie do dynamicznego tworzenia, kiedy pm.start_servers są uruchamiane przy uruchamianiu usługi).
pm = static — liczba procesów potomnych jest stała i określana parametrem pm.max_children.
Szczegóły znajdują się w .
Podobieństwa menedżera procesów PHP-FPM z regulatorem częstotliwości procesora
To może być nie na temat, ale zamierzam powiązać to z tematem konfiguracji PHP-FPM. Który z Was nie doświadczył spowolnienia procesora — na laptopie, maszynie wirtualnej lub serwerze dedykowanym? Pamiętacie skalowanie częstotliwości procesora? Te parametry, dostępne dla nix i Windows, mogą poprawić wydajność i czas reakcji systemu, jeśli zmienisz parametr regulatora procesora na ondemand na performance*. Tym razem porównajmy opisy i przyjrzyjmy się podobieństwom:
Governor = ondemand — dynamiczne skalowanie częstotliwości procesora w zależności od aktualnego obciążenia. Nagłe przejście na maksymalną częstotliwość, a następnie jej zmniejszenie, gdy wydłużają się okresy bezczynności.
Governor = conservative = dynamiczne skalowanie częstotliwości w zależności od aktualnego obciążenia. Zwiększa i zmniejsza częstotliwość płynniej niż ondemand.
Governor = performance — częstotliwość zawsze maksymalna.
Szczegóły znajdują się w .
Widzicie podobieństwo? Chciałem pokazać to porównanie, aby przekonać Was, że najlepiej jest używać pm static dla PHP-FPM.
Dla regulatora procesora parametr performance pomaga bezpiecznie zwiększyć wydajność, ponieważ niemal całkowicie zależy od limitu procesora serwera. Oczywiście istnieją też takie czynniki, jak temperatura, naładowanie akumulatora (w laptopie) i inne efekty uboczne ciągłej pracy procesora na 100%. Ustawienie wydajności zapewnia najszybszą pracę procesora. Na przykład poczytaj o , z którym panel RPi będzie używać regulatora performance, gdzie poprawa wydajności będzie bardziej zauważalna z powodu niskiej częstotliwości taktowania CPU.
Użycie pm static do osiągnięcia maksymalnej wydajności serwera
Parametr PHP-FPM pm static w dużej mierze zależy od dostępnej pamięci na serwerze. Jeśli pamięć jest ograniczona, lepiej wybrać ondemand lub dynamic. Z drugiej strony, jeśli masz pamięć, możesz uniknąć zbędnych kosztów zarządzania procesem PHP, ustawiając pm static na maksymalną pojemność serwera. Innymi słowy, jeśli wszystko dobrze policzyć, musisz ustawić pm.static na maksymalną liczbę procesów PHP-FPM, które mogą być uruchomione, nie powodując problemów z brakującą pamięcią lub pamięcią podręczną. Ale nie tak wysoko, aby przeciążyć procesory i nagromadzić ilość operacji PHP-FPM, czekających na wykonanie..
Na powyższym zrzucie ekranu serwer ma ustawione pm = static i pm.max_children = 100, co zajmuje około 10 GB z dostępnych 32. Zwróć uwagę na wyróżnione kolumny, wszystko tu jest jasne. Na tym zrzucie ekranu było około 200 aktywnych użytkowników (ponad 60 sekund) w Google Analytics. Na tym poziomie około 70% procesów potomnych PHP-FPM nadal pozostaje bezczynnych. Oznacza to, że PHP-FPM jest zawsze ustawione na maksymalny poziom zasobów serwera, niezależnie od aktualnego ruchu. Proces bezczynny czeka na szczytowy ruch i reaguje natychmiast. Nie musisz czekać, aż pm stworzy procesy potomne, a następnie zakończy je, gdy upłynie okres pm.process_idle_timeout. Ustawiłem bardzo dużą wartość dla pm.max_requests, ponieważ to jest serwer roboczy bez wycieków pamięci w PHP. Możesz ustawić pm.max_requests = 0 ze static, jeśli jesteś całkowicie pewny swoich istniejących i przyszłych skryptów PHP. Ale lepiej jest restartować skrypty z czasem. Ustaw dużą liczbę żądań, ponieważ chcemy uniknąć zbędnych kosztów pm. Na przykład przynajmniej pm.max_requests = 1000 — w zależności od liczby pm.max_children i liczby żądań na sekundę.
Na zrzucie ekranu pokazano komendę , filtrując według u (użytkownik) i nazwy użytkownika PHP-FPM. Wyświetlane są tylko pierwsze 50 lub około tego procesów (nie liczyłem dokładnie), ale zasadniczo top pokazuje statystyki, które mieszczą się w oknie terminala. W tym przypadku z sortowaniem według % CPU (%CPU). Aby zobaczyć wszystkie 100 procesów PHP-FPM, wykonaj polecenie:
top -bn1 | grep php-fpmKiedy używać pm ondemand i dynamic
Jeśli używasz pm dynamic, pojawiają się podobne błędy:
OSTRZEŻENIE: [pool xxxx] wydaje się zajęty (możesz potrzebować zwiększyć pm.start_servers lub pm.min/max_spare_servers), uruchamiając 32 dzieci, jest 4 bezczynnych i 59 całkowitych dzieciSpróbuj zmienić parametr, błąd nie zniknie, jak . W tym przypadku wartość pm.min była zbyt mała, a ponieważ ruch na stronie znacznie się zmienia i ma wysokie szczyty oraz głębokie spadki, trudno jest odpowiednio skonfigurować pm dynamic. Zwykle w tym przypadku używa się pm ondemand, . Ale to jeszcze gorsze, bo ondemand kończy bezczynne procesy do zera, gdy ruch jest mały lub w ogóle go nie ma, i w końcu nadal będziesz zmagać się z kosztami zmiany ruchu. Oczywiście, jeśli nie ustawiłeś ogromnego czasu oczekiwania. Dlatego lepiej użyć pm.static + dużej liczby pm.max_requests.
PM dynamic i szczególnie ondemand mogą być przydatne, jeśli masz kilka pul PHP-FPM. Na przykład, jeśli hostujesz kilka kont cPanel lub kilka witryn w różnych pulach. Mam serwer, gdzie, powiedzmy, 100+ kont cPanel i około 200 domen, a pm.static lub nawet dynamic by mi nie pomogło. Potrzebny jest tylko ondemand, ponieważ więcej niż dwie trzecie witryn otrzymuje mało ruchu lub w ogóle go nie ma, a z ondemand wszystkie procesy podrzędne przestaną działać, co zaoszczędzi nam mnóstwo pamięci! Na szczęście programiści cPanel to zauważyli i ustawili domyślną wartość ondemand. Wcześniej, gdy domyślną wartością było dynamic, PHP-FPM w ogóle nie był odpowiedni dla obciążonych serwerów współdzielonych. Wielu używało suPHP, ponieważ pm dynamic zużywał pamięć nawet przy bezczynnych pulach i kontach cPanel PHP-FPM. Prawdopodobnie przy dobrym ruchu nie będziesz hostować na serwerze z dużą liczbą pul PHP-FPM (wspólny hosting).
Podsumowanie
Jeśli używasz PHP-FPM i masz poważny ruch, menedżerowie procesów ondemand i dynamic dla PHP-FPM będą ograniczać przepustowość z powodu wrodzonych kosztów. Zbadaj swój system i skonfiguruj procesy PHP-FPM zgodnie z maksymalną pojemnością serwera. Najpierw ustal pm.max_children w zależności od maksymalnego wykorzystania pm dynamic lub ondemand, a następnie zwiększ tę wartość do poziomu, w którym pamięć i procesor będą działać bez nadmiernego obciążenia. Zauważysz, że pm static, gdy wszystko jest przechowywane w pamięci, szczyty ruchu w czasie będą powodować mniejsze obciążenie dla procesora, a średnie wartości obciążenia serwera i procesora wyrównają się. Średni rozmiar procesu PHP-FPM zależy od serwera WWW i wymaga ręcznej konfiguracji, dlatego bardziej zautomatyzowane menedżery procesów są dynamic i ondemand — bardziej popularne. Mam nadzieję, że artykuł był przydatny.
UPD Dodano diagram benchmarku . Jeśli procesy PHP-FPM znajdują się w pamięci, wydajność wzrasta dzięki zużyciu pamięci, w której czekają. Znajdź optymalne rozwiązanie dla siebie.
Źródło: habr.com
