PHP 7 валится в uninterruptible sleep

Активист

Активист
Команда форума
Пытаюсь перевести проект на PHP 7. В продакшине во время бейкапа, один два раза за за утро только PHP 7 переходит в состояние uninterruptible sleep (при этом на PHP 5 такой проблемы не замечено).

В этом случае

Если запускать как fcgi для apache видим максимальное число процессов в состоянии uninterruptible sleep (php-cgi процессы).

Как php-fpm без апача на nginx видим картину - масса процессов php-fpm (мастер процесс) в состоянии uninterruptible sleep , пулы тоже в этом же состоянии, пара процессов пулов в состоянии S или R (sleep/run), LA с двух поднимается до 50-60, процессы прибить невозможно.

в kern.log, syslog ничего нет, диски работают нормально. Сеть в порядке. PHP 5 такой херней не страдает. Переходить на PHP 5 желания нет. Может конфигурю как-нибудь

Сервак правда не ребутил 320 дней, сложно даже на 5 минут простоя


в php-fpm.log следующее
Код:
[19-Jan-2017 05:22:55] WARNING: [pool avtovokzal] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 48 total children
[19-Jan-2017 05:22:56] WARNING: [pool avtovokzal] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 49 total children
[19-Jan-2017 05:22:57] WARNING: [pool avtovokzal] server reached pm.max_children setting (50), consider raising it
[19-Jan-2017 05:24:22] NOTICE: Finishing ...
[19-Jan-2017 05:26:23] NOTICE: Terminating ...
[19-Jan-2017 05:26:24] NOTICE: Terminating ...
[19-Jan-2017 05:26:25] NOTICE: Terminating ...
[19-Jan-2017 05:26:27] NOTICE: Terminating ...
[19-Jan-2017 05:26:28] NOTICE: Terminating ...
[19-Jan-2017 05:27:40] NOTICE: exiting, bye-bye!
[19-Jan-2017 05:27:44] NOTICE: fpm is running, pid 13132
[19-Jan-2017 05:27:44] NOTICE: ready to handle connections
Debian Wheezy (7.11), собираю PHP 7 так:
Код:
read -p "Configure (y/n)?" REPLY
if [ $REPLY = "y" ]; then
    apt-get build-dep php5

    ./configure --prefix="$PREFIX"\
        --enable-cgi \
        --enable-static \
        \
        --enable-mbstring \
        --enable-soap \
        --enable-zip \
        --enable-calendar\
        --enable-sockets\
        --enable-bcmath\
        \
        --with-zlib\
        --with-openssl=/opt/openssl \
        --with-curl=/opt/curl \
        --with-gettext=shared \
        \
        --with-gd=shared \
        --enable-gd-native-ttf \
        --with-freetype-dir=/usr \
        \
        --with-mcrypt \
        --with-mysqli \
        --with-pdo-mysql \
        \
        --with-jpeg-dir=/usr \
        --with-png-dir=/usr \
        --with-config-file-path="$CFG" \
        --with-config-file-scan-dir="$CFG/conf.d" \
        --enable-fpm
        #--enable-debug
        #--with-pgsql
fi
 

confguru

ExAdmin
Команда форума
Надо смотреть чем заняты процессы - больше логирования...
 

Активист

Активист
Команда форума
Появилось свободное время. Проблему решил добавлением директивы events.mechanism = epoll (видимо автоматическое определение страдает). Третий день полетный нормальный.

Код:
[global]
pid = /run/php/php-7.0-fpm.pid
error_log = /var/log/php-7.0-fpm.log
events.mechanism = epoll
include=/opt/php-7.0-fpm.d/*.conf
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Немного unrelated, а кто-нибудь в продакшне юзает pm отличный от static?
 

AnrDaemon

Продвинутый новичок
Боюсь спросить, а почему не dynamic?
Хотя, подозреваю, отает будет "смотря какой продакшен".
 

Активист

Активист
Команда форума
Да и еще считай, те что IDLE - убиваются, тем самым меньше рисков что бы память утекла.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Боюсь спросить, а почему не dynamic?
Ну, форк свежего процесса — не очень мгновенная штука. При этом потолок максимальной нагрузки все равно задан. Почему сразу не иметь столько нужных готовых процессов? Я могу представить конечно, что можно динамик использовать, когда несколько пулов конкурируют за потребление.
А чем плох dynamic? ОЗУ использует по максимуму только в пиках. Сейчас у меня форкается не более 8-ми вокеров при нагрузках.
И кто у тебя эту ОЗУ, «освобожденную» потребляет?
 

fixxxer

К.О.
Партнер клуба
Немного unrelated, а кто-нибудь в продакшне юзает pm отличный от static?
Ну, я много где видел - просто потому что по умолчанию dynamic и никто не менял. Смысла в этом не вижу, тут скорее лень думать, сколько статиков поставить.

Вообще, насколько я помню историю вопроса, Андрей не хотел делать dynamic как-в-апаче ввиду его относительной бестолковости для задач, отличающихся от shared-хостинга, что-то там в итоге придумал, но руки никогда не доходили, потому что самим не надо было. Когда fpm отправился в свободное плавание, в итоге было сделано "как в апаче" как раз потому что этого хотели хостеры (да, есть такие, которые пользуются php-fpm).
 

fixxxer

К.О.
Партнер клуба
Да и еще считай, те что IDLE - убиваются, тем самым меньше рисков что бы память утекла.
Вообще, больше памяти утечет как раз там, где нагрузки больше. На этот случай есть pm.max_requests. Хотя я давно уже не видел, чтобы php тек.
 

AnrDaemon

Продвинутый новичок
форк свежего процесса — не очень мгновенная штука
Вполне возможно, сравнимая по времени с блокировкой по занятости воркеров.
Вот только блокировки будут повторяться, а заспавнившийся воркер продолжит принимать новые запросы.
 

Активист

Активист
Команда форума
Я из раздела админов "шаред хостинга", ибо да, мы его предоставляем сами на своем оборудовании и я все настраиваю. Так что видимо дело привычки. Вообще, каких-либо проблем с dynamic не видел.
 

Активист

Активист
Команда форума
Главное на серверах не допустить использование свопа чуть более чем пару раз, тогда все, считай LA под 50, и общее лавинное "гашение" сервера, да так что по SSH не подключиться, только ребут по IPMI.
 

Активист

Активист
Команда форума
Когда обнаружили багу в Apache (когда он чуть более чем совсем забирал память) при запросах типа "докачка", я наблюдал, что чисто боты ради забавы убивали напрочь сервера) тот еще троллинг сети был)))
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Когда обнаружили багу в Apache (когда он чуть более чем совсем забирал память) при запросах типа "докачка", я наблюдал, что чисто боты ради забавы убивали напрочь сервера) тот еще троллинг сети был)))
А нет ли такой проблемы в HTTP/2? Там же заголовки запросов сжимаются. Можно ли запендюрить на сервер аналог 42.zip?
 

fixxxer

К.О.
Партнер клуба
А нет ли такой проблемы в HTTP/2? Там же заголовки запросов сжимаются. Можно ли запендюрить на сервер аналог 42.zip?
gzip-бомбы, в отличие от zip, не такие уж прям бомбы (гигабайты из 10 байт не получится, придется несколько мегабайт залить). но вообще идея стара как мир
https://www.rapid7.com/db/modules/auxiliary/dos/http/gzip_bomb_dos

Но поскольку в серверах поточная распаковка, то скорее всего упрется в body size limit вовремя, еще не выжрав много (тут как раз спасают ограничения gzip).
 
Сверху