Katalog artykułów
Liczba jednoczesnych użytkowników, z jaką może obsłużyć serwer, zależy nie od liczby jego rdzeni, ale od ilości pamięci zużywanej przez każdy proces.
To stwierdzenie może brzmieć jak prowokacja, ale jest to najbardziej realne i bolesne doświadczenie w branży operacyjnej i konserwacyjnej.
Dlaczego pamięć jest głównym wąskim gardłem?
Wiele osób widząc VPS z 8-rdzeniowym procesorem i 24 GB pamięci podświadomie myśli, że bez problemu można na nim uruchomić setki procesów PHP-FPM.
W rzeczywistości jednak użycie pamięci RSS przez pojedynczy proces PHP wynosi często aż 200 MB.
Oto wynik uzyskany w wyniku rzeczywistych testów za pomocą wiersza poleceń:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
W złożonym środowisku HestiaCP i wielu wtyczkach, szczególnie bez optymalizacji OPcache, 200 MB jest normą.
Oznacza to, że pamięć, a nie procesor, jest sztywnym limitem określającym maksymalną współbieżność.
Zalecany plik konfiguracyjny (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
Logika obliczania parametrów i podstawa ustawień
| Parametry konfiguracyjne | Ustawienie wartości | Podstawa obliczeń i konfiguracji rdzenia |
|---|---|---|
| pm | dynamic | Tryb dynamiczny umożliwia elastyczne dodawanie lub usuwanie procesów na podstawie wymagań współbieżności, równoważąc szybkość reakcji i wykorzystanie pamięci. |
| pm.max_children | 80 | 24 GB pamięci całkowitej, pomniejszone o jądro systemowe i MySQL/RedisPo Nginxie na PHP pozostaje około 16 GB.16,384 MB / 200 MB ≈ 81.9Ustawienie wartości na 80 może całkowicie wyeliminować problem braku pamięci (OOM) występujący przy dużej współbieżności. |
| pm.start_servers | 16 | Liczba rdzeni procesora podczas rozruchu jest podwajana (8 rdzeni × 2 = 16), co pozwala mieć pewność, że usługa po ponownym uruchomieniu będzie w stanie natychmiast obsłużyć podstawową współbieżność. |
| pm.min_zapasowe_serwery | 8 | Ustaw liczbę rdzeni procesora na 8, aby mieć pewność, że na nowe żądania będzie można odpowiadać w dowolnym momencie w okresach niskiego ruchu. |
| pm.max_spare_servers | 24 | Ustaw ją na trzykrotność liczby rdzeni procesora (8 rdzeni × 3 = 24), aby zachować umiarkowaną liczbę procesów po ustaniu ruchu, co pozwoli poradzić sobie z niewielkimi wahaniami. |
| pm.max_requests | 500 | Jeśli pojedynczy proces osiągnie rozmiar bazy 200 MB, zmniejszenie liczby żądań do 500 spowoduje zniszczenie i odbudowanie procesu, co może szybciej usunąć niejawne wycieki pamięci. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Bezczynne procesy są automatycznie zwalniane i powracają do pamięci systemowej po 10 sekundach braku żądań. |
Niezbędne ustawienia pomocnicze i sugestie dotyczące optymalizacji
1. Mechanizm zapobiegający kacowi po wyłączeniu
request_terminate_timeout = 60s To jest klucz.
Może wymusić zakończenie procesów, które utknęły z powodu zablokowania bazy danych lub blokowania interfejsu API innej firmy.
Tymczasem Nginx fastcgi_read_timeout Musi on trwać co najmniej 60 sekund, w przeciwnym razie klient otrzyma go przedwcześnie. 504 Gateway Timeout.
2. Strategie pokonywania wąskich gardeł pamięci
Maksymalnie 80 równoczesnych procesów oznacza, że w ekstremalnych warunkach współbieżności system może obsłużyć jednocześnie maksymalnie 80 dynamicznych żądań HTTP.
Jeśli chcesz jeszcze bardziej zwiększyć wydajność, powinieneś skupić się na zmniejszeniu wykorzystania pamięci dla każdego procesu.
- Włącz OPcache：Wzór
php.iniŚrednia konfiguracjaopcache.enable=1iopcache.memory_consumption=256Buforowanie bajtkodu może zmniejszyć zużycie pamięci przez pojedynczy proces z 200 MB do 60~100 MB. - Rozsądna kontrola limitu pamięci：将
php.iniśrodkowymemory_limitOgraniczone do128M或256MAby zapobiec powstawaniu pojedynczych nieprawidłowych skryptów无限Zajmuje dużo pamięci.
Gdy wykorzystanie pamięci przez pojedynczy proces spadnie do 100 MB...pm.max_children Można go bezpiecznie ulepszyć do 150 Ponadto możliwości współbieżności niemal się podwoiły.
Przytoczone autorytatywne punkty widzenia
Zgodnie z zaleceniami oficjalnej dokumentacji Nginx :
„Aplikacje FastCGI należy zawsze monitorować za pomocą dyrektyw timeout, aby zapobiec wyczerpaniu zasobów”.
(Źródło: Dokumentacja Nginx)
Oficjalny podręcznik PHP wyraźnie stwierdza:
„pm.max_children definiuje maksymalną liczbę procesów potomnych, które mają zostać utworzone. To najważniejsza dyrektywa”.
(Źródło: Dokumentacja PHP-FPM)
Te autorytatywne poglądy doskonale wpisują się w naszą praktykę, dowodząc, że logika optymalizacji nie opiera się wyłącznie na doświadczeniu, ale również na standardowych najlepszych praktykach.
Wnioski: Moje poglądy i kluczowe cytaty
W scenariuszach o wysokiej współbieżności procesor jest silnikiem, pamięć jest zbiornikiem paliwa, a PHP-FPM jest dyspozytorem floty.
Niezależnie od mocy silnika, jeśli zbiornik paliwa jest za mały, konwój nie pojedzie daleko.
Prawdziwi eksperci nie maksymalizują bezmyślnie parametrów, lecz raczej precyzyjnie obliczają użycie pamięci przez każdy proces, aby uniknąć zarówno marnotrawstwa, jak i przepełnienia.
Istotą optymalizacji jest znalezienie optymalnej równowagi przy ograniczonych zasobach.
To nie tylko technologia, ale i filozofia.
Dlatego przestań wierzyć, że „liczba rdzeni decyduje o wszystkim”. To, co naprawdę decyduje o granicy współbieżności, to Twoja kontrola nad pamięcią.
Podejmij działania i zoptymalizuj swój VPS, wykorzystując w pełni jego potencjał, maksymalnie wykorzystując każdą kroplę pamięci.
Mamy nadzieję, że artykuł „8-rdzeniowy VPS 24 GB z brakiem pamięci? Ekstremalne dostrajanie puli procesów PHP-FPM w HestiaCP” udostępniony na blogu Chen Weilianga ( https://www.chenweiliang.com/ ) okaże się dla Ciebie pomocny.
Możesz udostępnić link do tego artykułu: https://www.chenweiliang.com/cwl-34509.html