Больше 1800 одновременных коннектов, php-fpm уходит в несознанку

[Andrey Kozlov]

Доброго дня!

nginx+php-fpm на одном сервере.

четко при 1800 одновременных коннектов уходит в глубокую несознанку, и обрубает все по 11: Resource temporarily unavailable) while connecting to upstream

Сделал два php-fpm пула чтобы nginx распределял по ним нагрузку, коннекты через сокеты с php-fpm.

При dynamic всё мрёт еще на 300+ коннектов, при static с 1500 в каждом конфиге, доводится до 1800 и умирает.

Все что мог перечитал, как только конфиги не менял - вообще не могу понять куда копать, почему так происходит.

[No1]

sysctl крутили?

--

---
Вы получили это сообщение, поскольку подписаны на группу "highload-php-ru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес highload-php-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Tony Air]

можно попробовать ondemand о нём почему-то мало пишут, а sysctl, конечно, обязательно.

pm = ondemand

pm.max_children = 10

pm.process_idle_timeout = 10s

pm.max_requests = 500

-- 
Best regards, Tony Air
CEO, TWDA New Castle LLC

E-mail: to...@twma.pro
Skype: a2nt.fd
http://twma.pro

[Evgeny Petrenko]

ulimit -n посмотрите для юзера под которым крутится php-fpm

5 ноября 2014 г., 16:31 пользователь Tony Air <dark...@gmail.com> написал:

With best regards, Evgeniy Petrenko.

[Andrey Kozlov]

Все накручено.

ulimit -n

150000

В общем как впервые с таким столкнувшимся - скажите куда копать.

Беда в чем.

Сейчас допустим

Active connections: 3322 
server accepts handled requests
 207807 207807 251464 
Reading: 0 Writing: 3224 Waiting: 98 

При этом я добился работы в dynamic, но у меня сейчас на сервере на это вышло 2743 total children у php-fpm.

Т.е. получается что на каждый коннект рождается отдельный php-fpm процесс, их уже под 3000 в системе, естественно мы почти сожрали все 48 гиг озу и скоро сервер ляжет.

Как-то php-fpm-у можно объяснить чтобы одним процессом он обрабатывал несколько концертов?

Процессы находятся в статусе R - может в этом беда и надо пинать программеров? Тогда скажите куда их пинать.

Я просто читаю что люди по 10к держат а я упираюсь в 1 коннект - 1 процесс, а это 20 метров памяти и привет, дальше математика.

[Antony Dovgal]

Опкод-кэш какой-нить в FPM стоит?

-- 
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP

[No1]

strace,ptrace посмотрите.

[Andrey Uteshev]

а как быстро скрипты обрабатываются?

среднее время завершение? пики времени какие?

5 ноября 2014 г., 15:06 пользователь No1 <smile.ne...@gmail.com> написал:

--

Andrey Uteshev
+7(906)311-33-11
http://uteshev.ru

[Andrey Kozlov]

Он и стоит.

среда, 5 ноября 2014 г., 17:57:19 UTC+6 пользователь tony2001 написал:

[Andrey Kozlov]

Ну вот тут видимо и засада, я сейчас включил как тут посоветовали ondemand, поставил время выполнения 300 секунд максимум, и у меня по логам стало терминироваться куча чилдов php-fpm, со словами "убиваем после 2500 секунд работы скрипта, по таймауту".

Ну что-то раньше стало. 

Впечатление что где-то в скриптах у программеров цикл бесконечный, что ли, и оно по нарастающей просто все сжирает.

Буду трейсить дальше.

среда, 5 ноября 2014 г., 18:17:05 UTC+6 пользователь Andrey Uteshev написал:

[Andrey Uteshev]

Если у вас веб приложение то программист должен/обязан оптимизировать скрипты так что время их выполнения будет измеряться мили или единицами секунд. 

Сколько у вас запросов в секунду к phpfpm?

среда, 5 ноября 2014 г. пользователь Andrey Kozlov написал:

--

---
Вы получили это сообщение, поскольку подписаны на группу "highload-php-ru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес highload-php-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
АУ
+7(906)311-33-11

[Andrey Uteshev]

через strace -p PIDofPHPFPM

можно подключиться к процессу fpm и посмотреть что внутри происходит.

5 ноября 2014 г., 18:37 пользователь Andrey Uteshev <ves...@gmail.com> написал:

[Andrey Kozlov]

В настоящий момент порядка 26 тысяч...

Что-то мне кажется программер был не прав выбрав php для этого решения.

среда, 5 ноября 2014 г., 21:37:23 UTC+6 пользователь Andrey Uteshev написал:

[Antony Dovgal]

On 11/05/2014 09:45 PM, Andrey Kozlov wrote:
> В настоящий момент порядка 26 тысяч...
> Что-то мне кажется программер был не прав выбрав php для этого решения.

К одному серверу? 26 тыщ запросов в секунду?
Меня гложут смутные сомнения.

[No1]

С кешированием вы бы справились,оно есть?

В мемкеш сгенерированые страницы складывать например,множество вариантов. Для поиска: кеширование динамического контента.

--

--- Вы получили это сообщение, поскольку подписаны на группу highload-php-ru.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес highload-php-ru+unsubscribe@googlegroups.com.

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Andrey Kozlov]

До 35 тысяч в пике было.

Всё, со всем что есть разобрался, спасибо за мысли и наводки.

Через strace смотрел что же там происходит с php-fpm, появились догадки.

Заставил программиста вместо "промышленного фреймворка" написать тупейший скрипт без классов и прочего - и всё заработало.

Был load average 2900, стал 2-4 в пике.

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

Это заставил переделать на выдачу обычного текстового файла средствами nginx, с указанием опять же nginx-ом нужного Content Type. Даже когда был load average 2900 - этот момент стал как из пулемета отстреливать.

Ну и второй коннект от клиентов, на получение токена авторизации - был переделан в тупой скрипт, и не смотря на все вычисления и обновления БД перед выдачей токена авторизации, все залетало.

А вот "промышленный фреймворк", благодаря strace (спасибо еще раз), был пойман на бесконечном цикле...

И получалось что вместо двух отстрелов моментальных на каждый коннект - коннект подвисал, php что-то там у себя в циклах умное крутил, и процесс в R постоянно находился. И таким образом всё пухло.

Вчера на тех же 35к запросах php-fpm обрабатывал всё это в режиме dynamic используя всего 50, максимум 60 чайлдов.

Всем спасибо :) Программист закопан глубоко в лесу )

четверг, 6 ноября 2014 г., 15:05:17 UTC+6 пользователь tony2001 написал:

[Alex Filatov]

вопрос не совсем по теме - а можно имя промышленного фреймворка в студию? =)

заранее благодарю.

Best regards,
Alex

[Andrey Kozlov]

Второй симфони с доктрайном.

Но я думаю это косяк программера, он кастомизировал авторизацию и вот видимо "что-то пошло не так".

Потому как - дальше то клиенты если по сайту ходят - там все на нём же и отлетает вообще не замечая нагрузки. Но там уже заходят с готовой авторизационной сессией и ни каких проблем не возникло ни разу.

пятница, 7 ноября 2014 г., 11:12:07 UTC+6 пользователь Alex Filatov написал:

[No1]

Также отказался однажды от симфони с доктриной,оверхед по вычислениям хеша дикий какой-то был.

[Antony Dovgal]

Браво!

--

---
Вы получили это сообщение, поскольку подписаны на группу "highload-php-ru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес highload-php-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.