8-jedrnemu 24GB VPS-ju zmanjkuje pomnilnika? Praktični vodnik za ekstremno nastavitev PHP-FPM procesnega bazena s HestiaCP

Število hkratnih uporabnikov, ki jih lahko strežnik obdela, ni odvisno od števila jeder, temveč od tega, koliko pomnilnika porabi vsak proces.

Ta izjava se morda sliši kot provokacija, vendar je to najbolj resnična in boleča izkušnja v panogi obratovanja in vzdrževanja.

Zakaj je spomin ključno ozko grlo?

Mnogi ljudje vidijo VPS z 8-jedrnim procesorjem in 24 GB pomnilnika in podzavestno mislijo, da lahko zlahka izvajajo na stotine PHP-FPM procesov.

Vendar pa v resnici poraba pomnilnika RSS enega samega PHP procesa pogosto znaša kar 200 MB.

To je rezultat, pridobljen z dejanskim testiranjem prek ukazne vrstice:

ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'

V kompleksnem ogrodju HestiaCP in okolju z več vtičniki, še posebej brez optimizacije OPcache, je 200 MB norma.

To pomeni, da je pomnilnik, ne procesor, tista fiksna omejitev, ki določa največjo sočasnost.

Priporočena konfiguracijska datoteka (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 izračuna parametrov in osnova za nastavitev

Bistvene podporne nastavitve in predlogi za optimizacijo

1. Mehanizem proti mačku s časovno omejitvijo

request_terminate_timeout = 60s To je ključ.

Prisilno lahko prekine procese, ki so obtičali zaradi zastoja baze podatkov ali blokiranja API-ja tretjih oseb.

Medtem, Nginxov fastcgi_read_timeout Hraniti ga je treba vsaj 60 sekund, sicer ga bo stranka prejela prezgodaj. 504 Gateway Timeout.

2. Strategije za premagovanje ozkih grl pomnilnika

Največ 80 sočasnih procesov pomeni, da lahko sistem v ekstremnih pogojih sočasnosti obdela največ 80 dinamičnih zahtev HTTP hkrati.

Če želite še izboljšati zmogljivost, se morate osredotočiti na zmanjšanje porabe pomnilnika na proces.

• Omogoči OPcache：在 php.ini Srednja konfiguracija opcache.enable=1 In opcache.memory_consumption=256Predpomnjenje bajtne kode lahko zmanjša porabo pomnilnika enega procesa z 200 MB na 60~100 MB.
• Razumen nadzor nad mejo pomnilnika：将 php.ini srednji memory_limit Omejeno na 128M 或 256MZa preprečevanje posameznih nenavadnih skriptovneomejenoPorabi veliko pomnilnika.

Ko poraba pomnilnika enega procesa pade na 100 MB ...pm.max_children Lahko se varno nadgradi na 150 Poleg tega se je zmogljivost sočasnosti skoraj podvojila.

Navedena avtoritativna stališča

Glede na priporočila v uradni dokumentaciji Nginx :

"Aplikacije FastCGI je treba vedno spremljati z direktivami o časovni omejitvi, da se prepreči izčrpanost virov."
(Vir: Dokumenti Nginx)

Uradni priročnik za PHP jasno navaja:

"pm.max_children določa največje število podrejenih procesov, ki jih je mogoče ustvariti. To je najpomembnejša direktiva."
(Vir: Dokumentacija PHP-FPM)

Ta avtoritativna stališča so popolnoma usklajena z našimi praksami in dokazujejo, da logika optimizacije ne temelji le na izkušnjah, temveč tudi na standardiziranih najboljših praksah.

Zaključek: Moja stališča in ključni citati

V scenarijih z visoko sočasnostjo je CPU motor, pomnilnik rezervoar za gorivo, PHP-FPM pa dispečer voznega parka.

Ne glede na to, kako močan je motor, če rezervoar za gorivo ni dovolj velik, konvoj ne bo prišel daleč.

Pravi strokovnjaki ne slepo maksimizirajo parametrov, temveč natančno izračunajo porabo pomnilnika za vsak proces, da se izognejo tako potrati kot prelivanju.

Bistvo optimizacije je najti optimalno ravnovesje z omejenimi viri.

To ni le tehnologija, ampak tudi filozofija.

Zato nehajte verjeti, da "število jeder določa vse." Kar resnično določa omejitev sočasnosti, je vaš nadzor nad pomnilnikom.

Ukrepajte in optimizirajte svoj VPS do njegovega polnega potenciala, ter kar najbolje izkoristite vsako kapljico pomnilnika.