Оптимизация fastcgi + php5
Запуск системы Debian с использованием lighttpd, php5, xcache и fastcgi. 2 ГБ оперативной памяти, 2 ядра, загрузка процессора менее 10% за 5 минут, среднее время пиковой нагрузки, использование менее 1 ГБ оперативной памяти.
Система запускает пользовательское веб-приложение сборки, которое очищает сайты поиска полетов, кэширование (результатов) не допускается, поэтому оно выполняется в режиме реального времени, и код, который делает это, использует libcurl и, вероятно, может выполняться довольно много секунд для каждого поиска. Также есть рекламная система OpenX.
В последнее время сайт периодически прерывается, и я создал простой тестовый скрипт, который просто печатает слово, чтобы убедиться, что он не связан с базой данных MySQL.
Из того, что я понимаю, когда мы запускаем кеширование кода операции, мы не должны запускать много fastcgi "max-procs" (потому что каждый процесс будет использовать свой собственный кеш, я полагаю), а вместо этого увеличивать дочерние элементы.
Чайлдс был увеличен с 20 (с 2 max-procs) до 32, без заметной разницы. Из того, что я понимаю, количество одновременно запускаемых скриптов - это max-procs * children. Просмотр вывода status.statistics-url, в то время как выполнение сценариев занимает много времени, не показывает, что все дети заняты.
Является ли правильный подход к продолжению роста детей от fastcgi, или что еще нужно сделать? Можно ли увидеть, какие сценарии находятся во время выполнения, как долго они выполняются и т. Д.
fastcgi.active-запросов: 39
fastcgi.backend.0.0.connected: 2259
fastcgi.backend.0.0.died: 0
fastcgi.backend.0.0.disabled: 0
fastcgi.backend.0.0.load: 19
fastcgi.backend.0.0.overloaded: 0
fastcgi.backend.0.1.connected: 4646
fastcgi.backend.0.1.died: 0
fastcgi.backend.0.1.disabled: 0
fastcgi.backend.0.1.load: 20
fastcgi.backend.0.1.overloaded: 0
fastcgi.backend.0.load: 39
fastcgi.requests: 6905
10-fastcgi.conf:
"max-procs" => 2,
"idle-timeout" => 20,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "32",
"PHP_FCGI_MAX_REQUESTS" => "500"
Журнал ошибок lighttpd, множество таких:
2011-05-30 09:45:48: (server.c.1258) ПРИМЕЧАНИЕ. Время запроса /index.php?//search/poll истекло после записи 15180 байт. Мы ждали 360 секунд. Если это проблема, увеличьте server.max-write-idle
2011-05-30 09:49:08: (server.c.1258) ПРИМЕЧАНИЕ: время запроса /index.php?// истекло после записи 12420 байт. Мы ждали 360 секунд. Если это проблема, увеличьте server.max-write-idle
3 ответа
У одного из поставщиков возникли проблемы с ответом на запросы, поэтому все поиски на сайте поставили в очередь множество потоков, ожидающих выполнения fastcgi. Похоже, что на стороне fastcgi нет реального исправления, а просто внедрите в коде правильное время ожидания и, возможно, определите, когда поставщики не отвечают, и перестаньте отправлять туда больше запросов.
Кроме того, я переключился на php-fpm и теперь постоянно отслеживаю "/status", чтобы рано обнаруживать подобные проблемы.
Измените ваш бинарный PHP на FPM вместо старых fastcgi.
FPM (FastCGI Process Manager) - это альтернативная реализация PHP FastCGI с некоторыми дополнительными функциями (в основном), полезными для сайтов с большой нагрузкой.
Работает намного стабильнее, у вас не должно быть проблем с тайм-аутом.
Как сказал vartec, PHP-FPM, вероятно, хорошая идея здесь. Обратите внимание, что версия PHP 5.2 не поддерживает создание динамических процессов (несмотря на то, что это настраиваемый параметр), поэтому вам нужно убедиться, что у вас достаточно рабочих для обработки всех ваших скачков трафика.
Если вы переключитесь на PHP-FPM, одним из преимуществ будет кэш кода операции, который будет использоваться всеми вашими PHP-процессами (чего можно добиться с помощью метода lighttpd, но это немного раздражает).
Какие запросы / сек вы видите? Я обычно пытаюсь запустить один процесс PHP для каждого запроса / сек, который видит сервер. Возможно, это не лучшая идея для системы с относительно небольшим объемом памяти, но я еще не сталкивался с какими-либо проблемами.
Используете ли вы Unix сокет или TCPIP для подключения lighttpd и php? Вы обязательно должны переключиться на сокеты Unix, если вы используете TCPIP. Я видел все виды периодических, трудно диагностировать проблемы при использовании TCPIP. Возможно, вы используете ограничения брандмауэра или соединения с TCPIP.
Вы контролируете что-то вроде Munin? Вероятно, вам было бы удобно иметь графики нагрузки трафика, нагрузки на сервер, загрузки mysql и т. Д. Хотя это не решит вашу проблему, просто имея их, они будут очень удобны для вас.