Директориум за статии
Бројот на истовремени корисници што еден сервер може да ги обработи не зависи од тоа колку јадра има, туку од тоа колку меморија троши секој процес.
Оваа изјава може да звучи како провокација, но тоа е најреалното и најболното искуство во индустријата за работење и одржување.
Зошто меморијата е клучното тесно грло?
Многу луѓе гледаат VPS со 8-јадрен процесор и 24GB меморија и потсвесно мислат дека лесно можат да извршуваат стотици PHP-FPM процеси.
Сепак, во реалноста, употребата на RSS меморија од еден PHP процес често достигнува и до 200 MB.
Ова е резултатот добиен преку вистинско тестирање преку командна линија:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Во сложената рамка и околината со повеќе додатоци на HestiaCP , особено без оптимизација на OPcache, 200MB е норма.
Ова значи дека меморијата, а не процесорот, е цврстата граница што ја одредува максималната истовременост.
Препорачана конфигурациска датотека (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 | 24GB вкупна меморија минус системското јадро и MySQL,/RedisПо Nginx, остануваат приближно 16GB за PHP.16,384 MB / 200 MB ≈ 81.9Поставувањето на 80 може целосно да го елиминира 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 | Ако еден процес достигне голема база од 200MB, намалувањето на бројот на барања на 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: 在
php.iniСредна конфигурацијаopcache.enable=1иopcache.memory_consumption=256Кеширањето на бајткод може да ја намали употребата на меморија на еден процес од 200MB на 60~100MB. - Разумна контрола на memory_limit：将
php.iniсреденmemory_limitОграничено на128MИли256MЗа да се спречат индивидуални абнормални сценаријанеограниченТроши многу меморија.
Откако употребата на меморија од еден процес ќе падне на 100MB...pm.max_children Може безбедно да се надгради на 150 Покрај тоа, можноста за истовремено работење е речиси двојно зголемена.
Цитирани авторитетни гледишта
Според препораките во официјалната документација за Nginx :
„FastCGI апликациите секогаш треба да се следат со директиви за истекување на времето за да се спречи исцрпување на ресурсите.“
(Извор: Nginx Docs)
Во официјалниот прирачник за PHP јасно е наведено:
„pm.max_children го дефинира максималниот број на детски процеси што треба да се креираат. Ова е најважната директива.“
(Извор: PHP-FPM документација)
Овие авторитативни ставови се совршено усогласени со нашите практики, докажувајќи дека логиката за оптимизација не се базира само на искуство, туку и на стандардизирани најдобри практики.
Заклучок: Мои гледишта и клучни цитати
Во сценарија со висока истовременост, процесорот е моторот, меморијата е резервоарот за гориво, а PHP-FPM е диспечерот на флотата.
Без разлика колку е моќен моторот, ако резервоарот за гориво не е доволно голем, конвојот нема да оди многу далеку.
Вистинските експерти не ги максимизираат параметрите на слепо, туку прецизно ја пресметуваат употребата на меморијата на секој процес за да избегнат и губење и прелевање.
Суштината на оптимизацијата е да се пронајде оптимална рамнотежа со ограничени ресурси.
Ова не е само технологија, туку и филозофија.
Затоа, престанете да верувате дека „бројот на јадра одредува сè“. Она што навистина го одредува ограничувањето на истовременоста е вашата контрола врз меморијата.
Преземете акција и оптимизирајте го вашиот VPS до неговиот максимален потенцијал, искористувајќи ја максимално секоја капка меморија.
Се надеваме дека статијата „8-јадрен 24G VPS останува без меморија? Екстремно подесување на PHP-FPM процесниот базен под HestiaCP“ споделена на блогот на Чен Вејлијанг ( https://www.chenweiliang.com/ ) ќе ви биде корисна.
Слободно споделете го линкот до овој напис: https://www.chenweiliang.com/cwl-34509.html