У меня ситуация, при которой происходит следующее:
Мы находимся на линоде с 8-ядерным процессором, 8 ГБ оперативной памяти, 2,6 ГГц - используя nginx + php-fpm - мы получаем чрезвычайно высокие графики использования процессора (что мы не хотим быть таким плохим соседом VPS) ...
У нас на сайте одновременно находится около 100 пользователей - так что эта ситуация также невероятно смущает, - что наш процессор загружен очень часто.
Мы используем очень неизвестный, возможно, требующий интенсивного использования процессоров php, сомнительно ужасный фреймворк вместо хорошо известных, хорошо задокументированных, хорошо созданных других фреймворков, таких как wordpress или drupal, в которых есть МНОГО документации по кешированию (а также плагины которые обрабатывают кеширование) php на платформе nginx + php_fpm.
Таким образом, у нас есть около 6 открытых процессов php-fpm, которые при ЗАПУСКЕ потребляют по отдельности БОЛЬШОЕ (30+, а часто почти 99%) количество ЦП - и я действительно не имею ни малейшего представления, как остановить их от использования такого количества ЦП. . Я не могу сказать, какие скрипты php вызывают эти всплески, потому что они происходят постоянно ... обычно работают только 1 или 2, но когда выполняются все 6, мы максимизируем все 8 процессоров.
Мой файл pool.d / www.conf имеет следующие настройки:
pm = dynamic
pm.max_children = 10
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
Мы сделали эту настройку ^, потому что, как я это интерпретирую, наша память на самом деле потрясающая (htop показывает, что используется 472/7000 МБ, без подкачки и т. Д.), И мы можем обрабатывать гораздо больше процессов и разбивать строку, ожидающую, чтобы получить обработано - НО, к сожалению, поскольку каждый процесс слишком интенсивен для нашего процессора во время работы - мы в конечном итоге перегружаем наш процессор - поэтому мы не можем обрабатывать достаточное количество процессов.
Вопрос - что мы можем сделать с уменьшить использование процессора php-fpm, чтобы мы могли увеличить настройки в этом файле conf пула для php-fpm - а также да, /var/log/php5-fpm.log кричит на нас, чтобы мы увеличивали количество наших детей и настраивали / увеличивали наши минимальные / максимальные / стартовые серверы. Но это делает нашу среднюю нагрузку сумасшедшей, как говорилось ранее. Как мы можем сделать это без обязательного использования кеша или какие у нас есть варианты?
Моя идея? Я читал кое-что об использовании cpulimit, чтобы гарантировать, что ни один процесс не займет больше выделенного количества ЦП, но замедлит ли это работу, чтобы ее нельзя было использовать? Или при этом мы могли бы увеличить нашу способность запускать больше, чем несколько процессов - я также подумал о запуске двух пулов - один для нашего прямого веб-сайта (с которым сталкиваются клиенты), а другой для внутреннего интерфейса (который влияет на наш прямой сайт, когда время -потребляющие отчеты составляются).
Я провел несколько дней, исследуя эту тему, гуглил и т. Д. - и это сложно, потому что ситуация каждого настолько уникальна для их системы - проблема заключается в такой конкретной неслыханной, возможно, плохо написанной - структуре - создает трудно найти решение. Мы также не можем просто отказаться от этого фреймворка - я должен найти какое-то решение.
ОБНОВЛЕНИЕ: я реализовал memcache для хранения сеансов php - потому что фреймворк сильно зависит от пользовательских сеансов, а природа нашей системы такова, что сотрудники часто используют несколько вкладок одновременно - каждая проверяет сеансы, чтобы подтвердить способности / данные пользователя / и т. ... так что я надеюсь увидеть некоторое увеличение производительности от этого - добро пожаловать, прокомментируйте это, если хотите - я посмотрю, как это пойдет завтра, когда мы пройдем через наши пиковые времена с большим объемом.
Пара вещей, которые следует учитывать (заранее извиняюсь, если вы уже это учли): Прежде всего, убедитесь, что вы оптимизировали конфигурацию nginx и вызывайте php-fpm только в случае крайней необходимости. Последнее, что вы хотите сделать, - это позволить php обрабатывать такие вещи, как статические HTML-страницы (что он с радостью сделает).
Во-вторых, поскольку вы используете php-fpm, я предлагаю более агрессивно подходить к вопросу о том, как долго дети php-fpm могут жить. Вам нужно найти золотую середину между недолговечными потоками / дочерними элементами и стабильностью. ИМХО, значения по умолчанию php-fpm слишком щедры для любой производственной системы. Чем дольше воркеру разрешено обслуживать запросы, тем более нестабильным он будет. Также существует более высокий риск утечки памяти, и если эта структура, на которую вы ссылаетесь, имеет ошибки, такие как бесконечные циклы, которые могут вызывать у вас проблемы с загрузкой процессора, это не должно повредить.
Я бы уменьшил количество для pm.max_requests для ваших производственных бассейнов. Я думаю, что по умолчанию 200. Я бы начал с 50 и посмотрел, к чему это приведет.
В случае неудачи / дополнения к этому вы также можете попробовать эти глобальные параметры (AFAIK все они отключены по умолчанию):
emergency_restart_threshold 3
emergency_restart_interval 1m
process_control_timeout 5s
Что это значит? Если 3 дочерних процесса PHP-FPM завершаются с SIGSEGV или SIGBUS (т.е. сбой) в течение 1 минуты, предполагается, что PHP-FPM перезапустится автоматически. Дочерние процессы ждут 5 секунд реакции на сигналы от мастера.
Вот хороший обзор всех параметров конфигурации, которые я упомянул здесь, а также других: http://myjeeva.com/php-fpm-configuration-101.html
Надеюсь, эти советы вам помогут! Не забудьте настроить и наблюдать, к сожалению, для всего этого нет практического правила, как вы заметили, существует слишком много переменных, которые влияют на поведение и стабильность PHP.
Наконец, задокументировано средство ограничения ЦП, о котором вы спрашивали. Вот, но я прибегу к нему только в том случае, если вы исчерпаете все остальные варианты. Если вы выберете этот путь, я определенно буду следить за возможным взаимодействием между настройками PHP-FPM и вашей конфигурацией limits.conf. В таком случае etckeeper может быть палочкой-выручалочкой! :)
Удачи!
Рубен
Вы ведь используете кеширование кода операции?
Раньше здесь использовался APC, но он долгое время был ошибочным, и был заменен на Zend Opcache, который теперь является частью PHP, начиная с версии 5.5, и имеет обратный порт в PECL для версий 5.3 и 5.4.