Cikkkönyvtár
Az, hogy egy szerver mennyi egyidejű felhasználót tud kezelni, nem a processzormagok számától, hanem az egyes folyamatok által felhasznált memóriától függ.
Ez a kijelentés provokációnak tűnhet, de ez a legvalóságosabb és legfájdalmasabb tapasztalat az üzemeltetési és karbantartási iparágban.
Miért a memória a legfőbb szűk keresztmetszet?
Sokan tudat alatt azt gondolják, hogy egy 8 magos CPU-val és 24 GB memóriával rendelkező VPS könnyedén képes több száz PHP-FPM folyamatot futtatni.
A valóságban azonban egyetlen PHP folyamat RSS memóriahasználata gyakran eléri a 200 MB-ot.
Ez az eredmény, amelyet a parancssoron keresztüli tényleges tesztelés során kaptunk:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
A HestiaCP összetett keretrendszerében és több plugint tartalmazó környezetében, különösen OPcache optimalizálás nélkül, a 200 MB a norma.
Ez azt jelenti, hogy a memória, nem pedig a CPU az a kemény korlát, amely meghatározza a maximális párhuzamosságot.
Ajánlott konfigurációs fájl (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
Paraméterszámítási logika és beállítási alap
| Konfigurációs paraméterek | Beállítási érték | Magszámítás és beállítás alapja |
|---|---|---|
| pm | dynamic | A dinamikus mód lehetővé teszi a folyamatok rugalmas hozzáadását vagy törlését a párhuzamossági követelmények alapján, kiegyensúlyozva a válaszidőt és a memória-kihasználtságot. |
| pm.max_children | 80 | 24 GB teljes memória a rendszermag levonásával és MySQL/FeleinekAz Nginx után körülbelül 16 GB marad a PHP számára.16,384 MB / 200 MB ≈ 81.9A 80-as érték beállítása teljesen kiküszöböli az OOM-ot (Out of Memory - Megfogyott a memória) nagy párhuzamosság esetén. |
| pm.start_servers | 16 | Az indításkor az előmelegítés a CPU-magok számának kétszeresére van állítva (8 mag × 2 = 16), hogy a szolgáltatás az újraindítás után azonnal kezelni tudja az alapvető párhuzamos működést. |
| pm.min_tartalék_szerverek | 8 | Állítsd a CPU magok számát 8 magra, hogy az új kérésekre bármikor válaszolni lehessen alacsony forgalmú időszakokban is. |
| pm.max_tartalék_szerverek | 24 | Állítsd a CPU-magok számának háromszorosára (8 mag × 3 = 24), hogy a forgalom visszaesése után mérsékelt számú folyamat maradjon meg, így kezelve az enyhe ingadozásokat. |
| pm.max_requests | 500 | Ha egyetlen folyamat eléri a 200 MB-os nagy bázist, a kérések számának 500-ra csökkentése megsemmisíti és újraépíti a folyamatot, ami gyorsabban kiküszöbölheti az implicit memóriaszivárgásokat. |
| pm.process_idle_timeout | 10s | Túllépő min_spare_servers A tétlen folyamatok automatikusan felszabadulnak és visszakerülnek a rendszermemóriába 10 másodpercnyi kérésmentesség után. |
Alapvető támogató beállítások és optimalizálási javaslatok
1. Időtúllépéses másnapossággátló mechanizmus
request_terminate_timeout = 60s Ez a kulcs.
Kényszeresen leállíthatja az adatbázis-holtpont vagy harmadik féltől származó API-blokkolás miatt elakadt folyamatokat.
Eközben az Nginx fastcgi_read_timeout Legalább 60 másodpercig meg kell őrizni, különben az ügyfél idő előtt megkapja. 504 Gateway Timeout.
2. Stratégiák a memória szűk keresztmetszetek leküzdésére
A maximum 80 egyidejű folyamat azt jelenti, hogy szélsőséges párhuzamos működési körülmények között a rendszer maximum 80 dinamikus HTTP-kérést képes egyszerre kezelni.
Ha tovább szeretnéd növelni a kapacitást, akkor a folyamatok memóriafelhasználásának csökkentésére kell összpontosítanod.
- Engedélyezze az OPcache-t: 在
php.iniKözepes konfigurációopcache.enable=1ésopcache.memory_consumption=256A bájtkód-gyorsítótárazás egyetlen folyamat memóriahasználatát 200 MB-ról 60~100 MB-ra csökkentheti. - A memory_limit ésszerű szabályozása:Akarat
php.iniközépsőmemory_limitKorlátozott128M或256MAz egyes rendellenes szkriptek megelőzése érdekébenkorlátlanSok memóriát fogyaszt.
Amikor egyetlen folyamat memóriahasználata 100 MB-ra csökken...pm.max_children Biztonságosan fejleszthető erre: 150 Ráadásul a párhuzamos működés lehetősége is csaknem megduplázódott.
Hivatkozott tekintélyes nézőpontok
A hivatalos Nginx dokumentációban található ajánlások szerint :
„A FastCGI alkalmazásokat mindig időtúllépési direktívákkal kell monitorozni az erőforrások kimerülésének megelőzése érdekében.”
(Forrás: Nginx dokumentáció)
A hivatalos PHP kézikönyv egyértelműen kimondja:
„A pm.max_children meghatározza a létrehozandó gyermekfolyamatok maximális számát. Ez a legfontosabb direktíva.”
(Forrás: PHP-FPM dokumentáció)
Ezek a mérvadó nézetek tökéletesen összhangban vannak a mi gyakorlatunkkal, bizonyítva, hogy az optimalizálási logika nemcsak tapasztalatokon, hanem szabványosított legjobb gyakorlatokon is alapul.
Konklúzió: Véleményem és főbb idézetek
Nagy párhuzamosság esetén a CPU a motor, a memória az üzemanyagtartály, a PHP-FPM pedig a flotta diszpécser.
Nem számít, milyen erős a motor, ha az üzemanyagtartály nem elég nagy, a konvoj nem fog messzire menni.
Az igazi szakértők nem vakon maximalizálják a paramétereket, hanem pontosan kiszámítják az egyes folyamatok memóriahasználatát, hogy elkerüljék a pazarlást és a túlcsordulást.
Az optimalizálás lényege, hogy korlátozott erőforrásokkal megtaláljuk az optimális egyensúlyt.
Ez nem csak technológia, hanem filozófia is.
Ezért ne hidd azt, hogy „a magok száma mindent meghatároz”. Ami igazán meghatározza a párhuzamos működés korlátját, az a memória feletti kontrollod.
Cselekedjen, és optimalizálja VPS-ét a lehető legjobban, minden csepp memóriát kihasználva.
Remélhetőleg hasznosnak találod a Chen Weiliang blogján ( https://www.chenweiliang.com/ ) megosztott "8 magos 24G VPS fogytán a memóriából? PHP-FPM folyamatkészlet extrém hangolása HestiaCP alatt" című cikket .
Nyugodtan oszd meg a cikk linkjét: https://www.chenweiliang.com/cwl-34509.html