Скачки ЦП в 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% ЦП. Вам не нужно хорошо разбираться в этом, чтобы знать, что 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, и я хотел бы придерживаться этого.
Заранее спасибо.
РЕДАКТИРОВАТЬ
Это график Bitnami, показывающий всплески и как быстро они возникают (это 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, и я подозревал его, но ничего конкретного.
Ну вроде хорошо. Используется много ЦП, но их всего несколько, так что все в порядке
Объем работы, выполняемой процессом, определяется объемом процессора, который он использует - следовательно, это процент использования x время, в течение которого он используется. Так что, если ваши PHP-процессы используют много ЦП, это обычно хорошо - это означает, что он не ждет, пока что-то случится. С точки зрения системного администратора вы можете выделить больше ЦП для других задач, но вы увеличите количество времени, затрачиваемого PHP-процессом на обработку запроса.
И, конечно, если запросы поступают с постоянной скоростью, их обработка занимает больше времени, что означает, что одновременно будет больше процессов, работающих (или ожидающих планирования), а больший объем памяти означает, что для кэширования VFS доступно меньше памяти. Также существует риск того, что планировщик начнет упреждать задачи, а не позволять им завершаться, что снижает общую пропускную способность.
Следовательно, вы должен стремитесь к высокой загрузке процессора! (но небольшая нагрузка).
Ограничение памяти в php.ini - 128 МБ
Это довольно много, но поскольку загрузка ЦП высока, это указывает на то, что это не слишком большая проблема, ЕСЛИ каждый запрос занимает много времени и выполняет большую сборку мусора - в этом сценарии вынуждает более частую сборку мусора за счет сокращения ограничение памяти действительно может улучшить производительность.
В последнее время у меня было так много простоев
Как бы то ни было, я обнаружил, что APC намного надежнее Xcache - и это, похоже, тенденция в том, что я читал в других местах. У вас нет опыта / данных по Zend Optimizer +, который должен быть включен в будущие версии PHP.
Я снова собираюсь настроить Apache, и мне бы хотелось придерживаться этого
Pre-fork apache + mod_php значительно быстрее, чем nginx + php-fpm при меньших объемах трафика, но nginx, похоже, имеет огромное преимущество, когда скорость загрузки / запросов средняя - высокая по сравнению с мощностью оборудования (это то, где вы, кажется, быть).
Если бы это был я, я бы внимательно посмотрел в журналы, чтобы увидеть, вызваны ли всплески увеличением объема трафика / изменением профиля трафика / изменением времени отклика. Также внимательно смотрю на кеширование и код. Вы можете рассмотреть возможность временного запуска профилировщика на работающем сайте (используйте xhprof, а не xdebug для производственной системы).