Проблема производительности: php-fcgi перестает обрабатывать запросы

[DProstoy]

Проблема производительности: php-fcgi перестает обрабатывать запросы

Уважаемые,

Есть проблема с производительностью сервера, с которой бьюсь уже несколько недель и никак не одолею по причине нехватки опыта и знаний. Очень рассчитываю на помощь и дельные советы экспертов.

Есть выделенный сервер. Конфигурация:
CentOS release 5 (Final)
DELL PE1950
2 x Quad Core Xeon L5320
4GB RAM
4x 73GB SAS (2xRAID1)

На сервере установлена связка: nginx + php-fcgi +mysql

В среднем сервер загружен процентов на 20-30%, однако периодически возникают кратковременные всплески в загрузке, что приводит к отказу в обслуживании.

Вот картинки мунина:

Админ говорит:

очень похоже, что дело не в узких местах. А непосредственно в php-fcgi. Он просто перестает обрабатывать запросы, все запросы. Пока не перезагрузишь его. Причина пока не понятна такого поведения.

"просто перестает" означает что процессы ничем не занимаются и при этом не обрабатывают новые запросы. Если подключится к любому процессу fast cgi в моменты проблем каким-либо трассировщиком системных вызовов это сразу видно.

mysql тут абсолютно не причем, мунин ,я более чем уверен, рисует Threads_connected, а то, что оно около 50, означает, что у вас нет нагрузки просто и максимально около 50 параллельных запросов обрабатывалось. У вас стоит max_connections 1024, соответственно столько тредов может быть порождено.

nginx и php-fcgi не работают вообще с тредами, есть мастер процесс и есть чайлд процессы.

Мы пробовали менять кол-во чайлдов для php-fcgi от адекватных до довольно сильно задранных, симптомы те-же.

Подскажите, в каком направлении копать? Готов предоставить дополнительную информацию по конфигурации и статистику при необходимости.

 

[Макс]

Если подключится к любому процессу fast cgi в моменты проблем каким-либо трассировщиком системных вызовов это сразу видно.

А что конкретно показывает трассировщик ? Ну то есть если выполнить например
strace -p <some_fcgi_pid>
что выводит ?

 

[Alexandre]

могу посоветовать написать в рассылку http://groups.google.com/group/highload-php-ru?lnk=srg

120 запросов в сек - это не оч большая нагрузка.

Может как -то можно воспроизвести ситуацию падения без MySQL?

 

[MiksIr]

Да, тут strace да gdb и думать, думать...
У меня как-то случались такие странные штуки с fpm когда я fork использовал. Так вроде ни о чем и не додумались, пришлось от fork отказаться.

 

[DProstoy]

Макс

# strace -p 25077
Process 25077 attached - interrupt to quit
как видите полный 0. Пробовалось несколько пидов.

MiksIr, у нас нет fork-а, насколько я понимаю.
worker_processes 6;
events {
worker_connections 4096;
use epoll;
}

Alexandre
За ссылку на рассылку - благодарю, попробую

Есть ли еще какие-то идеи?

-~{}~ 18.11.09 18:08:

И сразу вопрос: есть ли способ хотя бы примерно определить на какой строчке зависает php? или на какой сетевой операции и с какими параметрами?

 

[MiksIr]

Теоретически gdb может помочь. Только нужно php собрать --with-debug или что-то вроде этого.
Но спросите лучше в хайлоад-пхп, там более компетентные люди в плане ковыряния в системе, включая и человека, кто изначально fpm патч сделал.

 

[DProstoy]

Глупость, но не получается отправить - гугл говорит

К сожалению, мы не смогли отправить Ваше сообщение
Если Вы считаете, что это ошибка, обратитесь в службу поддержки Google.



-~{}~ 19.11.09 14:29:

Подскажите, какой PHP отладчик мог бы быть полезен для анализа где именно подвисание происходит?