Straipsnių katalogas
Vienu metu serverio apdorojamų vartotojų skaičius priklauso ne nuo to, kiek branduolių jis turi, o nuo to, kiek atminties sunaudoja kiekvienas procesas.
Šis teiginys gali skambėti kaip provokacija, tačiau tai yra realiausia ir skaudžiausia patirtis eksploatavimo ir priežiūros pramonėje.
Kodėl atmintis yra pagrindinė kliūtis?
Daugelis žmonių, matydami VPS su 8 branduolių procesoriumi ir 24 GB atminties, pasąmoningai mano, kad jie gali lengvai vykdyti šimtus PHP-FPM procesų.
Tačiau iš tikrųjų vieno PHP proceso RSS atminties naudojimas dažnai siekia net 200 MB.
Tai rezultatas, gautas atlikus faktinį testavimą per komandinę eilutę:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Sudėtingoje „HestiaCP “ sistemoje ir kelių įskiepių aplinkoje, ypač be „OPcache“ optimizavimo, 200 MB yra norma.
Tai reiškia, kad atmintis, o ne CPU, yra griežta riba, lemianti maksimalų lygiagretumą.
Rekomenduojamas konfigūracijos failas (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
Parametrų skaičiavimo logika ir nustatymo pagrindas
| Konfigūracijos parametrai | Nustatoma vertė | Šerdies skaičiavimas ir sąrankos pagrindas |
|---|---|---|
| pm | dynamic | Dinaminis režimas leidžia lanksčiai pridėti arba ištrinti procesus pagal lygiagretumo reikalavimus, subalansuojant atsako greitį ir atminties panaudojimą. |
| pm.max_vaikai | 80 | 24 GB bendros atminties, atėmus sistemos branduolį ir MySQL/RedisPo „Nginx“ PHP lieka maždaug 16 GB.16,384 MB / 200 MB ≈ 81.9Nustačius reikšmę 80, galima visiškai pašalinti atminties trūkumą (OOM) didelio lygiagretumo metu. |
| pm.start_servers | 16 | Paleidimo metu išankstinis pašildymas nustatomas dvigubai daugiau nei procesoriaus branduolių (8 branduoliai × 2 = 16), siekiant užtikrinti, kad paslauga galėtų iš karto apdoroti pagrindinį lygiagretumą po paleidimo iš naujo. |
| pm.min_atsarginiai_serveriai | 8 | Nustatykite procesoriaus branduolių skaičių į 8, kad užtikrintumėte, jog į naujas užklausas būtų galima atsakyti bet kuriuo metu esant mažam srautui. |
| pm.max_spare_servers | 24 | Nustatykite jį į 3 kartus didesnį nei procesoriaus branduolių skaičius (8 branduoliai × 3 = 24), kad išlaikytumėte vidutinį procesų skaičių po srauto sumažėjimo ir galėtumėte valdyti nedidelius svyravimus. |
| pm.max_requests | 500 | Jei vienas procesas pasiekia didelę 200 MB bazę, sumažinus užklausų skaičių iki 500 prieš sunaikinimą ir atkūrimą, galima greičiau pašalinti netiesioginius atminties nutekėjimus. |
| pm.process_idle_timeout | 10s | Viršijantis min_spare_servers Neveiki procesai automatiškai paleidžiami ir grąžinami į sistemos atmintį po 10 sekundžių, kai nėra užklausų. |
Svarbiausi palaikomieji nustatymai ir optimizavimo pasiūlymai
1. Laiko apribojimo mechanizmas nuo pagirių
request_terminate_timeout = 60s Štai ir esmė.
Jis gali priverstinai nutraukti procesus, kurie užstrigo dėl duomenų bazės aklavietės arba trečiosios šalies API blokavimo.
Tuo tarpu „Nginx“ fastcgi_read_timeout Jis turi būti saugomas bent 60 sekundžių, kitaip klientas jį gaus anksčiau laiko. 504 Gateway Timeout.
2. Strategijos atminties kliūtims įveikti
Maksimalus 80 vienu metu vykstančių procesų skaičius reiškia, kad esant ekstremalioms lygiagrečioms sąlygoms sistema gali vienu metu apdoroti daugiausia 80 dinaminių HTTP užklausų.
Jei norite dar labiau padidinti pajėgumus, reikėtų sutelkti dėmesį į atminties naudojimo mažinimą kiekvienam procesui.
- Įgalinti OPcache：在
php.iniVidutinė konfigūracijaopcache.enable=1及opcache.memory_consumption=256Baitų kodų kaupimas talpykloje gali sumažinti vieno proceso atminties naudojimą nuo 200 MB iki 60–100 MB. - Protinga atminties limito kontrolė：将
php.inividuryjememory_limitApribota iki128MArba256MSiekiant išvengti atskirų nenormalių scenarijųneribotasTai sunaudoja daug atminties.
Kai vieno proceso atminties naudojimas sumažėja iki 100 MB...pm.max_children Jį galima saugiai atnaujinti iki 150 Be to, lygiagretumo galimybė beveik padvigubėjo.
Cituoti autoritetingi požiūriai
Remiantis oficialioje „Nginx“ dokumentacijoje pateiktomis rekomendacijomis :
„FastCGI“ programas visada reikėtų stebėti naudojant skirtojo laiko direktyvas, kad būtų išvengta išteklių išeikvojimo.“
(Šaltinis: „Nginx“ dokumentai)
Oficialiame PHP vadove aiškiai parašyta:
„pm.max_children“ apibrėžia maksimalų sukurtų antrinių procesų skaičių. Tai svarbiausia direktyva.“
(Šaltinis: PHP-FPM dokumentacija)
Šios autoritetingos nuomonės puikiai atitinka mūsų praktiką, įrodydamos, kad optimizavimo logika grindžiama ne tik patirtimi, bet ir standartizuota geriausia praktika.
Išvada: mano požiūris ir pagrindinės citatos
Didelio lygiagretumo scenarijuose CPU yra variklis, atmintis – degalų bakas, o PHP-FPM – parko dispečeris.
Kad ir koks galingas variklis būtų, jei degalų bakas nėra pakankamai didelis, vilkstinė toli nenuvažiuos.
Tikri ekspertai aklai nemaksimalizuoja parametrų, o tiksliai apskaičiuoja kiekvieno proceso atminties naudojimą, kad išvengtų ir švaistymo, ir perpildymo.
Optimizavimo esmė – rasti optimalų balansą su ribotais ištekliais.
Tai ne tik technologija, bet ir filosofija.
Todėl nustokite tikėti, kad „branduolių skaičius lemia viską“. Kas iš tikrųjų lemia lygiagretumo ribą, yra jūsų atminties kontrolė.
Imkitės veiksmų ir optimizuokite savo VPS iki galo, išnaudodami kiekvieną atminties lašą.
Tikiuosi, kad jums bus naudingas straipsnis „8 branduolių 24 GB VPS baigiasi atmintis? Ekstremalus PHP-FPM procesų telkinio derinimas naudojant HestiaCP“, kuriuo pasidalino Chen Weiliang tinklaraštyje ( https://www.chenweiliang.com/ ).
Nedvejodami pasidalinkite šio straipsnio nuoroda: https://www.chenweiliang.com/cwl-34509.html