[error] 344#0: *13900 writev() failed (107: Transport endpoint is not connected) while sending request to upstream

[Rauan Maemirov]

Для эксперимента потестировал сайт под ab. При 300 конкурентных
запросах он начал выливать эту самую строчку. Однако сайт через раз
все же открывается, а через раз 502.

nginx: процесса 4, коннекшнов 6144.
php-fpm: max_children: 40, max_requests: 500.

Корок нету :) (rlimit_core unlimited я ставил).

Как только бенчмарк закончился, сайт начал стабильно работать.

Означает ли это, что он просто игнорирует избыточные запросы?

[Rauan Maemirov]

P.S. Забыл сказать, что php 5.2.6, php-fpm 0.5.8, nginx 0.6.30.

[Alex Vorona]

Rauan Maemirov пишет:

какой backlog у php-fpm? Похоже, что nginx принимает запросы, передаёт
их на php-fpm, но у того уже переполнена очеред сокета(backlog) и nginx
отдаёт 502.
Попробуйте поднять backlog до 1024.

если ОС FreeBSD и nginx с php-fpm общаются через tcp, то размер и
заполнение backlog можно наблюдать по netstat -Lan

[Rauan Maemirov]

backlog до этого стоял дефолтный (-1). Поставил 1024. Ничего не
изменилось. Все то же самое. И даже логи php-fpm "пустые":

May 05 00:26:21.640594 [NOTICE] fpm_unix_init_main(), line 271:
getrlimit(nofile): max:10240, cur:10240
May 05 00:26:21.641158 [NOTICE] fpm_event_init_main(), line 109:
libevent: using epoll
May 05 00:26:21.641229 [NOTICE] fpm_init(), line 47: fpm is running,
pid 2796

Потом 40 штук:
May 05 00:26:21.642351 [NOTICE] fpm_children_make(), line 305: child
2797 (pool default) started

и

May 05 00:26:21.682023 [NOTICE] fpm_event_loop(), line 124: libevent:
entering main loop

В логах нгинкса та же байда что и в subject.
А общаются они по сокету на Linux.

P.S: Кстати, что означает backlog?

[Alex Vorona]

Rauan Maemirov пишет:

> backlog до этого стоял дефолтный (-1). Поставил 1024. Ничего не
> изменилось. Все то же самое. И даже логи php-fpm "пустые":
>
>

сделайте
echo 1024 > /proc/sys/net/core/somaxconn
и перезапустите php-fpm

[Rauan Maemirov]

Ураааа. Теперь вообще не вылазят ошибки. И даже при 500
конкурентных... Ну разве что время отклика увеличилось.

Так что же означает backlog и /proc/sys/net/core/somaxconn ?

[Alex Vorona]

Rauan Maemirov пишет:

> Ураааа. Теперь вообще не вылазят ошибки. И даже при 500
> конкурентных... Ну разве что время отклика увеличилось.
>
>

Андрей, может стОит сделать проверку в php-fpm и на превышение
системного лимита варнинговать в лог?

> Так что же означает backlog и /proc/sys/net/core/somaxconn ?
>

максимальное количество соединений на один listen сокет, которое
принимает ОС, но для которых приложение ещё не сделало accept. При
превышении лимита вот такое вот получается.
Кстати можете попробовать запустить например не 40 воркеров php-fpm
одним пулом, а 5 пулов по 8 воркеров с разными сокетами, между которыми
сделать балансинг nginx'ом.

[Rauan Maemirov]

Надо же. Сейчас пробуем. А как быть допустим

location / {
fastcgi_pass unix:/var/log/php.sock;
fastcgi_index index.php;
}
Придется 5 разных серверов прописывать?

Возможно ли как-то просто менять адреса пулов?

[Alex Vorona]

Rauan Maemirov пишет:

> Надо же. Сейчас пробуем. А как быть допустим
>
> location / {
> fastcgi_pass unix:/var/log/php.sock;
> fastcgi_index index.php;
> }
> Придется 5 разных серверов прописывать?
>
> Возможно ли как-то просто менять адреса пулов?
>
>

http://sysoev.ru/nginx/docs/http/ngx_http_upstream.html

[Rauan Maemirov]

Все прописал.

а в логах у меня вот так должно светиться?

upstream: "fastcgi://unix:/var/log/php5.sock:"

И еще, я прописал 5 pool-ов. Но там громоздко получается. Возможно ли
проставить один default-ный pool, а в остальных только listen_address
прописывать?

[Alex Vorona]

Rauan Maemirov пишет:
> Все прописал.
>
>
интересен эффект времени отклика на тех же 500 параллельных запросах.

> а в логах у меня вот так должно светиться?
>
> upstream: "fastcgi://unix:/var/log/php5.sock:"
>
>

думаю да. Сервер, отработавший запрос, должен падать в лог, ну и должны
сервера меняться в режиме round-robin.

> И еще, я прописал 5 pool-ов. Но там громоздко получается. Возможно ли
> проставить один default-ный pool, а в остальных только listen_address
> прописывать?
>
>

насколько я знаю, это в разработке

[Rauan Maemirov]

Спасибо, работает безупречно.

И еще вопрос. Как проставлять rlimit_files? Аналогично children-ам
делить на 5 или он для всех пулов держит общие дескрипторы? Сейчас
стоит 10240. ulimit -n стоит 10240 и на nginx то же значение на
worker_rlimit_nofile.

On May 5, 3:52 am, Alex Vorona <vorona...@gmail.com> wrote:
> Rauan Maemirov пишет:> Все прописал.

[Rauan Maemirov]

А вот тут вот вся малина. :)

Без ip_hash разницы особой не обнаружил.

А с ним можно сказать, что как будто и не делал benchmark.

Хотя для одного пользователя наверное эффект никак не изменится, но
все-таки это лучше.

[Alex Vorona]

Rauan Maemirov пишет:

> Спасибо, работает безупречно.
>
> И еще вопрос. Как проставлять rlimit_files?

внутри секции pool
<value name="rlimit_files">1024</value>

> Аналогично children-ам
> делить на 5 или он для всех пулов держит общие дескрипторы? Сейчас
> стоит 10240. ulimit -n стоит 10240 и на nginx то же значение на
> worker_rlimit_nofile.
>
>

это лимит одновременно открытых дескрипторов для одного процесса.

[Alex Vorona]

Rauan Maemirov пишет:

> А вот тут вот вся малина. :)
>
> Без ip_hash разницы особой не обнаружил.
>
>

Хотя если разница и могла бы быть, то как раз без него.
Расчёт был на то, что очередей сокетов теперь 5 и забирать из них
запросы php-воркеры разных пулов могут параллельно.
В access_log nginx'а добавьте $upstream_addr и проследите, меняется ли
адрес сокета у запросов.
Если меняется, то балансировка nginx'ом идёт, но эффекта от неё, как я
понял, нет.

[Rauan Maemirov]

Да, меняется. Только эффекта дейсвительно нет. В чем может быть
причина? Но при включенном ip_hash, допустим, если я делаю benchmark,
то он полностью занимает один пул, а на остальных (одном из них) я
свободно серфю. Тоже неплохо.

А в чем может быть загвоздка? насчет эффекта без ip_hash.

[Andrei Nigmatulin]

Это две ошибки - в linux и в nginx. Судя вот по этому strace

http://www.ruby-forum.com/topic/132314

ядро возвращает EAGAIN на неблокирующийся connect (только для unix socket, при
превышении backlog), хотя должен EINPROGRESS, а nginx пытается записать в
сокет данные, хотя не должен этого делать.

--
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

[Andrei Nigmatulin]

On Sunday 04 May 2008 23:55, Alex Vorona wrote:
> Rauan Maemirov пишет:
> > Ураааа. Теперь вообще не вылазят ошибки. И даже при 500
> > конкурентных... Ну разве что время отклика увеличилось.
>
> Андрей, может стОит сделать проверку в php-fpm и на превышение
> системного лимита варнинговать в лог?

Сравнивать backlog и /proc/sys/net/core/somaxconn ? Не вижу смысла, это
linux-specific и админстратор должен знать про это. В FAQ можно указать,
впринципе.

[Alex Vorona]

Andrei Nigmatulin пишет:

> On Sunday 04 May 2008 23:55, Alex Vorona wrote:
>
>> Rauan Maemirov пишет:
>>
>>> Ураааа. Теперь вообще не вылазят ошибки. И даже при 500
>>> конкурентных... Ну разве что время отклика увеличилось.
>>>
>> Андрей, может стОит сделать проверку в php-fpm и на превышение
>> системного лимита варнинговать в лог?
>>
>
> Сравнивать backlog и /proc/sys/net/core/somaxconn ? Не вижу смысла, это
> linux-specific и админстратор должен знать про это. В FAQ можно указать,
> впринципе.
>
>

во FreeBSD тот же kern.ipc.somaxconn, который также не может быть
превышен backlog'ом

[Rauan Maemirov]

Какое-то странное поведение.
Отсюда http://www.lexa.ru/nginx-ru/msg17635.html

Как говорится, а все-таки она вертится. Подозреваю, что дело в БД. Я
использую persistent_connection (через pgpoolII-beta, до этого был
последний stable, но были те же проблемы).

Однако, по крайней мере, я ведь должен был увидеть в top что хоть что-
то происходит. А там пусто.

[Andrei Nigmatulin]

On Friday 16 May 2008 01:47, Rauan Maemirov wrote:
> Какое-то странное поведение.
> Отсюда http://www.lexa.ru/nginx-ru/msg17635.html
>
> Как говорится, а все-таки она вертится. Подозреваю, что дело в БД. Я
> использую persistent_connection (через pgpoolII-beta, до этого был
> последний stable, но были те же проблемы).
>
> Однако, по крайней мере, я ведь должен был увидеть в top что хоть что-
> то происходит. А там пусто.

Страницы отдаются не до конца ? Надо трейсить php и nginx, чтобы разобраться.

[Rauan Maemirov]

Нет, не то чтобы не до конца, но как будто коннект потерялся. Иногда
слетает, а иногда отдает с долгим временем отклика.

On May 16, 4:11 am, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:

> On Friday 16 May 2008 01:47, Rauan Maemirov wrote:
>
> > Какое-то странное поведение.

> > Отсюдаhttp://www.lexa.ru/nginx-ru/msg17635.html

[Alexey V. Karagodov]

On 16.05.2008, at 9:40, Rauan Maemirov wrote:

> Нет, не то чтобы не до конца, но как будто коннект потерялся. Иногда
> слетает, а иногда отдает с долгим временем отклика.
>
> On May 16, 4:11 am, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
> wrote:
>> On Friday 16 May 2008 01:47, Rauan Maemirov wrote:
>>
>>> Какое-то странное поведение.
>>> Отсюдаhttp://www.lexa.ru/nginx-ru/msg17635.html

в этом треде оказалось, что небыло места на диске под временные
файлы ...

[Rauan Maemirov]

Да, там было это. Но у меня с местом на диске вроде все в порядке.

On May 16, 11:43 am, "Alexey V. Karagodov" <k...@karagodov.name>
wrote:

[Rauan Maemirov]

Как и подозревалось проблема была в пуле. max_children был больше чем
num_init_children к БД, поэтому ступорилось. Извиняюсь.

On May 16, 3:47 am, Rauan Maemirov <rauan1...@gmail.com> wrote:
> Какое-то странное поведение.

> Отсюдаhttp://www.lexa.ru/nginx-ru/msg17635.html

[Rauan Maemirov]

Аналогичная ситуация возникла на другом серваке, только уже при
реальной нагрузке.

Я уже somaxconn аж 10240 поставил.

Ничего не помогает. mysql жрет 100% CPU (а памяти максимум 10-15%),
выдается 502. Но раньше он и все 220% жрал и ниче, все работало.

nginx: processes=6, connections=6144
php-fpm: max_children=100.

Какие еще workaround-ы есть по этой проблеме?

On May 4, 11:18 pm, Rauan Maemirov <rauan1...@gmail.com> wrote:

[Rauan Maemirov]

Ох, от этого решения нет. Это была DoS-атака. :(