Reise

Рейтинг
174
Регистрация
22.06.2007
michaek:
что значит не помогает?

Значит, что не решило проблему. Ресурсы, занятые кривыми скриптами не освобождаются, php и дальше вешается.

michaek:
сделать, так же как и первый

не очень силен в этом вопросе, придется видимо гуглить.

michaek:
или еще вариант, в конфиге есть директива request_terminate_timeout, можно посмотреть ее

не помогает

load average: 13.48, 8.73, 4.73

---------- Добавлено 12.08.2012 в 22:20 ----------

michaek:
что мешает медленные запросы загнать в отдельный пул? тогда они к остальным отношения иметь не будут

неплохо было бы, еще бы знать как это сделать.

Уже почти что решил проблему, но все равно чего-то не хватает, не могу разобраться чего.

И так еще раз: на сервере появились скрипты, которые выполняются слишком долго, так как при выполнении подтягивают данные извне из интернета. Это вешает php-fpm.

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

Варианты решения:

1. Переписать криво написанный скрипт, чтобы он умел грамотно пользоваться ресурсами. Кстати при определенных обстоятельствах скрипт может вообще не подтянуть данные, за которыми он обращается, и как я понимаю это исключение в нем не обрабатывается. Зависит не от меня, так как писал не я и как поправить не знаю.

2. Обрезать выполнение таких медленных скриптов по таймауту и освобождать ресурсы

По понятным причинам второй вариант является правильным.

Что я нашел.

В php.ini:

max_execution_time поставил 10 сек. По умолчанию там 30.

В конфигурациях nginx хостов, на которых медленные скрипты подправил параметр fastcgi_read_timeout

#fastcgi_read_timeout 180;
fastcgi_read_timeout 10;

Но как не странно не совсем помогло. С одной стороны если вручную проверять проблемные сайты с медленным скриптами, то на страницах если долго не отдается контент выдается 504, что правильно - срабатывает таймаут nginx на получения данных от php-fpm, но с другой стороны по load average и дальше творится ужас вплоть до 8ки php все равно вешается. То есть очевидно со стороны вебсервер ответ от php не ожидается, но скрипт продолжает выполнятся php-сервером, что вешает его.

Что я еще не учел? Ну вот уже проблема разжевана буквально по косточкам. Ау, админы, кто подскажет как обрывать нежелательные медленные php-процессы, освобождая ресурсы.

Лучше бы вместо того, чтобы выяснять кто круче админ :), помогли бы разобраться в проблеме и заодно доказали бы это на деле.

myhand:
Разница невелика, если скрипты не по секунде отрабатывают

Есть там у меня скрипты, которые отрабатывает не то что по сек, а по секунд 30. Причины этого описал выше, убрать их нельзя, оптимизировать тоже, но еще раз повторяю, даже мой дилетантский взгляд говорит о том, что это не должно стать причиной падения php. Соответственно возникает вопрос, что подкрутить в конфигах. Увеличивать max_children - не вариант, попробовал поставить 50, так у меня вообще нагрузка по load average к 4ке подскочила.

Andreyka:
В нормальном дистре пчих не падает с сегфолтом.

У меня debian - он по вашему ненормальный? Еще раз повторяю - все стабильно работало и летало очень долго - точно больше чем полгода, пока на сервере не появились медленные скрипты - вот корень проблемы.

mloezk:
5 процессов это не более 5 пользователей включая внутренний запросы. Обычный дефолт для средних серверов 100-150.

НУ я не слишком большой специалист, но позволю себе с вами не согласится. Один чилдрен может обслуживать не 1 процесс, а много, сколько именно зависит от других параметров. Если бы это было только 5, то никак такое значение по дефолту в настройках не могло бы даже быть.

---------- Добавлено 11.08.2012 в 17:44 ----------

mloezk:
Это не моя фантазия, читай ответ автора темы.

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

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

Так я знаю где эти медленные скрипты, они медленные из-за того, что в них идет вызов функции file_get_contents, которая подтягивает контент из выдачи поисковиков интернета. Соотвественно такой скрипт выполняется как минимум несколько секунд в лучшем случае.

Но что с того, если мне эти скрипты нужны, ускорить их по понятной причине и не получится...

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

Проблема как раз в наличии медленно работающих скриптов. Баг начал проявляться после того, как та система с медленными скриптами была добавлена на сервер.

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

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

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
Andreyka:
Тогда стоит подумать об смене vps на vip хостинг

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

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

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

Всего: 1587