Запуск системы debian с lighttpd, php5, xcache и fastcgi. 2 ГБ оперативной памяти, 2 ядра, загрузка процессора менее 10% за 5 минут, среднее пиковое время, менее 1 ГБ оперативной памяти.
Система запускает пользовательское веб-приложение сборки, которое очищает сайты поиска рейсов, кеширование (результатов) не допускается, поэтому оно выполняется в реальном времени, а код, который это делает, использует libcurl и, вероятно, может выполняться в течение нескольких секунд для каждого поиска. Также есть рекламная система OpenX.
В последнее время сайт, кажется, периодически истекает таймаутом, и я создал простой тестовый сценарий, который просто печатает слово, чтобы убедиться, что оно не связано с базой данных MySQL.
Насколько я понимаю, когда мы запускаем кешер кодов операций, мы не должны запускать много fastcgi «max-procs» (потому что каждый процесс будет использовать свой собственный кеш, как я полагаю), а вместо этого увеличивать дочерние элементы.
Число детей было увеличено с 20 (с 2 макс-процессами) до 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. перегружено: 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
Как сказал vartec, PHP-FPM, вероятно, здесь хорошая идея. Обратите внимание, что версия PHP 5.2 не поддерживает динамическое порождение процессов (несмотря на то, что это настраиваемая опция), поэтому вы должны убедиться, что у вас достаточно рабочих, чтобы справиться со всеми всплесками трафика.
Если вы переключитесь на PHP-FPM, одним из преимуществ будет то, что кеш-код операции будет использоваться всеми вашими PHP-процессами (чего можно достичь с помощью метода lighttpd, но это немного раздражает).
Какие запросы в секунду вы видите? Обычно я пытаюсь запускать один процесс PHP для каждого запроса в секунду, который видит сервер. Возможно, это не лучшая идея для системы с относительно низким объемом памяти, но я еще не столкнулся с какими-либо проблемами.
Используете ли вы сокет unix или TCPIP для подключения lighttpd и php? Вам обязательно следует переключиться на сокеты unix, если вы используете TCPIP. Я видел всякие непостоянные, трудно диагностируемые проблемы при использовании TCPIP. Возможно, вы достигли пределов брандмауэра или соединений с TCPIP.
Вы контролируете что-нибудь вроде Мунина? Возможно, вам будет удобно иметь графики загрузки трафика, загрузки сервера, загрузки MySQL и т. Д. Хотя это не решит вашу проблему, просто имея их, они будут вам очень удобны.
Измените двоичный файл PHP на FPM вместо старого fastcgi.
FPM (FastCGI Process Manager) - это альтернативная реализация PHP FastCGI с некоторыми дополнительными функциями (в основном), полезными для сильно загруженных сайтов.
Работает намного стабильнее, проблем с таймаутом быть не должно.
У одного из поставщиков возникли проблемы с ответом на запросы, поэтому все поиски на сайте ставили в очередь множество потоков, ожидающих выполнения fastcgi. Кажется, что на стороне fastcgi нет реального исправления, а лучше реализовать правильный тайм-аут в коде и, возможно, определить, когда поставщики не отвечают, и прекратить отправлять туда больше запросов.
Кроме того, я переключился на php-fpm и теперь постоянно отслеживаю "/ status" для раннего обнаружения подобных проблем.