01 Feb 07, Vladimir Dymikha writes to All:
VD> Первые две части сабжа очень плохо ведут себя вместе - при долгом
VD> использовании апача он норовит скушивать всю память, и почему-то
VD> игнорирует
VD> установки mpm вроде ServerLimit - запускает сколько хочет дочек.
VD> (используется mpm worker, php соответственно zts). server-status при этом
VD> полон висящими очень долгое время (больше часа точно) соединениями Sending
VD> Reply от клиентов, которые уже давно отвалились. При использовании php-cgi
VD> такого совершенно не наблюдается. Что это такое и как с этим быть?
Hе использовать. apache 1.3 и php 4.4 -- выбор старых пердунов
... АТС 73 защищает Ваши модемы от каppиеpа с утpа и до вечеpа...
VD> Первые две части сабжа очень плохо ведут себя вместе - при долгом
VD> использовании апача он норовит скушивать всю память, и почему-то
VD> игнорирует установки mpm вроде ServerLimit - запускает сколько
VD> хочет дочек. (используется mpm worker, php соответственно zts).
VD> server-status при этом полон висящими очень долгое время (больше
VD> часа точно) соединениями Sending Reply от клиентов, которые уже
VD> давно отвалились. При использовании php-cgi такого совершенно не
VD> наблюдается. Что это такое и как с этим быть?
выкидываешь апача нафиг, ставишь nginx+php как fastCGI.
Производительность растет, потребление памяти в разы падает.
--
Andrew E. Filonov
Persons disagreeing with your facts are always emotional
and employ faulty reasoning.
02 Feb 07, Andrew Filonov writes to Vladimir Dymikha:
VD>> Первые две части сабжа очень плохо ведут себя вместе - при долгом
VD>> использовании апача он норовит скушивать всю память, и почему-то
VD>> игнорирует установки mpm вроде ServerLimit - запускает сколько
VD>> хочет дочек. (используется mpm worker, php соответственно zts).
VD>> server-status при этом полон висящими очень долгое время (больше
VD>> часа точно) соединениями Sending Reply от клиентов, которые уже
VD>> давно отвалились. При использовании php-cgi такого совершенно не
VD>> наблюдается. Что это такое и как с этим быть?
AF> выкидываешь апача нафиг, ставишь nginx+php как fastCGI.
AF> Производительность растет, потребление памяти в разы падает.
А как при этом с http-auth?
... Даже маленькая практика стоит большой теории
AF> выкидываешь апача нафиг, ставишь nginx+php как fastCGI.
AF> Производительность растет, потребление памяти в разы падает.
SO> А как при этом с http-auth?
Нормально. Но про .htaccess придется конечно забыть.
--
Andrew E. Filonov
When more and more people are thrown out of work,
unemployment results.
02 фев 07 09:43, you wrote to Vladimir Dymikha:
AF> выкидываешь апача нафиг, ставишь nginx+php как fastCGI.
AF> Производительность растет, потребление памяти в разы падает.
Давно ищу замену сабжевому монстру. Можно подробней.
Ewgeny
AF>> выкидываешь апача нафиг, ставишь nginx+php как fastCGI.
AF>> Производительность растет, потребление памяти в разы падает.
EK> Давно ищу замену сабжевому монстру. Можно подробней.
Не так давно из интереса заводил связку php-fastcgi + ngix
впечатления сугубо положительные, до сих под
локальный phpmyadmin под ним живет :)
тонкостей заметил две:
1. ngix юзает директории
/var/tmp/nginx
/var/tmp/nginx/client_body_temp
/var/tmp/nginx/proxy_temp
/var/tmp/nginx/fastcgi_temp
они лежат в /var/tmp , а он указывает симлинком на /tmp который
очищается после каждой перезагрузки...
Пришлось скриптик написать, который запускался до ngix и создавал эти
директории, если их небыло (лишний раз попрактиковался в rc.subr scripting)
Знаю, это не правильно и не по стандартам (симлинк /var/tmp) , но так делает
много пользователей, и по хорошему нужно сделать патч к nginx.sh (перед
запуском проверка на наличие этих директорий и создание при необходимости) и
send-pr, но как-то не сложилось... Может кто займется? ;)
2. При нагрузочном тестировании с помошью ab от апача выяснилось что php
неадекватно себя ведет, если ему не выставить переменные
PHP_FCGI_MAX_REQUESTS, PHP_FCGI_CHILDREN (после обработки какого-то количества
запросов подвисает нах и перестает отвечать). Соответственно если пускать
например так:
echo "Run php4 fastcgi server on port 9000"
export PHP_FCGI_MAX_REQUESTS=500
export PHP_FCGI_CHILDREN=4
export FCGI_WEB_SERVER_ADDRS=127.0.0.1
/usr/local/bin/sudo -u www /usr/local/bin/php -b 127.0.0.1:9000 2>/dev/null
1>/dev/null &
то вроде нормально работает, после 500 запросов пересоздает дочку.
В общем удачи. Когда будет опыт продакшн использования этой связки, поделись
опытом, если не сложно :D
AI> Знаю, это не правильно и не по стандартам (симлинк /var/tmp) , но так
AI> делает много пользователей, и по хорошему нужно сделать патч к nginx.sh
AI> (перед запуском проверка на наличие этих директорий и создание при
AI> необходимости) и send-pr, но как-то не сложилось... Может кто займется?
AI> ;)
IMHO в стартовом скрипте этого быть не должно. Кто делает симлинк
/var/tmp -> /tmp и при этом чистит /tmp при перезагрузке (по умолчанию этого
не происходит) ССЗБ.
--
Anton Yuzhaninov, OSPF-RIPE, mail: citrin (at) citrin.ru
AI>> Знаю, это не правильно и не по стандартам (симлинк /var/tmp) , но так
AI>> делает много пользователей, и по хорошему нужно сделать патч к nginx.sh
AI>> (перед запуском проверка на наличие этих директорий и создание при
AI>> необходимости) и send-pr, но как-то не сложилось... Может кто займется?
AI>> ;)
AY> IMHO в стартовом скрипте этого быть не должно. Кто делает симлинк
AY> /var/tmp -> /tmp и при этом чистит /tmp при перезагрузке (по умолчанию
AY> этого не происходит) ССЗБ.
Да ладно, делов то на 5 минут.
Небольшая защита от дурака не повредит точно.
А некоторым новичкам может помочь, ибо это не совсем очевидно.
Хуже будет если это вылезет через некоторое время, после перезагрузки... Как
обычно в самый неудачный момент ;)
Крутецки конечно, только как использовать это на шаред-хостинге - непонятно.
Запустить для каждого юзера свой fastcgi-php сервер? Не жирно ли?
VD> From: "Vladimir Dymikha" <fly-...@icn.bmstu.ru>
>> echo "Run php4 fastcgi server on port 9000"
>> export PHP_FCGI_MAX_REQUESTS=500
>> export PHP_FCGI_CHILDREN=4
>> export FCGI_WEB_SERVER_ADDRS=127.0.0.1
>> /usr/local/bin/sudo -u www /usr/local/bin/php -b 127.0.0.1:9000
>> 2>/dev/null
>> 1>/dev/null &
VD> Крутецки конечно, только как использовать это на шаред-хостинге -
VD> непонятно.
VD> Запустить для каждого юзера свой fastcgi-php сервер? Hе жирно ли?
На более-менее большом хостинге один фиг от апача не уйдешь, ибо у многих
клиентов используются всякие apache специфичные приблуды (типа .htaccess)
По хорошему, с точки зрения безопасности для каждого из вирт.хостов и юзверей
необходима своя копия php-fastcgi, но при этом держать её постоянно в памяти
слегка не рационально (если у тебя клиенты с небольшим траффиком).
Оптимальным IMHO будет решение, при котором при первом вызове php скрипта на
определенном вирт.хосте должна стартовать копия php-fastcgi (есно от
правильного пользователя) и обрабатывать запрос. Потом висеть некоторое время
в памяти (на случай если еще запросы придут). Соответственно в случае
неактивности в течении некоторого времени она должна умирать, освобождая
ресурсы.
Кстати с точки зрения экономии ресурсов было бы еще интереснее решение, при
котором был бы один мастер процесс, от которого при необходимости форкались
дочки и делали switch-user на необходимого пользователя, после чего в случае
неактивности тихо умирали бы.
Как мне кажется, если поставить php в такую позу, жрать памяти это все станет
намного меньше.
Есть у всезнающего All идеи, как это можно реализовать в случае ngix?
On Sat, 3 Feb 2007 13:30:59 +0000 (UTC); Alex Ivanov wrote about 'ngix + php-fastcgi (Apache 2.2.4 && mod_php 5.2.0 && freebsd 6.1)':
AI> они лежат в /var/tmp , а он указывает симлинком на /tmp который
AI> очищается после каждой перезагрузки...
AI> Пришлось скриптик написать, который запускался до ngix и создавал эти
А всё потому, что ССЗБ. Можно же прочитать man hier, немного подумать,
и сделать вот так:
% df
/dev/ad0s1d 1519502 55294 1342648 4% /var/tmp
% ls -l /tmp
lrwxrwxrwx 1 root wheel 12 29 янв 2006 /tmp@ -> /var/tmp/tmp
% ls -lo /var/tmp
drwxrwxrwt 8 root wheel sunlnk 26112 4 фев 20:25 tmp/
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]