Artikola Adresaro
La nombro de samtempaj uzantoj, kiujn servilo povas pritrakti, dependas ne de kiom da kernoj ĝi havas, sed de kiom da memoro ĉiu procezo konsumas.
Ĉi tiu deklaro eble sonas kiel provoko, sed ĝi estas la plej reala kaj dolora sperto en la funkciada kaj bontenada industrio.
Kial memoro estas la ĉefa proplempunkto?
Multaj homoj vidas VPS-on kun 8-kerna CPU kaj 24GB da memoro kaj subkonscie pensas, ke ili povas facile ruli centojn da PHP-FPM-procezoj.
Tamen, en realeco, la RSS-memoruzado de unuopa PHP-procezo ofte atingas 200MB.
Jen la rezulto akirita per fakta testado per komandlinio:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
En la kompleksa kadro kaj plur-kromaĵa medio de HestiaCP , precipe sen OPcache-optimumigo, 200MB estas la normo.
Tio signifas, ke memoro, ne CPU, estas la fiksa limo, kiu determinas maksimuman samtempecon.
Rekomendita agordodosiero (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
Logiko de parametrokalkulo kaj bazo de agordo
| Parametroj de agordo | Agordo de valoro | Kerna kalkulo kaj agorda bazo |
|---|---|---|
| pm | dynamic | Dinamika reĝimo permesas la elastan aldonon aŭ forigon de procezoj bazitaj sur samtempecaj postuloj, balancante respondrapidecon kaj memorutiligon. |
| pm.max_infanoj | 80 | 24GB totala memoro minus la sistema kerno kaj MySQL/RedisPost Nginx, restas proksimume 16GB por PHP.16,384 MB / 200 MB ≈ 81.9Agordi ĝin al 80 povas tute forigi OOM (Elmemoro) dum alta samtempeco. |
| pm.start_servers | 16 | Antaŭvarmiĝo ĉe starto estas agordita al duobla nombro de CPU-kernoj (8 kernoj × 2 = 16) por certigi, ke la servo povas tuj pritrakti bazan samtempecon post rekomenco. |
| pm.min_rezervaj_serviloj | 8 | Agordu la nombron de CPU-kernoj al 8 kernoj por certigi, ke novaj petoj povas esti responditaj iam ajn dum periodoj de malalta trafiko. |
| pm.max_spare_servers | 24 | Agordu ĝin al 3-obla nombro da CPU-kernoj (8 kernoj × 3 = 24) por konservi moderan nombron da procezoj post kiam la trafiko retiriĝas, por pritrakti mildajn fluktuojn. |
| pm.max_petoj | 500 | Se unuopa procezo atingas grandan bazon de 200MB, redukti la nombron de petoj al 500 detruos kaj rekonstruos la procezon, kio povas pli rapide purigi implicajn memorlikojn. |
| pm.process_idle_timeout | 10s | Superante min_spare_servers Neaktivaj procezoj estas aŭtomate liberigitaj kaj resenditaj al la sistemmemoro post 10 sekundoj sen petoj. |
Esencaj Subtenaj Agordoj kaj Optimumigaj Sugestoj
1. Kontraŭpostebria mekanismo por paŭzo
request_terminate_timeout = 60s Tio estas la ŝlosilo.
Ĝi povas perforte fini procezojn, kiuj estas blokitaj pro datumbaza blokado aŭ triaparta API-blokado.
Dume, la fastcgi_read_timeout Ĝi devas esti konservita almenaŭ 60 sekundojn, alie la kliento ricevos ĝin trofrue. 504 Gateway Timeout.
2. Strategioj por superi memorajn proplempunktojn
Maksimumo de 80 samtempaj procezoj signifas, ke sub ekstremaj samtempecaj kondiĉoj, la sistemo povas pritrakti maksimumon de 80 dinamikaj HTTP-petoj samtempe.
Se vi volas plu plibonigi la kapaciton, la fokuso devus esti redukti la memoruzon por ĉiu procezo.
- Ebligu OPcache: en
php.iniMeza konfiguracioopcache.enable=1kajopcache.memory_consumption=256Bajtkoda kaŝmemorigo povas redukti la memoruzon de unuopa procezo de 200MB ĝis 60~100MB. - Racia kontrolo de memoro_limoVolo
php.inimezamemory_limitLimigita al128M或256MPor preventi individuajn nenormalajn skriptojnsenlimaĜi konsumas multan memoron.
Kiam la memoruzado de unuopa procezo falas al 100MB...pm.max_children Ĝi povas esti sekure ĝisdatigita al 150 Krome, la samtempeca kapablo preskaŭ duobliĝis.
Aŭtoritataj vidpunktoj cititaj
Laŭ la rekomendoj en la oficiala Nginx-dokumentaro :
"Aplikaĵoj FastCGI ĉiam estu monitorataj per tempolimdirektivoj por malhelpi elĉerpiĝon de rimedoj."
(Fonto: Nginx Dokumentoj)
La oficiala PHP-manlibro klare deklaras:
"pm.max_children difinas la maksimuman nombron de kreotaj idaj procezoj. Ĉi tiu estas la plej grava direktivo."
(Fonto: Dokumentaro de PHP-FPM)
Ĉi tiuj aŭtoritataj vidpunktoj perfekte kongruas kun niaj praktikoj, pruvante ke optimumiga logiko ne nur baziĝas sur sperto, sed ankaŭ sur normigitaj plej bonaj praktikoj.
Konkludo: Miaj Vidpunktoj kaj Ŝlosilaj Citaĵoj
En alt-samkonkurencaj scenaroj, la CPU estas la motoro, la memoro estas la benzinujo, kaj PHP-FPM estas la flotasendanto.
Ne gravas kiom potenca estas la motoro, se la benzinujo ne estas sufiĉe granda, la konvojo ne iros tre malproksimen.
Veraj fakuloj ne blinde maksimumigas la parametrojn, sed prefere precize kalkulas la memoruzon de ĉiu procezo por eviti kaj malŝparon kaj superfluon.
La esenco de optimumigo estas trovi la optimuman ekvilibron kun limigitaj rimedoj.
Ĉi tio estas ne nur teknologio, sed ankaŭ filozofio.
Tial, ĉesu kredi, ke "la nombro da kernoj determinas ĉion." Tio, kio vere determinas la samtempecan limon, estas via kontrolo super memoro.
Agu kaj optimumigu vian VPS-on laŭ ĝia plena potencialo, plej bone utiligante ĉiun guton da memoro.
Espereble, la artikolo "Ĉu 8-kerna 24GB VPS elĉerpas memoron? Ekstrema agordado de PHP-FPM-proceza naĝejo sub HestiaCP" dividita en la blogo de Chen Weiliang ( https://www.chenweiliang.com/ ) estos helpema al vi.
Bonvolu kunhavigi la ligilon al ĉi tiu artikolo: https://www.chenweiliang.com/cwl-34509.html