NGINX/PHP-FPM процесс всплески и безудержные процессы
Недавно я перешел на NGINX/PHP-FPM для запуска своих форумов.
В большинстве случаев сайт работает красиво, очень быстро, и я очень доволен этим. Это на 13 ядерном /30+ ГБ экземпляре памяти с AWS, так что достаточно ресурсов (было на 8 ядер, 16 ГБ раньше с Apache.)
Итак, в большинстве случаев у нас 6 или 7 процессов PHP-FPM, и все хорошо в мире;
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27676 apache 20 0 499m 34m 19m R 49.2 0.1 0:06.33 php-fpm
27669 apache 20 0 508m 48m 24m R 48.2 0.1 0:10.84 php-fpm
27661 apache 20 0 534m 75m 26m R 45.9 0.2 0:16.18 php-fpm
27671 apache 20 0 531m 69m 21m R 43.9 0.2 0:09.85 php-fpm
27672 apache 20 0 501m 41m 23m R 32.9 0.1 0:09.18 php-fpm
27702 apache 20 0 508m 40m 16m R 23.6 0.1 0:00.94 php-fpm
Ну, вроде хорошо. Используется много процессоров, но есть только несколько из них, так что все в порядке.
Затем, казалось бы, из ниоткуда, я порождаю кучу процессов (в прошлый раз у нас было 52), и каждый использует 8% CPU. Вам не нужно быть хорошим в этом, чтобы знать, что 52 * 8 много.
Теперь я установил для max_children значение 40 (это было 50.)
pm.max_children = 40
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 100
Ограничение памяти в php.ini составляет 128 МБ.
Итак, я понимаю, почему у меня так много процессов - это нормально, я их настроил. Что меня интересует, так это то, что если на процесс приходится 8% процессоров - это слишком много? И, может быть, мои процессы остаются живы слишком долго?
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 26575 0.0 0.0 499572 4944 ? Ss 18:23 0:01 php-fpm: master process (/etc/php-fpm.conf)
apache 28161 16.1 0.1 516644 47588 ? S 19:06 0:08 php-fpm: pool www
apache 28164 18.0 0.1 525044 59644 ? S 19:06 0:07 php-fpm: pool www
apache 28166 18.6 0.1 513152 41388 ? R 19:06 0:06 php-fpm: pool www
apache 28167 23.2 0.1 515520 47092 ? S 19:06 0:07 php-fpm: pool www
apache 28168 15.2 0.1 515804 49320 ? S 19:06 0:04 php-fpm: pool www
apache 28171 17.3 0.1 514484 43752 ? S 19:06 0:04 php-fpm: pool www
Когда я пишу это, у него 19:08 вечера - так что дочерние процессы работали в течение 2 минут и, вероятно, послужили многим за это время (на форумах было 700 человек).
Так что - супер хотелось услышать совет / критику / мнение. В последнее время у меня было так много простоя, что я снова собираюсь настроить Apache, и я бы хотел придерживаться этого.
Заранее спасибо.
РЕДАКТИРОВАТЬ
Это график Битнами, показывающий пики и как быстро они возникают (это 24 часа)
РЕДАКТИРОВАТЬ № 2
nginx.conf можно найти здесь.
РЕДАКТИРОВАТЬ № 3
Я поднял свои цифры. Это выглядит хорошо, но все еще заставляет меня немного нервничать.
pm.max_children = 100
pm.start_servers = 25
pm.min_spare_servers = 25
pm.max_spare_servers = 50
pm.max_requests = 500
РЕДАКТИРОВАТЬ № 4
Итак, у меня было еще несколько простоев, и я настроил Splunk и New Relic, чтобы помочь мне следить за происходящим. Кажется, что нет времени ожидания процессора, и у меня все еще есть свободная память.
top - 17:30:37 up 10 days, 19:20, 2 users, load average: 24.61, 37.34, 25.68
Tasks: 151 total, 20 running, 131 sleeping, 0 stopped, 0 zombie
Cpu0 : 71.8%us, 27.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 73.7%us, 26.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 70.8%us, 29.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 69.3%us, 30.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 35062648k total, 28747980k used, 6314668k free, 438032k buffers
Swap: 0k total, 0k used, 0k free, 16527768k cached
Наблюдая за Splunk, это не похоже на его трафик - Googlebot сильно меня забивает, и я с подозрением относился к нему, но ничего конкретного.
1 ответ
Ну, вроде хорошо. Используется много процессоров, но есть только некоторые из них, так что все в порядке
Объем работы, выполняемой процессом, определяется количеством процессоров, которые он использует, - следовательно, это процент использования x за время его использования. Так что, если ваши процессы PHP используют много ресурсов ЦП, то это, как правило, хорошо - это значит, что они не ждут, пока что-то произойдет. С точки зрения системного администратора вы можете сделать больше ЦП доступным для других задач, но вы увеличите время, затрачиваемое PHP-процессом на обработку запроса.
И, конечно, если запросы поступают с постоянной скоростью, более длительный процесс их обработки означает, что в любой момент времени будет больше работать (или ждать запланированного), а больший объем памяти означает меньше памяти, доступной для кэширования VFS. Существует также риск того, что планировщик начнет с преимуществом выполнять задачи, а не давать им выполнять, что снижает общую пропускную способность.
Следовательно, вы должны стремиться к высокой загрузке процессора! (но низкая нагрузка).
Ограничение памяти в php.ini составляет 128 Мб
Это довольно высокий показатель, но поскольку загрузка ЦП высока, это указывает на то, что проблема не слишком большая, ЕСЛИ МНЕ, что для выполнения каждого запроса требуется много времени и много сборщика мусора - в этом сценарии форсирование более частой сборки мусора за счет сокращения ограничение памяти может реально улучшить производительность.
У меня было так много простоя в последнее время
Несмотря на это, я считаю, что APC намного надежнее, чем Xcache - и это, кажется, тенденция в том, что я читал в другом месте. Не имейте никакого опыта / данных о Zend Optimizer+, который должен быть в комплекте с будущими версиями PHP.
Я на грани настройки Apache снова, и я хотел бы придерживаться этого
Pre-fork apache + mod_php значительно быстрее, чем nginx + php-fpm при меньших объемах трафика - но nginx, по-видимому, обладает огромным преимуществом, когда скорость загрузки / запроса средняя - высокая по сравнению с аппаратной емкостью (что, как вам кажется, быть).
Если бы это был я, я бы внимательно посмотрел журналы, чтобы увидеть, вызваны ли скачки увеличением объема трафика / изменением профиля трафика / изменением времени отклика. Также внимательно изучаю кеширование и код. Вы можете временно запустить профилировщик для работающего сайта (используйте xhprof, а не xdebug для производственной системы).