ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nginx + spawn-fcgi виснут php воркер ы



Лучше посмотрите strace'ом, на чем заблокировался php-worker и
попытайтесь устранить это вместе с php-программистами.

2 октября 2009 г. 13:35 пользователь nginx@xxxxxxxx <nginx@xxxxxxxx> написал:
> Согласен, что намудрено. Туда просто программистами была заложена какая-то
> идея по распределению серверов. В том месте, о котором написал в примере,
> всё-равно настою чтобы упростили, т.к. это жутко не рационально. Да и
> распределять в будущем будем скорее всего как-то по-другому. Но php виснет и
> где-то в других местах. Просто пока не удалось отследить где именно.
> Почему курл не знаю. Там насколько понял всего один параметр отдаётся. Оно
> даже с file_get_content() работает. Но и с ним тоже виснет. Мне кажется, что
> зависает из-за того что неправильно выстраивается очередь на обработчики.
> Т.е. 2.php назначается обработчику, на который передали 1.php . А очередь
> при этом обрабатывается каждым воркером в один поток. Может этим как-то
> можно управлять?
>
> Anton Bessonov пишет:
>>
>> Что-то как-то намудрённо... Почему курл, если скрипт находится локально?
>> Почему не натравить парзер?
>>
>> nginx@xxxxxxxx schrieb:
>>>
>>> Например. Есть скрипт 1.php , который прежде чем выдаст ответ,
>>> запрашивает инфу у 2.php (через curl)
>>> запущено 50 обработчика php
>>> Если обратится к 1.php в 51 и более паралельных запросов, все обработчики
>>> полностью виснут. После этого приходится убивать php при помощи
>>> killall -9 php-cgi
>>> иначе не убивается
>>> пока просто отделили под 2.php несколько обработчиков на другом порту
>>> хотя и сейчас местами наблюдаются подвисания, но обычно отвисает сам
>>> Проблема похоже в php. Может кто-нибудь уже решил её?
>>> Кстати пока разбирался с этим замерял производительность связки на
>>> тестовой машине (средний домашний двухядерник).
>>> eaccelerator включён
>>> Скрипт с обычным phpinfo(); обрабатывается примерно 430 раз в секунду
>>> Рабочие скрипты не больше 100 в секунду. Причём, касательно этих 100,
>>> такое ощущение, что где-то, что-то нужно "подкрутить", т.к. общая загрузка
>>> системы во время теста 65-70%
>>> Причём пробовал apache 1.3.x + mod_php и получил примерно такую же
>>> производительность php (ниже процентов на 10).
>>> Действительно что-то нужно донастроить, или это нормальные показатели для
>>> php?
>>>
>>>
>>>
>>
>>
>
>
>
>



-- 
С уважением, Борис Долгов.
icq 77556665
e-mail boris@xxxxxxxxxxx


 




Copyright © Lexa Software, 1996-2009.