Article Directory
Сервер бир эле учурда канча колдонуучуну иштете алаары анын канча ядросунан эмес, ар бир процесс канча эс тутумду керектей тургандыгынан көз каранды.
Бул билдирүү провокация сыяктуу угулушу мүмкүн, бирок бул эксплуатация жана техникалык тейлөө тармагындагы эң реалдуу жана оор тажрыйба.
Эмне үчүн эс тутум негизги тоскоолдук болуп саналат?
Көптөгөн адамдар 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 МБ норма болуп саналат.
Бул максималдуу параллелдүүлүктү аныктоочу катуу чектөө CPU эмес, эс тутум экенин билдирет.
Сунушталган конфигурация файлы (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.9Аны 80ге коюу жогорку параллелдүүлүк учурунда OOM (Эстутумсуздук) функциясын толугу менен жок кыла алат. |
| pm.start_servers | 16 | Кызмат кайра иштетилгенден кийин негизги параллелдүүлүктү заматта иштете алышы үчүн, ишке киргизүүдө алдын ала ысытуу CPU ядролорунун санынан эки эсе көп (8 ядро × 2 = 16) деп коюлган. |
| pm.min_spare_servers | 8 | Трафик аз болгон мезгилде жаңы суроо-талаптарга каалаган убакта жооп берүүгө мүмкүнчүлүк берүү үчүн CPU өзөктөрүнүн санын 8ге коюңуз. |
| pm.max_spare_servers | 24 | Трафик азайгандан кийин процесстердин орточо санын сактап калуу үчүн, акырындык менен өзгөрүүлөрдү башкаруу үчүн, аны CPU ядролорунун санынан 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's fastcgi_read_timeout Аны кеминде 60 секунд кармоо керек, болбосо кардар аны мөөнөтүнөн мурда алат. 504 Gateway Timeout.
2. Эс тутумдагы кыйынчылыктарды жеңүү стратегиялары
Эң көп дегенде 80 бир эле учурда жүргүзүлүүчү процесстер, өзгөчө бир эле учурда иштөө шарттарында система бир эле учурда эң көп дегенде 80 динамикалык HTTP суроо-талаптарын иштете алаарын билдирет.
Эгер сиз кубаттуулукту андан ары жакшыртууну кааласаңыз, көңүл ар бир процессте эстутумдун колдонулушун азайтууга бурулушу керек.
- OPcache иштетүү: in
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 ядролуу 24 ГБ VPSтин эс тутуму түгөнүп баратабы? HestiaCP астында PHP-FPM процесстер пулун экстремалдык түрдө жөндөө" деген макала сизге пайдалуу болот деп үмүттөнөбүз.
Бул макаланын шилтемеси менен бөлүшүүдөн тартынбаңыз: https://www.chenweiliang.com/cwl-34509.html