Հոդվածների տեղեկատու
Սերվերի կողմից միաժամանակյա օգտագործող օգտատերերի քանակը կախված չէ միջուկների քանակից, այլ յուրաքանչյուր պրոցեսի կողմից սպառվող հիշողության քանակից։
Այս հայտարարությունը կարող է սադրանք թվալ, բայց դա շահագործման և սպասարկման ոլորտում ամենաիրական և ցավոտ փորձառությունն է։
Ինչո՞ւ է հիշողությունը գլխավոր խոչընդոտը։
Շատերը տեսնում են 8-միջուկանի պրոցեսորով և 24 ԳԲ հիշողությամբ VPS և ենթագիտակցորեն կարծում են, որ կարող են հեշտությամբ գործարկել PHP-FPM հարյուրավոր պրոցեսներ։
Սակայն, իրականում, մեկ PHP պրոցեսի RSS հիշողության օգտագործումը հաճախ հասնում է 200 ՄԲ-ի ։
Սա հրամանի տողի միջոցով իրական փորձարկման արդյունքում ստացված արդյունքն է.
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP- ի բարդ շրջանակում և բազմապլագին միջավայրում, հատկապես առանց OPcache օպտիմալացման, 200 ՄԲ-ը նորմա է։
Սա նշանակում է, որ հիշողությունը, այլ ոչ թե պրոցեսորը, այն խիստ սահմանն է, որը որոշում է առավելագույն միաժամանակյա օգտագործումը։
Առաջարկվող կարգավորման ֆայլ (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
Պարամետրերի հաշվարկման տրամաբանությունը և կարգավորման հիմքը
| Կազմաձևման պարամետրեր | Արժեքի սահմանում | Հիմնական հաշվարկի և կարգավորման հիմքը |
|---|---|---|
| pm | dynamic | Դինամիկ ռեժիմը թույլ է տալիս առաձգականորեն ավելացնել կամ ջնջել գործընթացներ՝ հիմնվելով զուգահեռության պահանջների վրա, հավասարակշռելով արձագանքման արագությունը և հիշողության օգտագործումը։ |
| pm.max_children | 80 | 24 ԳԲ ընդհանուր հիշողություն՝ առանց համակարգի միջուկի և MySQL/RedisNginx-ից հետո PHP-ի համար մնում է մոտավորապես 16 ԳԲ։16,384 MB / 200 MB ≈ 81.980 սահմանելը կարող է ամբողջությամբ վերացնել OOM-ը (հիշողության բացակայությունը) բարձր միաժամանակյա օգտագործման դեպքում։ |
| pm.start_servers | 16 | Գործարկման ժամանակ նախնական տաքացումը սահմանվում է պրոցեսորի միջուկների քանակի կրկնակի չափով (8 միջուկ × 2 = 16)՝ ապահովելու համար, որ ծառայությունը կարողանա անմիջապես կարգավորել հիմնական զուգահեռ աշխատանքը վերագործարկումից հետո։ |
| pm.min_spare_servers | 8 | Սահմանեք պրոցեսորի միջուկների քանակը 8-ի՝ ապահովելու համար, որ նոր հարցումներին կարողանան պատասխանել ցանկացած պահի ցածր երթևեկության ժամանակահատվածներում։ |
| pm.max_spare_servers | 24 | Սահմանեք այն պրոցեսորի միջուկների թվի 3-ապատիկի վրա (8 միջուկ × 3 = 24)՝ երթևեկության նահանջից հետո պրոցեսների չափավոր քանակ պահպանելու և թույլ տատանումները կարգավորելու համար։ |
| pm.max_requests | 500 | Եթե մեկ պրոցեսը հասնում է 200 ՄԲ մեծ ծավալի, հարցումների քանակը մինչև 500 կրճատելը կքանդի և կվերականգնի այն, ինչը կարող է ավելի արագ մաքրել հիշողության անուղղակի արտահոսքերը։ |
| pm.process_idle_timeout | 10s | Գերազանցելով min_spare_servers Անգործուն գործընթացները ավտոմատ կերպով ազատվում են և վերադարձվում համակարգի հիշողություն 10 վայրկյան հարցումներ չանելուց հետո։ |
Հիմնական օժանդակ կարգավորումներ և օպտիմալացման առաջարկներ
1. Թայմաութ հակահումորային մեխանիզմ
request_terminate_timeout = 60s Դա է բանալին։
Այն կարող է հարկադրաբար դադարեցնել տվյալների բազայի փակուղու կամ երրորդ կողմի API-ի արգելափակման պատճառով խրված գործընթացները։
Միևնույն ժամանակ, Nginx-ը fastcgi_read_timeout Այն պետք է պահվի առնվազն 60 վայրկյան, հակառակ դեպքում հաճախորդը այն կստանա վաղաժամկետ։ 504 Gateway Timeout.
2. Հիշողության խցանումները հաղթահարելու ռազմավարություններ
Առավելագույնը 80 միաժամանակյա պրոցես նշանակում է, որ ծայրահեղ միաժամանակյա պայմաններում համակարգը կարող է միաժամանակ մշակել առավելագույնը 80 դինամիկ HTTP հարցում։
Եթե ցանկանում եք հետագայում բարելավել հզորությունը, ուշադրությունը պետք է կենտրոնացվի յուրաքանչյուր պրոցեսի հիշողության օգտագործման կրճատման վրա։
- Միացնել OPcache-ը:գոյություն
php.iniՄիջին կոնֆիգուրացիաopcache.enable=1及opcache.memory_consumption=256Բայթկոդի քեշավորումը կարող է կրճատել մեկ պրոցեսի հիշողության օգտագործումը 200 ՄԲ-ից մինչև 60~100 ՄԲ։ - memory_limit-ի ողջամիտ վերահսկողություն:Ուիլ
php.iniմիջինmemory_limitՍահմանափակված է128M或256MԱնհատական աննորմալ սցենարները կանխելու համարանսահմանափակԱյն շատ հիշողություն է սպառում։
Երբ մեկ պրոցեսի հիշողության օգտագործումը նվազում է մինչև 100 ՄԲ...pm.max_children Այն կարող է անվտանգ կերպով արդիականացվել մինչև 150 Բացի այդ, միաժամանակյա հնարավորությունները գրեթե կրկնապատկվել են։
Մեջբերված հեղինակավոր տեսակետներ
Համաձայն Nginx-ի պաշտոնական փաստաթղթերի առաջարկությունների ՝
«FastCGI հավելվածները միշտ պետք է վերահսկվեն ժամանակի ավարտի հրահանգներով՝ ռեսուրսների սպառումը կանխելու համար»։
(Աղբյուր՝ Nginx Docs)
PHP-ի պաշտոնական ձեռնարկում հստակ նշված է.
"pm.max_children-ը սահմանում է ստեղծելու ենթակա դուստր պրոցեսների առավելագույն քանակը։ Սա ամենակարևոր հրահանգն է։"
(Աղբյուր՝ PHP-FPM փաստաթղթեր)
Այս հեղինակավոր տեսակետները կատարելապես համապատասխանում են մեր գործելակերպին՝ ապացուցելով, որ օպտիմալացման տրամաբանությունը հիմնված է ոչ միայն փորձի, այլև ստանդարտացված լավագույն գործելակերպի վրա։
Եզրակացություն. Իմ տեսակետները և հիմնական մեջբերումները
Բարձր զուգահեռականության սցենարներում CPU-ն շարժիչն է, հիշողությունը՝ վառելիքի բաք, իսկ PHP-FPM-ը՝ ավտոպարկի դիսպետչերը։
Անկախ շարժիչի հզորությունից, եթե վառելիքի բաքը բավականաչափ մեծ չէ, շարասյունը շատ հեռու չի գնա։
Իսկական մասնագետները կուրորեն չեն առավելագույնի հասցնում պարամետրերը, այլ ճշգրիտ հաշվարկում են յուրաքանչյուր պրոցեսի հիշողության օգտագործումը՝ խուսափելու համար թե՛ վատնումից, թե՛ գերբեռնվածությունից։
Օպտիմալացման էությունը սահմանափակ ռեսուրսներով օպտիմալ հավասարակշռություն գտնելն է։
Սա ոչ միայն տեխնոլոգիա է, այլև փիլիսոփայություն ։
Հետևաբար, դադարեք հավատալ, որ «միջուկների քանակը որոշում է ամեն ինչ»։ Միաժամանակյա օգտագործման սահմանը իրականում որոշում է հիշողության նկատմամբ ձեր վերահսկողությունը։
Գործողություններ ձեռնարկեք և օպտիմալացրեք ձեր VPS-ը մինչև դրա ողջ ներուժը՝ առավելագույնս օգտագործելով հիշողության յուրաքանչյուր կաթիլը։
Հուսով եմ, որ Չեն Վեյլիանգի բլոգում ( https://www.chenweiliang.com/ ) տեղադրված «8-միջուկանի 24G VPS-ի հիշողությունը սպառվու՞մ է։ PHP-FPM պրոցեսների լողավազանի ծայրահեղ կարգավորում HestiaCP-ի ներքո» հոդվածը օգտակար կլինի ձեզ համար։
Ազատորեն կիսվեք այս հոդվածի հղումով՝ https://www.chenweiliang.com/cwl-34509.html