Rakstu katalogs
Vienlaicīgu lietotāju skaits, ko serveris var apstrādāt, nav atkarīgs no tā, cik kodolu tam ir, bet gan no tā, cik daudz atmiņas patērē katrs process.
Šis apgalvojums var izklausīties pēc provokācijas, taču tā ir visreālākā un sāpīgākā pieredze ekspluatācijas un apkopes nozarē.
Kāpēc atmiņa ir galvenais šķērslis?
Daudzi cilvēki, redzot VPS ar 8 kodolu centrālo procesoru un 24 GB atmiņu, zemapziņā domā, ka tie var viegli palaist simtiem PHP-FPM procesu.
Tomēr patiesībā viena PHP procesa RSS atmiņas izmantošana bieži vien sasniedz pat 200 MB.
Šis ir rezultāts, kas iegūts, veicot faktisko testēšanu, izmantojot komandrindu:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP sarežģītajā ietvarā un vairāku spraudņu vidē, īpaši bez OPcache optimizācijas, 200 MB ir norma.
Tas nozīmē, ka atmiņa, nevis centrālais procesors, ir stingrais ierobežojums, kas nosaka maksimālo vienlaicīgumu.
Ieteicamais konfigurācijas fails (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
Parametru aprēķināšanas loģika un iestatīšanas pamats
| Konfigurācijas parametri | Vērtības iestatīšana | Kodola aprēķins un iestatīšanas pamats |
|---|---|---|
| pm | dynamic | Dinamiskais režīms ļauj elastīgi pievienot vai dzēst procesus, pamatojoties uz vienlaicības prasībām, līdzsvarojot reakcijas ātrumu un atmiņas izmantošanu. |
| pm.max_bērni | 80 | 24 GB kopējā atmiņa, atskaitot sistēmas kodolu un MySQL/RedisPēc Nginx aptuveni 16 GB paliek PHP.16,384 MB / 200 MB ≈ 81.9Iestatot to uz 80, var pilnībā novērst OOM (Out of Memory — atmiņas trūkums) augstas vienlaicīguma laikā. |
| pm.start_servers | 16 | Uzsildīšana startēšanas laikā ir iestatīta uz divreiz lielāku centrālā procesora kodolu skaitu (8 kodoli × 2 = 16), lai nodrošinātu, ka pakalpojums pēc restartēšanas var nekavējoties apstrādāt pamata vienlaicīgumu. |
| pm.min_spare_servers | 8 | Iestatiet centrālā procesora kodolu skaitu uz 8 kodoliem, lai nodrošinātu, ka uz jauniem pieprasījumiem var atbildēt jebkurā laikā zemas datplūsmas periodos. |
| pm.max_spare_servers | 24 | Iestatiet to uz 3 reizēm lielāku par centrālā procesora kodolu skaitu (8 kodoli × 3 = 24), lai saglabātu mērenu procesu skaitu pēc datplūsmas samazināšanās, tādējādi apstrādājot nelielas svārstības. |
| pm.max_requests | 500 | Ja viens process sasniedz lielu bāzi 200 MB, pieprasījumu skaita samazināšana līdz 500 iznīcinās un atjaunos procesu, kas var ātrāk novērst netiešās atmiņas noplūdes. |
| pm.process_idle_timeout | 10s | Pārsniedzot min_spare_servers Dīkstāves procesi tiek automātiski atbrīvoti un atgriezti sistēmas atmiņā pēc 10 sekundēm, ja nav pieprasījumu. |
Būtiski atbalsta iestatījumi un optimizācijas ieteikumi
1. Taimauta pretpaģiru mehānisms
request_terminate_timeout = 60s Tā ir atslēga.
Tas var piespiedu kārtā pārtraukt procesus, kas ir iestrēguši datubāzes strupceļa vai trešās puses API bloķēšanas dēļ.
Tikmēr Nginx fastcgi_read_timeout Tas jāglabā vismaz 60 sekundes, pretējā gadījumā klients to saņems priekšlaicīgi. 504 Gateway Timeout.
2. Stratēģijas atmiņas sastrēgumu pārvarēšanai
Maksimāli 80 vienlaicīgi procesi nozīmē, ka ekstremālos vienlaicīguma apstākļos sistēma var vienlaikus apstrādāt ne vairāk kā 80 dinamiskus HTTP pieprasījumus.
Ja vēlaties vēl vairāk uzlabot jaudu, uzmanība jāpievērš atmiņas izmantošanas samazināšanai katrā procesā.
- Iespējot OPcache: iekšā
php.iniVidēja konfigurācijaopcache.enable=1unopcache.memory_consumption=256Baitkoda kešatmiņa var samazināt viena procesa atmiņas izmantošanu no 200 MB līdz 60–100 MB. - Saprātīga atmiņas limita kontroleVils
php.inividūmemory_limitIerobežots līdz128MVai256MLai novērstu atsevišķus patoloģiskus skriptusneierobežotsTas patērē daudz atmiņas.
Kad viena procesa atmiņas izmantošana samazinās līdz 100 MB...pm.max_children To var droši uzlabot līdz 150 Turklāt vienlaicīguma iespējas ir gandrīz divkāršojušās.
Citēti autoritatīvi viedokļi
Saskaņā ar oficiālajā Nginx dokumentācijā sniegtajiem ieteikumiem :
"FastCGI lietojumprogrammas vienmēr jāuzrauga ar taimauta direktīvām, lai novērstu resursu izsīkumu."
(Avots: Nginx dokumentācija)
Oficiālajā PHP rokasgrāmatā ir skaidri norādīts:
"pm.max_children nosaka maksimālo izveidojamo bērnu procesu skaitu. Šī ir vissvarīgākā direktīva."
(Avots: PHP-FPM dokumentācija)
Šie autoritatīvie uzskati pilnībā atbilst mūsu praksei, pierādot, ka optimizācijas loģika nav balstīta tikai uz pieredzi, bet arī uz standartizētu labāko praksi.
Secinājums: Mani viedokļi un galvenie citāti
Augstas vienlaicīguma scenārijos centrālais procesors ir dzinējs, atmiņa ir degvielas tvertne, un PHP-FPM ir autoparka dispečers.
Lai cik jaudīgs būtu dzinējs, ja degvielas tvertne nav pietiekami liela, konvojs tālu netiks.
Īsti eksperti akli nepārsniedz parametrus, bet gan precīzi aprēķina katra procesa atmiņas izmantošanu, lai izvairītos gan no izšķērdēšanas, gan pārpildes.
Optimizācijas būtība ir atrast optimālu līdzsvaru ar ierobežotiem resursiem.
Tā nav tikai tehnoloģija, bet arī filozofija.
Tāpēc pārtrauciet ticēt, ka "kodolu skaits nosaka visu". Tas, kas patiesībā nosaka vienlaicības ierobežojumu, ir jūsu kontrole pār atmiņu.
Rīkojieties un optimizējiet savu VPS, lai maksimāli izmantotu katru atmiņas pilienu.
Cerams, ka jums noderēs raksts "8 kodolu 24 GB VPS beidzas atmiņa? PHP-FPM procesu kopas ekstremāla regulēšana HestiaCP vidē", kas publicēts Čena Veiljana emuārā ( https://www.chenweiliang.com/ ).
Droši kopīgojiet šo raksta saiti: https://www.chenweiliang.com/cwl-34509.html