Постоянно падает php-fpm приходится делать рестарт

R
На сайте с 22.06.2007
Offline
174
#11
myhand:
Сотрудничайте с кем-то постоянно. Если нет желания приобретать профильные знания систематически - имеет смысл отдать кому-то сервера на постоянное администрирование.

К сожалению, учитывая мои доходы и цены на администрирование серверов, у меня нет возможности нанять администратора на постоянное администрирование...

Andreyka
На сайте с 19.02.2005
Offline
822
#12

Тогда стоит подумать об смене vps на vip хостинг

Не стоит плодить сущности без необходимости
R
На сайте с 22.06.2007
Offline
174
#13
Andreyka:
Тогда стоит подумать об смене vps на vip хостинг

У меня выделенный сервер.

M
На сайте с 16.09.2009
Offline
278
#14
Reise:
У меня выделенный сервер.

Тем хуже - за железками добрый дядинька не следит...

Абонементное сопровождение серверов (Debian) Отправить личное сообщение (), написать письмо ().
R
На сайте с 22.06.2007
Offline
174
#15
Reise:
Цитата:
Сообщение от Logger Посмотреть сообщение
pm заставьте слушать сокет а не tcp
Если ставлю в конфиге nginx:
Цитата:
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/tmp/php-fpm.sock;
то nginx для этого хоста выдает:
Цитата:
502 Bad Gateway
nginx/1.0.14
Logger:
тогда вам уже надо обращаться за платными услугами

Нет :), оказывается достаточно просто еще дописать одну строчку в конфиг php-fpm. Подсказали тут.


В файле /etc/php5/fpm/pool.d/www.conf
; listen = 127.0.0.1:9000
listen = /tmp/php-fpm.sock
M
На сайте с 10.08.2012
Offline
1
#16

В логе две разные ошибки:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

и

WARNING: [pool www] child 12043 exited on signal 11 (SIGSEGV) after 35.646667 seconds from start

Скорее всего ошибки, как то связанны.

Чтобы избавиться от первой ошибки, можно увеличить число процессов(pm.max_children) до 10-100. А также разобраться, почему увеличилась нагрузка(время обработки запроса и/или количество запросов).

По второй ошибки, советую обновить PHP и решить первую проблему. Если не поможет, то нужно разбираться почему PHP получает SIGSEGV.

Замена TCP соединений на сокет не поможет. Проблема не в накладных расходах TCP соединений, а в увеличении нагрузки(времени обработки запроса).

Unix администратор email: USERNAME@gmail.com
M
На сайте с 16.09.2009
Offline
278
#17
mloezk:
Скорее всего ошибки, как то связанны.

Какие-то аргументы в пользу этого вы способны привести? Ну, помимо "эти строчки есть в одном и том же лог-файле" :D

mloezk:
Чтобы избавиться от первой ошибки, можно увеличить число процессов(pm.max_children) до 10-100.

А че мелочиться - давай до 1000 сразу.

mloezk:
А также разобраться

О, а вот с этого действительно стоит начать!

M
На сайте с 10.08.2012
Offline
1
#18
myhand:
Какие-то аргументы в пользу этого вы способны привести? Ну, помимо "эти строчки есть в одном и том же лог-файле" :D

Да, могу привести аргументы. Например вызов какой-то функции стал медленным и поэтому стало не хватать количества процессов. SIGSEGV случается в этой же функции.

myhand:
А че мелочиться - давай до 1000 сразу.

Достаточно увеличить в 2-20 раз, нет смысла увеличивать в 200 раз количество процессов.

myhand:
О, а вот с этого действительно стоит начать!

Ссылка на инструкцию https://bugs.php.net/bugs-generating-backtrace.php

R
На сайте с 22.06.2007
Offline
174
#19

Проблему частично удалось локализировать, но как решить сабж не знаю.

Дело в том, что на сервере имеются медленные php-скрипты, которые долго выполняются, так как подтягивают данные извне посредством функции file_get_contents. Но это же не должно стать причиной того, что php падает. Как настроить php так чтобы медленные скрипты не влияли на работу php-fpm.

M
На сайте с 16.09.2009
Offline
278
#20
mloezk:
Да, могу привести аргументы. Например вызов какой-то функции стал медленным и поэтому стало не хватать количества процессов. SIGSEGV случается в этой же функции.

Самого "интересного" не рассказали - таки причем сегфолт к какой-то "медленности вызова функции"?

Тем паче, что "связь" настолько странная - что даже во времени никакой корреляции не видно. Или чукча просто не читатель?

mloezk:
Достаточно увеличить в 2-20 раз, нет смысла увеличивать в 200 раз количество процессов.

"Отсюда не видно", что имеет смысл увеличивать что-то даже и в два раза, не то что в 20. Забыли в подписи вывеску "лечим по фотографиям"?

mloezk:
Ссылка на инструкцию

Которая абсолютно никак не поможет ТС найти "тяжелые" скрипты.

Еще раз: баг в каком-то модуле php (пример возможной причины сегфолта) и наличие медленно работающих скриптов - связаны только вашей фантазией.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий