Artiklite kataloog
Serveri poolt hallatavate samaaegsete kasutajate arv ei sõltu mitte tuumade arvust, vaid iga protsessi mälu tarbimisest.
See väide võib kõlada provokatsioonina, kuid see on kõige reaalsem ja valusam kogemus käitamise ja hoolduse valdkonnas.
Miks on mälu peamine kitsaskoht?
Paljud inimesed näevad VPS-i 8-tuumalise protsessori ja 24 GB mäluga ning arvavad alateadlikult, et see suudab hõlpsalt käivitada sadu PHP-FPM protsesse.
Tegelikkuses on ühe PHP protsessi RSS-mälu kasutus aga sageli kuni 200 MB.
See on tulemus, mis saadi käsurea kaudu tegeliku testimise teel:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP keerulises raamistikus ja mitme pluginaga keskkonnas, eriti ilma OPcache optimeerimiseta, on 200 MB normiks.
See tähendab, et maksimaalse samaaegsuse määravaks piiranguks on mälu, mitte protsessor.
Soovitatav konfiguratsioonifail (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
Parameetrite arvutamise loogika ja seadistamise alus
| Konfiguratsiooni parameetrid | Väärtuse määramine | Tuuma arvutamine ja seadistamise alus |
|---|---|---|
| pm | dynamic | Dünaamiline režiim võimaldab protsesse elastselt lisada või kustutada vastavalt samaaegsusnõuetele, tasakaalustades reageerimiskiirust ja mälu kasutamist. |
| pm.max_lapsed | 80 | 24 GB mälu kokku, millest on maha arvatud süsteemi kernel ja MySQL/RedisPärast Nginxit jääb PHP jaoks umbes 16 GB vaba ruumi.16,384 MB / 200 MB ≈ 81.9Selle väärtuseks 80 seadmine aitab suure samaaegsuse korral täielikult välistada mälu otsa saamise (OOM – Out of Memory). |
| pm.start_serverid | 16 | Käivitamisel seatakse eelsoojendus kahekordseks protsessori tuumade arvuks (8 tuuma × 2 = 16), et teenus saaks pärast taaskäivitamist koheselt hakkama põhilise samaaegsusega. |
| pm.min_spare_servers | 8 | Määra protsessori tuumade arvuks 8 tuuma, et tagada uutele päringutele vastamine igal ajal vähese liiklusega perioodidel. |
| pm.max_spare_servers | 24 | Määrake see kolmekordseks protsessori tuumade arvuks (8 tuuma × 3 = 24), et säilitada mõõdukas arv protsesse pärast liikluse vähenemist ja tulla toime väikeste kõikumistega. |
| pm.max_requests | 500 | Kui üks protsess jõuab 200 MB baasini, siis päringute arvu vähendamine 500-ni hävitab ja ehitab protsessi uuesti üles, mis aitab implitsiitseid mälulekkeid kiiremini kõrvaldada. |
| pm.process_idle_timeout | 10s | Ületav min_spare_servers Jõudeolekus protsessid vabastatakse automaatselt ja tagastatakse süsteemimällu 10 sekundi pärast, kui päringuid pole tehtud. |
Olulised tugiseaded ja optimeerimissoovitused
1. Ajapeatuse pohmellivastane mehhanism
request_terminate_timeout = 60s See ongi võti.
See suudab jõuga lõpetada protsesse, mis on andmebaasi ummikseisu või kolmanda osapoole API blokeerimise tõttu kinni jäänud.
Samal ajal Nginxi fastcgi_read_timeout Seda tuleb hoida vähemalt 60 sekundit, vastasel juhul saab klient selle enneaegselt kätte. 504 Gateway Timeout.
2. Mälu kitsaskohtade ületamise strateegiad
Maksimaalselt 80 samaaegset protsessi tähendab, et äärmuslikes samaaegsuse tingimustes suudab süsteem samaaegselt käsitleda maksimaalselt 80 dünaamilist HTTP-päringut.
Kui soovite mahtu veelgi suurendada, peaks keskenduma mälukasutuse vähendamisele protsessi kohta.
- Luba OPcache: olemas
php.iniKeskmise suurusega konfiguratsioonopcache.enable=1jaopcache.memory_consumption=256Baitkoodide vahemällu salvestamine võib vähendada ühe protsessi mälukasutust 200 MB-lt 60–100 MB-ni. - Mõistlik mälupiirangu kontrollWill
php.inikeskelmemory_limitPiiratud kuni128MVõi256MÜksikute ebanormaalsete skriptide vältimisekspiiramatuSee tarbib palju mälu.
Kui ühe protsessi mälukasutus langeb 100 MB-ni...pm.max_children Seda saab ohutult uuendada 150 Lisaks on samaaegsuse võimekus peaaegu kahekordistunud.
Viidatud autoriteetsed seisukohad
Nginxi ametliku dokumentatsiooni soovituste kohaselt :
"FastCGI rakendusi tuleks ressursside ammendumise vältimiseks alati jälgida ajalõpudirektiividega."
(Allikas: Nginxi dokumendid)
Ametlik PHP käsiraamat ütleb selgelt:
"pm.max_children määrab loodavate lapseprotsesside maksimaalse arvu. See on kõige olulisem direktiiv."
(Allikas: PHP-FPM dokumentatsioon)
Need autoriteetsed seisukohad on meie praktikatega ideaalselt kooskõlas, tõestades, et optimeerimisloogika ei põhine ainult kogemustel, vaid ka standardiseeritud parimatel tavadel.
Kokkuvõte: minu seisukohad ja peamised tsitaadid
Suure samaaegsuse korral on protsessor mootor, mälu kütusepaak ja PHP-FPM laevastiku dispetšer.
Ükskõik kui võimas mootor ka poleks, kui kütusepaak pole piisavalt suur, siis konvoi kaugele ei sõida.
Tõelised eksperdid ei maksimeeri parameetreid pimesi, vaid arvutavad täpselt iga protsessi mälukasutuse, et vältida nii raiskamist kui ka ületäitumist.
Optimeerimise olemus on leida optimaalne tasakaal piiratud ressurssidega.
See pole ainult tehnoloogia, vaid ka filosoofia.
Seega ära usu, et "tuumade arv määrab kõik". See, mis tegelikult määrab samaaegsuse piiri, on sinu kontroll mälu üle.
Tegutse ja optimeeri oma VPS-i maksimaalse potentsiaalini, kasutades ära iga mälutilka.
Loodetavasti on teile abiks Chen Weiliangi blogis ( https://www.chenweiliang.com/ ) jagatud artikkel "8-tuumalisel 24 GB VPS-il hakkab mälu otsa saama? PHP-FPM protsesside basseini äärmuslik häälestamine HestiaCP all".
Jaga julgelt seda artikli linki: https://www.chenweiliang.com/cwl-34509.html