Jak poprawnie konfigurować PHP-FPM

Konfiguracja PHP-FPM na hostingu współdzielonym lub serwerze VPS decyduje o szybkości działania stron, stabilności aplikacji oraz bezpieczeństwie całego środowiska. Źle dobrane limity procesów i pamięci powodują przeciążenia, błędy 502/504 lub spowolnienia przy większym ruchu. Dobrze skonfigurowany PHP-FPM pozwala obsługiwać więcej użytkowników przy tych samych zasobach, a jednocześnie utrzymać niski czas odpowiedzi. Poniżej znajdziesz praktyczne wskazówki, jak ustawić najważniejsze parametry krok po kroku, wprost pod potrzeby hostingu.

Podstawy działania PHP-FPM na hostingu

Czym jest PHP-FPM i gdzie ma znaczenie

PHP-FPM (FastCGI Process Manager) to menedżer procesów PHP. Zamiast uruchamiać interpreter przy każdym żądaniu, utrzymuje on pulę procesów gotowych do obsługi zapytań. Na hostingu, zwłaszcza współdzielonym, ma to ogromne znaczenie, bo wiele kont korzysta z tych samych zasobów serwera. Odpowiednia konfiguracja pozwala zbalansować wydajność i stabilność, tak aby pojedyncza strona nie zdominowała całej maszyny.

W praktyce na hostingu spotkasz dwie główne sytuacje:

• hosting współdzielony – dostawca ustawia bazową konfigurację PHP-FPM, a ty możesz zmieniać tylko wybrane parametry (np. przez .user.ini, panel www albo plik konfiguracyjny w katalogu użytkownika),
• VPS / serwer dedykowany – masz pełną kontrolę nad konfiguracją globalną i pulą (pool) PHP-FPM, dzięki czemu możesz optymalizować serwer pod konkretne aplikacje: WordPress, sklepy, frameworki PHP.

Najważniejsze elementy konfiguracji PHP-FPM

Konfiguracja PHP-FPM składa się z dwóch głównych warstw:

• globalny plik php-fpm.conf – dotyczy całego serwera i wszystkich pul,
• pliki pooli (np. www.conf, domain1.conf, domain2.conf) – odpowiadają za zachowanie procesów PHP dla konkretnych witryn/kont.

To właśnie pliki puli są zazwyczaj najważniejsze z punktu widzenia hostingu. Możesz w nich określić m.in. liczbę procesów, limity pamięci, sposób logowania, użytkownika systemowego oraz izolację aplikacji. Na hostingach z panelem (cPanel, Plesk, DirectAdmin) część tych ustawień jest mapowana na wygodne formularze, ale warto rozumieć, co dzieje się „pod spodem”.

Powiązanie PHP-FPM z serwerem WWW

PHP-FPM nie działa samodzielnie – komunikuje się z serwerem WWW (Apache, Nginx, LiteSpeed). Na hostingu najczęściej spotkasz:

• Apache + PHP-FPM – połączenie przez proxy_fcgi (mod_proxy_fcgi), zwykle w konfiguracji VirtualHost,
• Nginx + PHP-FPM – klasyczny układ: Nginx jako serwer frontowy + backend PHP-FPM,
• LiteSpeed / OpenLiteSpeed – własny mechanizm integracji, ale zasada jest podobna: żądanie PHP trafia do puli procesów.

Na hostingu współdzielonym nie zawsze masz dostęp do plików konfiguracyjnych Apache/Nginx, jednak rozumienie tej relacji pomaga diagnozować błędy 502 Bad Gateway, 504 Gateway Timeout czy sporadyczne „zawieszenia” aplikacji przy nagłych skokach ruchu.

Jak rozpoznać, że PHP-FPM jest źle ustawiony

Symptomy złej konfiguracji PHP-FPM na hostingu to m.in.:

• częste błędy 502 lub 504, zwłaszcza przy jednoczesnych wejściach na stronę,
• bardzo wolne ładowanie panelu administracyjnego (np. WordPress) w godzinach szczytu,
• błędy Out of memory w logach, restartowanie procesów PHP,
• przekraczanie limitów zasobów ustalonych przez hostingodawcę, blokady CPU/RAM,
• spadki wydajności po aktualizacji PHP lub migracji na inny serwer.

Jeśli zauważasz takie objawy, warto zajrzeć do konfiguracji PHP-FPM lub – przy braku bezpośredniego dostępu – do opcji w panelu klienta, które wpływają na działanie puli PHP.

Kluczowe parametry puli PHP-FPM

Tryb pm (static, dynamic, ondemand)

Podstawowym ustawieniem jest parametr pm, określający sposób zarządzania procesami:

• pm = static – stała liczba procesów, określona przez pm.max_children; dobra dla ruchliwych, przewidywalnych aplikacji na serwerach z odpowiednią ilością RAM,
• pm = dynamic – minimalna i maksymalna liczba procesów; PHP-FPM uruchamia nowe procesy, gdy są potrzebne, i zamyka je po czasie spoczynku,
• pm = ondemand – procesy uruchamiane są „na żądanie”; przy braku ruchu praktycznie nie ma aktywnych procesów.

Na hostingu współdzielonym najczęściej używany jest tryb dynamic lub ondemand, ponieważ oszczędza to zasoby serwera, dzielone między wielu klientów. Na VPS/dedykowanym możesz świadomie wybrać tryb dopasowany do typu aplikacji i dostępnego RAM.

pm.max_children – maksymalna liczba procesów

Parametr pm.max_children określa, ile procesów PHP-FPM może równocześnie obsługiwać żądania. Każdy proces może zwykle przetwarzać jedno żądanie na raz, więc wartość tego parametru przekłada się na maksymalną liczbę równoległych zapytań obsługiwanych bez kolejek.

Zbyt niska wartość:

• powoduje kolejki żądań (użytkownik czeka, aż jakiś proces się zwolni),
• zwiększa ryzyko timeoutów i błędów po stronie serwera WWW.

Zbyt wysoka wartość:

• powoduje nadmierne zużycie RAM,
• może doprowadzić do swapowania, a w konsekwencji do drastycznych spadków wydajności lub ubijania procesów przez kernel.

Na hostingu współdzielonym często masz narzucone limity, ale znając szacunkowe zużycie pamięci przez pojedynczy proces (np. 60–120 MB przy typowym WordPressie z wtyczkami), można obliczyć bezpieczną wartość. Jeśli hosting przydziela ci 1 GB RAM na procesy PHP, warto zacząć np. od 6–8 children, obserwować logi i dostosować wartość.

pm.min_spare_servers, pm.max_spare_servers, pm.start_servers

Te parametry obowiązują w trybie pm = dynamic i kontrolują, jak bardzo PHP-FPM może „rozszerzać” i „kurczyć” pulę procesów:

• pm.start_servers – ile procesów zostanie uruchomionych przy starcie puli,
• pm.min_spare_servers – minimalna liczba bezczynnych procesów oczekujących na nowe żądania,
• pm.max_spare_servers – maksymalna liczba bezczynnych procesów; nadmiar bywa zamykany.

Na hostingu ma to wpływ na tzw. „zimny start” – gdy po dłuższym braku ruchu nagle wejdzie kilku użytkowników, PHP-FPM musi uruchomić dodatkowe procesy. Zbyt zachowawcze ustawienia mogą spowodować opóźnienia przy pierwszych wejściach, natomiast zbyt wysokie wartości to niepotrzebne zużycie RAM przy niskim ruchu.

pm.max_requests – zapobieganie wyciekom pamięci

Parametr pm.max_requests określa, po ilu obsłużonych żądaniach dany proces PHP-FPM zostanie zrestartowany. Dzięki temu można ograniczyć skutki ewentualnych wycieków pamięci (memory leaks) w kodzie aplikacji lub rozszerzeniach PHP.

Przykładowo ustawienie pm.max_requests = 500–1000 pozwala zachować dobrą stabilność przy niewielkim narzucie zasobów. Na hostingu współdzielonym operator często sam wymusza określone wartości, ale jeśli masz możliwość ich zmiany, unikaj ustawiania wartości zbyt niskich (np. 10–20), bo częste restarty procesów spowodują niepotrzebne obciążenie.

Limity zasobów i bezpieczeństwo na hostingu

memory_limit i inne ustawienia PHP

Oprócz parametrów stricte PHP-FPM, istotne są limity samego PHP, konfigurowane w php.ini, .user.ini, czasem w panelu hostingu. Najważniejsze to:

• memory_limit – maksymalna ilość pamięci, jaką może zużyć pojedynczy skrypt PHP,
• max_execution_time – maksymalny czas wykonywania skryptu,
• post_max_size – maksymalny rozmiar danych HTTP POST,
• upload_max_filesize – limit wielkości pojedynczego pliku wysyłanego przez formularz.

Na hostingu współdzielonym zwiększanie memory_limit bez kontroli pm.max_children może doprowadzić do szybkiego wyczerpania RAM. Przykładowo: jeśli ustawisz memory_limit na 512M i pozwolisz na 10 children, to teoretycznie twoja pula może wymagać nawet kilku gigabajtów RAM, co niemal na pewno przekroczy limity przydzielone przez hostingodawcę.

open_basedir, disable_functions i izolacja puli

PHP-FPM pozwala uruchamiać pulę pod konkretnym użytkownikiem systemowym oraz ograniczać dostęp skryptów do systemu plików. Na wielu hostingach współdzielonych stosuje się:

• open_basedir – ograniczenie dostępu PHP do wybranych katalogów (np. tylko public_html danego konta),
• disable_functions – lista funkcji PHP zablokowanych ze względów bezpieczeństwa (np. exec, shell_exec, system),
• separację puli – każda domena lub konto ma osobną pulę, działającą jako inny użytkownik, co zmniejsza ryzyko eskalacji uprawnień.

Dla użytkownika hostingu oznacza to, że niektóre skrypty backupowe czy instalatory wymagające większych uprawnień mogą nie działać domyślnie. Jeśli potrzebujesz określonej funkcji, zwykle musisz poprosić obsługę o zmianę konfiguracji lub przeniesienie na plan, który na to pozwala.

Limity narzucane przez hostingodawcę

Na hostingu współdzielonym nie wszystkie parametry możesz zmienić samodzielnie. Często narzucone są:

• maksymalny memory_limit i czas wykonania,
• górna granica liczby procesów PHP na konto,
• limity CPU, I/O i jednoczesnych procesów w systemie (np. przez CloudLinux, cgroups),
• konkretne wartości pm.max_children i pm.max_requests w konfiguracji puli.

Świadomość tych ograniczeń jest kluczowa przy diagnozowaniu problemów wydajności. Jeśli optymalizujesz konfigurację w ramach dostępnego panelu, a wciąż widzisz komunikaty o przekroczeniu limitów, konieczna może być zmiana planu na wyższy lub migracja na VPS, gdzie masz pełną kontrolę.

Bezpieczne logi PHP-FPM i diagnostyka

Logi PHP-FPM i PHP to jedno z najważniejszych narzędzi diagnostycznych. W plikach puli możesz zdefiniować:

• access.log – logi żądań przetwarzanych przez PHP-FPM,
• slowlog – logi powolnych skryptów,
• error_log – błędy PHP i problemy z procesami.

Na hostingu współdzielonym logi zwykle znajdują się w katalogu logs lub można je podejrzeć w panelu klienta. Analiza slowlog pozwala zidentyfikować skrypty powodujące największe opóźnienia (np. intensywne zapytania do bazy lub ciężkie raporty w systemach e-commerce). W połączeniu z odpowiednią konfiguracją pm.max_children i memory_limit daje to pełniejszy obraz obciążenia.

Praktyczne scenariusze konfiguracji na różnych typach hostingu

Hosting współdzielony – ograniczone możliwości, sensowne kompromisy

Na klasycznym hostingu współdzielonym wpływ na PHP-FPM bywa mocno ograniczony. Możesz zazwyczaj:

• wybierać wersję PHP oraz czasem profil (np. produkcyjny vs. deweloperski),
• zmieniać podstawowe ustawienia php.ini przez panel lub .user.ini,
• włączać/wyłączać wybrane rozszerzenia PHP,
• wybierać tryb uruchamiania (np. PHP-FPM vs. CGI/FastCGI, jeśli hosting to udostępnia).

Nawet przy takich ograniczeniach możesz poprawić działanie aplikacji:

• dobrać rozsądne memory_limit (np. 128M–256M dla prostych stron, więcej dla rozbudowanych sklepów, ale w granicach planu),
• skrócić max_execution_time, aby szybciej „odcinać” skrypty w pętli,
• dostosować limity upload_max_filesize i post_max_size do realnych potrzeb.

Jeśli widzisz w logach błędy typu „server reached max_children setting”, a nie masz dostępu do konfiguracji puli, pozostaje kontakt z supportem hostingu i prośba o zmianę planu lub parametrów. Z kolei przy mało odwiedzanych stronach, domyślne ustawienia trybu ondemand bywają wystarczające i oszczędzają zasoby, co może przekładać się na niższą cenę usługi.

VPS – więcej swobody, więcej odpowiedzialności

Na VPS otrzymujesz większą lub pełną kontrolę nad PHP-FPM. Możesz:

• tworzyć osobne pule dla każdej domeny lub projektu,
• dobierać tryb pm, liczbę children, limity RAM i CPU,
• konfigurować logi, slowlog, poziom verbosity,
• integrować PHP-FPM z Apache/Nginx według własnego uznania.

Praktyczny schemat postępowania:

• zmierz średnie i maksymalne zużycie pamięci przez pojedynczy proces PHP (np. poprzez narzędzia systemowe i analizę logów),
• zsumuj dostępny RAM przeznaczony na PHP, pozostawiając rezerwę dla bazy danych, cache, systemu,
• oblicz pm.max_children tak, aby łączna pamięć wszystkich potencjalnych procesów nie przekroczyła bezpiecznej wartości,
• dobierz pm.max_requests, aby równoważyć stabilność z minimalizacją restartów procesów.

Przykład: VPS z 4 GB RAM, z czego 1,5 GB chcesz przeznaczyć na PHP dla danego projektu. Jeśli pojedynczy proces zużywa ok. 80 MB, bezpieczna liczba children to ok. 15–18. Ustawiasz pm = dynamic, pm.max_children = 16, pm.start_servers = 3, pm.min_spare_servers = 2, pm.max_spare_servers = 6, pm.max_requests = 800. Następnie obserwujesz realne obciążenie i dostosowujesz parametry.

Serwer dedykowany – wiele projektów i zaawansowane strojenie

Na dużym serwerze dedykowanym często utrzymujesz wiele aplikacji jednocześnie: kilka sklepów, portali, paneli administracyjnych. W takiej sytuacji warto stosować:

• osobne pule PHP-FPM dla każdego większego projektu,
• różne wersje PHP, jeśli wymagania aplikacji na to wskazują,
• rozsądny podział RAM pomiędzy pule, bazę danych, cache (Redis, Memcached) i serwer WWW.

Dodatkowo możesz:

• używać narzędzi monitorujących (Prometheus, Grafana, Zabbix) do śledzenia liczby procesów, wykorzystania RAM i czasu odpowiedzi,
• testować konfigurację pod syntetycznym obciążeniem (ab, wrk, k6),
• łączyć PHP-FPM z reverse proxy (Nginx, HAProxy) w konfiguracjach wysokiej dostępności.

W takim środowisku PHP-FPM staje się jednym z elementów większej układanki. Niewłaściwe ustawienie puli dla jednego bardzo obciążającego sklepu może „zadławić” cały serwer, dlatego warto precyzyjnie kontrolować pm.max_children i monitorować, czy któraś z pul nie zaczyna wykorzystywać nieproporcjonalnie dużej części zasobów.

Migracja między hostingami a konfiguracja PHP-FPM

Przenosząc stronę z jednego hostingu na inny, łatwo przeoczyć różnice w konfiguracji PHP-FPM. Typowe pułapki:

• inna wersja PHP, co zmienia zużycie pamięci przez proces,
• domyślnie inny tryb pm (np. ondemand zamiast dynamic),
• inne limity memory_limit i max_execution_time,
• ściślejsze ograniczenia open_basedir i disable_functions.

Po migracji warto:

• porównać stare i nowe ustawienia PHP (phpinfo, panel hostingu),
• sprawdzić logi PHP-FPM i error_log bezpośrednio po przeniesieniu,
• wykonać testy obciążeniowe lub przynajmniej zasymulować większy ruch (np. wejście na stronę z kilku urządzeń, generowanie cache).

Jeśli po migracji pojawiają się błędy 502/504 lub widoczne spowolnienia, często wystarczy dostosować pm.max_children i powiązane z nim limity lub poprosić nowego dostawcę hostingu o wyjaśnienie, jakie wartości są domyślne i które mogą zostać zmienione w ramach planu.