Справочник на статиите
Броят на едновременните потребители, които един сървър може да обработва, не зависи от броя на ядрата, които има, а от това колко памет консумира всеки процес.
Това твърдение може да звучи като провокация, но е най-реалното и болезнено преживяване в индустрията за експлоатация и поддръжка.
Защо паметта е основното пречка?
Много хора виждат VPS с 8-ядрен процесор и 24GB памет и подсъзнателно си мислят, че могат лесно да изпълняват стотици PHP-FPM процеси.
В действителност обаче, използването на RSS памет от един PHP процес често достига 200MB.
Това е резултатът, получен чрез реално тестване чрез командния ред:
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 (Out of Memory) по време на висока паралелност. |
| 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 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 документация)
Официалното ръководство за PHP ясно посочва:
„pm.max_children определя максималния брой дъщерни процеси, които могат да бъдат създадени. Това е най-важната директива.“
(Източник: PHP-FPM документация)
Тези авторитетни възгледи са напълно съобразени с нашите практики, доказвайки, че логиката на оптимизация не се основава само на опит, но и на стандартизирани най-добри практики.
Заключение: Моите гледни точки и ключови цитати
В сценарии с висока паралелност, процесорът е двигателят, паметта е резервоарът за гориво, а PHP-FPM е диспечерът на автопарка.
Без значение колко мощен е двигателят, ако резервоарът за гориво не е достатъчно голям, конвоят няма да стигне много далеч.
Истинските експерти не сляпо увеличават максимално параметрите, а по-скоро прецизно изчисляват използването на паметта за всеки процес, за да избегнат както разхищение, така и препълване.
Същността на оптимизацията е да се намери оптимален баланс с ограничени ресурси.
Това не е просто технология, а и философия.
Затова спрете да вярвате, че „броят на ядрата определя всичко“. Това, което наистина определя лимита за едновременност, е вашият контрол върху паметта.
Предприемете действия и оптимизирайте вашия VPS до пълния му потенциал, като се възползвате максимално от всяка капка памет.
Надяваме се, че статията „8-ядрен 24GB VPS с недостиг на памет? Екстремно настройване на PHP-FPM процесния пул под HestiaCP“, споделена в блога на Чен Вейлианг ( https://www.chenweiliang.com/ ), ще ви бъде полезна.
Чувствайте се свободни да споделите линка към тази статия: https://www.chenweiliang.com/cwl-34509.html