Каталог статей
Кількість одночасних користувачів, яких може обробляти сервер, залежить не від кількості його ядер, а від того, скільки пам'яті споживає кожен процес.
Це твердження може звучати як провокація, але це найреальніший і найболючіший досвід у сфері експлуатації та технічного обслуговування.
Чому пам'ять є ключовим вузьким місцем?
Багато людей бачать VPS з 8-ядерним процесором та 24 ГБ пам'яті та підсвідомо думають, що вони можуть легко запускати сотні PHP-FPM процесів.
Однак насправді використання пам'яті RSS одним PHP-процесом часто сягає 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/RedisПісля Nginx для PHP залишається приблизно 16 ГБ.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 | Встановіть його на втричі більше, ніж кількість ядер процесора (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)
В офіційному посібнику PHP чітко зазначено:
"pm.max_children визначає максимальну кількість дочірніх процесів, які можна створити. Це найважливіша директива."
(Джерело: Документація PHP-FPM)
Ці авторитетні погляди ідеально узгоджуються з нашими практиками, доводячи, що логіка оптимізації ґрунтується не лише на досвіді, а й на стандартизованих передових практиках.
Висновок: Мої погляди та ключові цитати
У сценаріях з високим рівнем паралельності процесор — це двигун, пам'ять — паливний бак, а PHP-FPM — диспетчер автопарку.
Незалежно від потужності двигуна, якщо паливний бак недостатньо великий, колона не заїде далеко.
Справжні експерти не сліпо максимізують параметри, а радше точно розраховують використання пам'яті кожним процесом, щоб уникнути як марнування, так і переповнення.
Суть оптимізації полягає в пошуку оптимального балансу з обмеженими ресурсами.
Це не просто технологія, а й філософія.
Тому перестаньте вірити, що «кількість ядер визначає все». Те, що насправді визначає ліміт паралельності, — це ваш контроль над пам'яттю.
Вживіть заходів та оптимізуйте свій VPS до максимуму, використовуючи кожну краплю пам'яті.
Сподіваємося, що стаття «8-ядерному 24-гігабайтному VPS не вистачає пам'яті? Екстремальне налаштування пулу процесів PHP-FPM під HestiaCP», опублікована в блозі Ченя Вейляна ( https://www.chenweiliang.com/ ), буде вам корисною.
Не соромтеся поділитися посиланням на цю статтю: https://www.chenweiliang.com/cwl-34509.html