Article Directory
Broj istovremenih korisnika koje server može obraditi ne zavisi od broja jezgara, već od toga koliko memorije svaki proces troši.
Ova izjava možda zvuči kao provokacija, ali to je najstvarnije i najbolnije iskustvo u industriji operacija i održavanja.
Zašto je memorija ključno usko grlo?
Mnogi ljudi vide VPS sa 8-jezgrenim CPU-om i 24 GB memorije i podsvjesno misle da mogu lako pokrenuti stotine PHP-FPM procesa.
Međutim, u stvarnosti, korištenje RSS memorije jednog PHP procesa često iznosi i do 200 MB.
Ovo je rezultat dobijen stvarnim testiranjem putem komandne linije:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
U HestiaCP -ovom složenom okviru i okruženju s više dodataka, posebno bez OPcache optimizacije, 200 MB je norma.
To znači da je memorija, a ne CPU, fiksno ograničenje koje određuje maksimalnu konkurentnost.
Preporuč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čunavanja parametara i osnova podešavanja
| Parametri konfiguracije | Vrijednost podešavanja | Osnova za izračun i podešavanje jezgra |
|---|---|---|
| pm | dynamic | Dinamički način rada omogućava elastično dodavanje ili brisanje procesa na osnovu zahtjeva za konkurentnost, balansirajući brzinu odziva i iskorištenost memorije. |
| pm.max_children | 80 | 24 GB ukupne memorije bez sistemskog kernela i MySQL/RedisNakon Nginx-a, za PHP ostaje otprilike 16 GB.16,384 MB / 200 MB ≈ 81.9Postavljanje na 80 može potpuno eliminirati OOM (Out of Memory - nedostatak memorije) tokom visoke konkurentnosti. |
| pm.start_servers | 16 | Predgrijavanje pri pokretanju postavljeno je na dvostruki broj CPU jezgara (8 jezgara × 2 = 16) kako bi se osiguralo da servis može odmah obraditi osnovnu konkurentnost nakon ponovnog pokretanja. |
| pm.min_rezervni_serveri | 8 | Postavite broj jezgara CPU-a na 8 jezgara kako biste osigurali da se na nove zahtjeve može odgovoriti u bilo kojem trenutku tokom perioda niskog prometa. |
| pm.max_spare_servers | 24 | Postavite ga na 3 puta veći broj CPU jezgara (8 jezgara × 3 = 24) kako biste zadržali umjeren broj procesa nakon što se promet smanji, te kako biste se nosili s blagim fluktuacijama. |
| pm.max_requests | 500 | Ako jedan proces dostigne veliku bazu od 200 MB, smanjenje broja zahtjeva na 500 prije uništavanja i ponovne izgradnje može brže očistiti implicitna curenja memorije. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Neaktivni procesi se automatski oslobađaju i vraćaju u sistemsku memoriju nakon 10 sekundi bez zahtjeva. |
Osnovne prateće postavke i prijedlozi za optimizaciju
1. Mehanizam protiv mamurluka s vremenskim ograničenjem
request_terminate_timeout = 60s To je ključ.
Može prisilno prekinuti procese koji su zaglavljeni zbog zastoja u bazi podataka ili blokiranja API-ja treće strane.
U međuvremenu, Nginx-ov fastcgi_read_timeout Mora se čuvati najmanje 60 sekundi, u suprotnom će ga klijent primiti prijevremeno. 504 Gateway Timeout.
2. Strategije za prevazilaženje uskih grla memorije
Maksimalno 80 istovremenih procesa znači da pod ekstremnim uslovima konkurentnosti, sistem može istovremeno obraditi maksimalno 80 dinamičkih HTTP zahtjeva.
Ako želite dodatno poboljšati kapacitet, fokus bi trebao biti na smanjenju korištenja memorije po procesu.
- Omogućite OPcache：在
php.iniSrednja konfiguracijaopcache.enable=1iopcache.memory_consumption=256Keširanje bajtkoda može smanjiti korištenje memorije jednog procesa sa 200 MB na 60~100 MB. - Razumna kontrola memorijskog limita：将
php.inisrednjimemory_limitOgraničeno na128M或256MDa biste spriječili pojedinačne abnormalne skripteneograničenoTroši mnogo memorije.
Kada potrošnja memorije jednog procesa padne na 100 MB...pm.max_children Može se bezbedno nadograditi na 150 Osim toga, mogućnost konkurentnosti se gotovo udvostručila.
Citirana autoritativna gledišta
Prema preporukama u službenoj Nginx dokumentaciji :
"FastCGI aplikacije treba uvijek pratiti pomoću direktiva o vremenskom ograničenju kako bi se spriječilo iscrpljivanje resursa."
(Izvor: Nginx dokumentacija)
Zvanični PHP priručnik jasno navodi:
"pm.max_children definira maksimalan broj podređenih procesa koji će biti kreirani. Ovo je najvažnija direktiva."
(Izvor: PHP-FPM dokumentacija)
Ovi autoritativni stavovi su savršeno usklađeni s našim praksama, dokazujući da logika optimizacije nije zasnovana samo na iskustvu, već i na standardiziranim najboljim praksama.
Zaključak: Moji stavovi i ključni citati
U scenarijima s visokom konkurentnošću, CPU je motor, memorija je rezervoar za gorivo, a PHP-FPM je dispečer voznog parka.
Bez obzira koliko je motor snažan, ako rezervoar za gorivo nije dovoljno velik, konvoj neće stići daleko.
Pravi stručnjaci ne maksimiziraju slijepo parametre, već precizno izračunavaju korištenje memorije svakog procesa kako bi izbjegli i rasipanje i prelijevanje.
Suština optimizacije je pronaći optimalnu ravnotežu s ograničenim resursima.
Ovo nije samo tehnologija, već i filozofija.
Stoga, prestanite vjerovati da "broj jezgara određuje sve". Ono što zaista određuje ograničenje konkurentnosti je vaša kontrola nad memorijom.
Preduzmite akciju i optimizirajte svoj VPS do njegovog punog potencijala, maksimalno iskoristivši svaku kap memorije.
Nadam se da će vam članak "8-core 24GB VPS ostaje bez memorije? Ekstremno podešavanje PHP-FPM procesnog skupa pod HestiaCP" podijeljen na Chen Weiliangovom blogu ( https://www.chenweiliang.com/ ) biti od pomoći.
Slobodno podijelite link ovog članka: https://www.chenweiliang.com/cwl-34509.html