php-fpm + nginx. 502 Gateway timeout
Alexey Kalinnikov
"
> В свое время перешел на пхп-фпм и в принципе очень доволен, но 502 все
> равно иногда проскакивает(хотя намного реже чем при обычном решении).
> Сам очень давно бьюсь но так ничего и не смог сделать.
Надо смотреть что в php-fpm.log в момент появления 502. Пишите в
highload-php-ru, попробуем помочь.
"
Конфигурация
Gentoo.
php-5.2.4 + fpm 0.5.3
nginx 0.5.34
Машина ксеон с квадро процессором и сас винтами.
Как уже написал выше проскакивают 502 ошибки нгинкса причем происходит
это "пачками". Т.е. скажем в течении 3-10 секунд все запросы получают
гейтвей таймауты.
Общение Нгинкса с пхп-фпм через сокеты (tcp пробовал какртина такая
же)
При этом в логе php-fpm девственно чисто. В логе пхп естественно тоже.
В логах нгинкса следующее
2008/05/03 13:40:23 [error] 2708#0: *11340879 writev() failed (107:
Transport endpoint is not connected) while sending request to
upstream, client: .....
2008/05/03 13:40:24 [error] 2708#0: *11343058 writev() failed (107:
Transport endpoint is not connected) while sending request to
upstream, client: .....
2008/05/03 13:40:24 [error] 2709#0: *11349538 writev() failed (107:
Transport endpoint is not connected) while sending request to
upstream, client: ......
Есть у кого нить идеи?
Andrei Nigmatulin
> В рассылке nginx'a произошел следующий диалог
>
> > В свое время перешел на пхп-фпм и в принципе очень доволен, но 502 все
> > равно иногда проскакивает(хотя намного реже чем при обычном решении).
> > Сам очень давно бьюсь но так ничего и не смог сделать.
>
> Надо смотреть что в php-fpm.log в момент появления 502. Пишите в
> highload-php-ru, попробуем помочь.
Есть смысл обновиться до последней версии php и php-fpm, там много всего
пофиксено.
> "
>
> Конфигурация
> Gentoo.
> php-5.2.4 + fpm 0.5.3
> nginx 0.5.34
>
> Машина ксеон с квадро процессором и сас винтами.
>
> Как уже написал выше проскакивают 502 ошибки нгинкса причем происходит
> это "пачками". Т.е. скажем в течении 3-10 секунд все запросы получают
> гейтвей таймауты.
> Общение Нгинкса с пхп-фпм через сокеты (tcp пробовал какртина такая
> же)
> При этом в логе php-fpm девственно чисто. В логе пхп естественно тоже.
> В логах нгинкса следующее
>
> 2008/05/03 13:40:23 [error] 2708#0: *11340879 writev() failed (107:
> Transport endpoint is not connected) while sending request to
> upstream, client: .....
> 2008/05/03 13:40:24 [error] 2708#0: *11343058 writev() failed (107:
> Transport endpoint is not connected) while sending request to
> upstream, client: .....
> 2008/05/03 13:40:24 [error] 2709#0: *11349538 writev() failed (107:
> Transport endpoint is not connected) while sending request to
> upstream, client: ......
>
>
> Есть у кого нить идеи?
http://groups.google.com/group/highload-php-ru/msg/a5a2883173f56f5d
--
Andrei Nigmatulin
GPG PUB KEY 6449830D
Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take
Itreek
либо если нет желания :-) "vmstat -z | grep tcp" скорее всего сокетов
не хватает...
ИМХО Было нечто похожее, из-за клиентсокго скрипта - выходил в
бесконечный цикл, из-за того что nginx не передавал нужный заголовок
-)
Andrei Nigmatulin
> On Saturday 03 May 2008 14:15, Alexey Kalinnikov wrote:
> > В рассылке nginx'a произошел следующий диалог
> >
> > > В свое время перешел на пхп-фпм и в принципе очень доволен, но 502 все
> > > равно иногда проскакивает(хотя намного реже чем при обычном решении).
> > > Сам очень давно бьюсь но так ничего и не смог сделать.
> >
> > Надо смотреть что в php-fpm.log в момент появления 502. Пишите в
> > highload-php-ru, попробуем помочь.
>
Собственно, пробуйте увеличить /proc/sys/net/core/somaxconn, должно стать
лучше.
Если записи такого типа "writev() failed (107: Transport endpoint is not
connected)" все равно останутся - значит зависания скриптов у вас происходят
систематически. Надо будет подсмотреть чем они занимаются в момент проявления
проблемы.
Alexey Kalinnikov
Уже двое суток полет нормальный.
И кстати, вот этот совет
либо если нет желания :-) "vmstat -z | grep tcp" скорее всего сокетов
не хватает... "
линуксом?
Andrei Nigmatulin
> Всем спасибо, действительно помогло увеличение somaxconn и ulimit.
>
> Уже двое суток полет нормальный.
>
> И кстати, вот этот совет
> "Попробуйте переделать с сокетов на порт и смотреть "netstat -Lan",
Насколько я понимаю, этой командой во freebsd, в том числе, смотрится размер
backlog. В линуксе прямого аналога нет, но кол-во соединений в backlog можно
посчитать сделав netstat -ntp. Все соединения в состоянии ESTABLISHED, но еще
не ассоциированные с процессом - это backlog (для которых еще не сделали
accept).
unix или inet - разницы нет на этом уровне.
> либо если нет желания :-) "vmstat -z | grep tcp" скорее всего сокетов
> не хватает... "
> отличный но он явно для фряхи, а нет ли аналогов для этого под
> линуксом?
--
Nafania
endpoint is not connected однако изменить /proc/sys/net/core/somaxconn
не имею возможности, ибо VPS (стоит значение 128).
nginx/0.7.1 + php 5.0.4 (with eAccelerator v0.9.5.2) в режиме fcgi,
пускается через spawn-php.
Есть ли еще какой-нибудь способ решения?
Andrei Nigmatulin
1) Всеми правдами и неправдами ускорять исполнение php скриптов и запросов к
базе данных - профайлинг, тюнинг, кэширование и т.д. В итоге php воркеры
будут обрабатывать запросы быстрее и вероятность переполнения очереди
уменьшится.
2) Увеличить мощность сервера, добавить процессоров, памяти и т.п. Результат
должен быть как в п. 1
Nafania
работаю :)
Однако я думал, может есть какие-другие причины возникновения этой
ошибки? Может быть неверная настройка или прочее.
Вообщем-то, занимаясь первым пунктом я обнаружил, что пхп воркеры
довольно шустро делают свое - в среднем отрабатывают запрос за
секунду, а то и меньше (время вообщем-то высокое, но в данном случае
приемлимое), однако вот upstream_response_time ненормально высок и
колеблется в значениях от 15 до 60(!) секунд в самые тяжкие времена.
On 20 июн, 00:22, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:
Andrei Nigmatulin
> Хех, это логично, до этого я сам дошел и над первым пунктом усердно
> работаю :)
> Однако я думал, может есть какие-другие причины возникновения этой
> ошибки? Может быть неверная настройка или прочее.
> Вообщем-то, занимаясь первым пунктом я обнаружил, что пхп воркеры
> довольно шустро делают свое - в среднем отрабатывают запрос за
> секунду, а то и меньше (время вообщем-то высокое, но в данном случае
> приемлимое), однако вот upstream_response_time ненормально высок и
> колеблется в значениях от 15 до 60(!) секунд в самые тяжкие времена.
На самом деле, секунда - это очень много. Или у вас система плотно перегружена
запросами и работает на пределе (смотреть top, vmstat, iostat и т.п.) или
имеют место массовые ожидания общих ресурсов, типа file locks, databases и
т.п. Отсюда и высокая вероятность большого времени исполнения запроса,
неважно, в accept queue он или уже исполняется. Это все теория массового
обслуживания.
Я планирую в будущем добавить в php-fpm средства визуализации "занятости"
воркеров, чтобы было примерно понятно куда копать.
Gorynych
> > > равно иногда проскакивает(хотя намного реже чем при обычном решении).
> > > Сам очень давно бьюсь но так ничего и не смог сделать.
>
> > Надо смотреть что в php-fpm.log в момент появления 502. Пишите в
> > highload-php-ru, попробуем помочь.
ситуация: нагрузка сервера для стресс-тестирования
ловится 502 от nginx'а
в логе php-fpm.log чисто, до того момента как принудительно шлю
SIGUSR2
вот тут в логе появляются множественные записи о том, что
fpm_stdio_child_said() ...бла-бла-бла... EACCELERATOR hit: "<имя
файла>"
затем идут записи о закрытие pipe'ов, уведомление о перезагрузке , тут
ловим fpm_unix_init_main(), line 271: getrlimit(nofile): max:1024, cur:
1024 и далее вполне нормально перестартовываем воркеры.
к моменту подвисания и 502 ошибки для php-fpm процессов имеем:
PID PPID USER %CPU %MEM STARTED VSZ WCHAN COMMAND
...
5780 5779 ХХХ 0.1 1.6 12:59:54 468880 pipe_w /usr/php/bin/php-cgi --
fpm
...
и в этом состоянии + отсутствие записей в php-fpm.log пребываем до
принудительного перезагруза через SIGUSR2
Конфигурация:
-------------
ОС: CentOS 5.1
nginx 0.6.31
php 5.2.6
php-fpm 0.5.8
акселератор: eAccelerator v0.9.5.2
php-fpm работает через unix-сокеты. Акселератор сменен с xcache на
eAccelerator по причине того, что последний ведет себя более устойчиво
(на xcache наблюдается косяк как минимум при групповом обновлении
опкода).
как это отзывается по логу nginx'а:
01/Jul/2008:13:16:01 +0400 192.168.0.144 0.024 - 200 174834 GET
http://host:8080/
01/Jul/2008:13:16:01 +0400 192.168.0.144 0.020 - 200 174834 GET
http://host:8080/
01/Jul/2008:13:16:01 +0400 192.168.0.144 0.021 - 200 174834 GET
http://host:8080/
01/Jul/2008:13:16:01 +0400 192.168.0.144 0.020 - 200 174834 GET
http://host:8080/
01/Jul/2008:13:16:01 +0400 192.168.0.144 0.023 - 200 174834 GET
http://host:8080/
01/Jul/2008:13:16:02 +0400 192.168.0.144 0.021 - 200 174834 GET
http://host:8080/
- состояние до 502. В среднем у меня запрос при использовании
eAccelerator'а обрабатывается 0,020 - 0,047 (на xcache было быстрее -
0,011/0,014 но не стабильно).
А вот теперь пошел срыв на 502:
01/Jul/2008:13:16:32 +0400 192.168.0.144 - - 499 0 GET http://host:8080/
01/Jul/2008:13:16:32 +0400 192.168.0.144 - - 499 0 GET http://host:8080/
01/Jul/2008:13:16:32 +0400 192.168.0.144 - - 499 0 GET http://host:8080/
образно говоря, хочется придумать нечто, что позволит получить эту
перезагрузку php-fpm в состоянии "висим, курим" без ручного посыла
SIGUSR2. Куда можно двинуться?
nagual
Рекомендую сделать:
_________________________________________________________
#!/bin/sh
DISKSIZE="64m"
case "$1" in
start)
/bin/echo -n "Starting memdisk "
/sbin/mdconfig -a -t malloc -s $DISKSIZE
/bin/mkdir -p /mnt/md0
/sbin/newfs /dev/md0
/sbin/mount /dev/md0 /mnt/md0
/bin/chmod 777 /mnt/md0
;;
stop)
/bin/echo -n "Shutting memdisk "
/sbin/umount -f /mnt/md0
/sbin/mdconfig -d -u md0
/bin/rm -R /mnt/md0
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac
________________________________________________
После чего перенести юниксокеты в /mnt/md0
В результате 502 станут редкостью ...
Кроме того я перенес в /mnt/md0 все временные и все что упоминалось в
nginx.conf и php.ini
Попутно вопрос
http://www.lexa.ru/nginx-ru/msg18952.html
Andrei Nigmatulin
Я конечно не эксперт во FreeBSD, но при использовании unix sockets впринципе
не может быть никаких обращений к носителю, на котором он располагается.
Соответственно, мне лично совершенно непонятен этот совет - перенести сокет на
memdisk.
> Попутно вопрос
> http://www.lexa.ru/nginx-ru/msg18952.html
Для отслеживания и устранения таких ситуаций в 0.5.9-rc2 появились новые
директивы - request_slowlog_timeout и request_terminate_timeout.
Подробнее - здесь:
http://groups.google.com/group/highload-php-ru/browse_thread/thread/901402a29ec7ba1a
Alexey V. Karagodov
nagual
eaccelerator.cache_dir="/mnt/md0"
Тоесть вся работа в памяти ... и при 1м трафа у меня в среднем 3-5% по
gstat ...
On 11 авг, 14:27, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:
nagual
Aug 21 01:02:15.505937 [WARNING] fpm_stdio_child_said(), line 192:
child 26006 (pool default) said into stderr: "[26006] EACCELERATOR: PH
P crashed on opline 1014 of (null)() at /usr/home/person5/phpmyadmin/
libraries/common.lib.php:3169"
Aug 21 01:02:15.506513 [WARNING] fpm_stdio_child_said(), line 192:
child 26006 (pool default) said into stderr: "", pipe is closed
Aug 21 01:02:15.506548 [NOTICE] fpm_got_signal(), line 73: received
SIGCHLD
Aug 21 01:02:15.506592 [WARNING] fpm_children_bury(), line 229: child
26006 (pool default) exited on signal 11 SIGSEGV after 268.699931 s
econds
Как это исправить ?
Antony Dovgal
отключить EAccelerator?
--
Wbr,
Antony Dovgal
nagual
Да и проблема скорее всего не в EAccelerator.
Ошибки возникают редко и как то связаны с сешенкуками.
Antony Dovgal
> Очень нехочется это делать.
> Да и проблема скорее всего не в EAccelerator.
Я бы сказал, проблема скорее всего именно в нём.
> Ошибки возникают редко и как то связаны с сешенкуками.
reproduce case?
--
Wbr,
Antony Dovgal
-= HaRius =-
В такой связке наблюдал обвал пхп каждую минуту.
Заменил еакселератор на xcache.
nagual
________________________________________________
cd /usr/work/src2/eaccelerator
/usr/local/bin/phpize -clean
/usr/local/bin/phpize
#./configure
#make
CC="gcc" \
OPTIM="-O3 -pipe -fno-exceptions -funroll-loops -ffast-math -funroll-
loops -march=athlon64 -msse3" \
CFLAGS="-O2 -pipe" \
INCLUDES="-I/usr/local/include" \
./configure \
--enable-eaccelerator=shared
__________________________________________________
cd /usr/work/src2/php
make -s clean
CC="gcc" \
OPTIM="-O3 -pipe -fno-exceptions -funroll-loops -ffast-math -funroll-
loops -march=core2 -msse3" \
CFLAGS="-O2 -pipe" \
INCLUDES="-I/usr/local/include" \
./configure \
--enable-fastcgi \
--enable-force-cgi-redirect \
--enable-discard-path \
--with-mysql=/usr/local \
--without-xmlrpc \
--without-ming \
--with-zlib \
--enable-inline-optimization \
--enable-exif \
--enable-static \
--enable-bcmath \
--with-gnu-ld \
--enable-zend-multibyte \
--enable-mbstring \
--with-mcrypt=/usr/local/lib \
--enable-fpm \
--disable-ipv6 \
--with-gd \
--with-jpeg-dir=/usr/local \
--with-freetype-dir=/usr/local \
--with-curl=/usr/local \
--with-openssl=/usr \
--enable-session \
--enable-sockets \
--disable-debug
______________________________________________________
[Zend]
;extension_dir="/usr/local/lib/php/extensions/no-debug-non-
zts-20060613"
;zend_
;extension="eloader.so"
;extension="/usr/local/lib/php/extensions/no-debug-non-zts-20060613/
eloader.so"
zend_extension="/usr/local/lib/php/extensions/no-debug-non-
zts-20060613/eaccelerator.so"
eaccelerator.shm_size="40"
;Размер кэша совместно используемой памяти, устанавливается в
мегабайтах.
eaccelerator.cache_dir="/mnt/md0"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
;eaccelerator.shm_ttl="100"
;Указывает в секундах время, по истечении которого давно не
используемый код должен быть удален из совместно используемой памяти
;при превышении объема выделяемой памяти. По умолчанию эта опция
отключена, мы рекомендуем устанавливать значение от 60 до 300
;при большом количестве файлов и от 900 до 1800 при малом количестве
файлов.
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
[Zend]
zend_optimizer.optimization_level=15
zend_extension_manager.optimizer="/usr/local/lib/php/20060613/
Optimizer"
zend_extension_manager.optimizer_ts="/usr/local/lib/php/20060613/
Optimizer_TS"
zend_extension="/usr/local/lib/php/20060613/ZendExtensionManager.so"
zend_extension_ts="/usr/local/lib/php/20060613/
ZendExtensionManager_TS.so"