Настройка производительности PHP-FPM - всплески трафика
У меня есть веб-приложение, написанное на Laravel/PHP, которое находится на ранних стадиях и обычно обслуживает около 500 - 600 запросов/мин. Мы используем Maria DB и Redis для кэширования, и все находится на AWS.
Для событий, которые мы хотим продвигать на нашей платформе, мы отправляем push-уведомление (мобильная платформа) всем пользователям, что приводит к всплеску трафика примерно на 2 минуты, который приводит нас к 3,5 тыс. запросов/мин.
При текущем масштабе сервера это полностью загружает ЦП серверов приложений, которые обычно работают на частоте около 10% ЦП. Во время этого всплеска кластеры баз данных и Redis выглядят нормально.
Глядя на журналы, кажется, что все процессы рабочего пула PHP-FPM заняты и начинают ставить в очередь запросы от восходящего потока Nginx.
В настоящее время у нас есть:
три серверы m4.large (2 ядра, 8 ГБ ОЗУ каждое)
динамическое управление процессами PHP-FPM с максимальным количеством 120 дочерних процессов (серверов) на каждом поле
Мои вопросы:
1) Должны ли мы увеличить пул FPM? Кажется, что с точки зрения памяти мы, вероятно, приближаемся к нашему пределу
2) Должны ли мы снижаться пул FPM? Кажется возможным, что мы запускаем так много процессов, что процессор увязает и не может действительно завершить ни один из них. Интересно, получим ли мы лучшие результаты с меньшими затратами.
3) Должны ли мы просто использовать более крупные блоки с большим количеством оперативной памяти и процессора, что позволит нам добавить больше FPM-воркеров?
4) Есть ли какая-либо настройка производительности FPM, которую мы должны рассмотреть? Мы используем Opcache, однако должны ли мы переключиться на статическое управление процессами для FPM, чтобы сократить накладные расходы на процессы, вращающиеся вверх и вниз?
@Reed, мы максимально оптимизировали на данный момент, поэтому мы оцениваем аспект fpm.
Вы всегда можете увеличить размер пула, по крайней мере временно, до того, как произойдет продвижение, вы также можете добавить больше серверов в свою группу масштабирования или включить автоматическое масштабирование (если всплеск не превышает скорость, с которой AWS может загружать экземпляры).
Ответы 1
Слишком много дочерних процессов по отношению к количеству ядер.
Во-первых, вам нужно знать состояние сервера во время обычный и лопаться.
1) Проверьте количество процессов php-fpm.
ps -ef | grep 'php-fpm: pool' | wc -l
2) Проверьте средняя нагрузка. При 2 ядрах 2 и более означает, что начало работы задерживается.
top
htop
glances
3) В зависимости от сервиса начинаем настраивать с удвоенного количества ядер.
; Example
;pm.max_children = 120 ; normal) pool 5, load 0.1 / burst) pool 120, load 5 **Bad**
;pm.max_children = 4 ; normal) pool 4, load 0.1 / burst) pool 4, load 1
pm.max_children = 8 ; normal) pool 6, load 0.1 / burst) pool 8, load 2 **Good**
load 2 = Maximum Performance 2 cores
Более точно протестировать веб-сервер с нагрузкой, аналогичной фактической нагрузке, с помощью бенчмарка apache (ab).
ab -c100 -n10000 http://example.com
Time taken for tests: 60.344 seconds
Requests per second: 165.72 [#/sec] (mean)
100% 880 (longest request)
Это достойный совет. 120 процессов может быть много. Начать с количества ядер и масштабирования в тестах до тех пор, пока все не остановится, — это достойная стратегия оптимизации.
спасибо за этот ответ! Я просто хочу уточнить: у меня 125 максимальных серверов, 25 стартовых серверов. Первый лог PHP, который мы получили на одном из ящиков во время взрыва, был: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 32 total children.
Кроме того, когда вы говорите Check the load average. At 2 cores, 2 or more means that the work's starting delayed. . Вы имеете в виду, проверить загрузку процессора?
«Использование ЦП» и «средняя нагрузка» отличаются. tecmint.com/…
Какие-нибудь фрагменты неэффективного кода, которые вы могли бы настроить?