Re: upstream c keepalive и периодически 502 ошибка

[Maxim Dounin]

Hello!

On Tue, Oct 18, 2016 at 05:31:00AM -0400, waster wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Соединение с бекендом, какое бы оно ни было постоянное, 
> > периодически закрывается.  Если это происходит в тот момент, когда 
> > nginx послал в соединение запрос - с точки зрения nginx'а это 
> > выглядит как ошибка.
> > 
> > Чтобы nginx имел возможность в такой ситуации перепослать запрос 
> > ещё раз - стоит описать ещё один server в блоке upstream, можно 
> > тот же самый.  Тогда вместо возврата 502 клиенту nginx пойдёт на 
> > следующий сервер в соответствии с настройкой proxy_next_upstream, 
> > и вернёт пользователю полученный ответ.
> 
> Похоже, что даже с одним server в блоке upstream уже происходит перепосылка
> запроса, судя по нескольким ответам, сначала 502, потом 200 в логах в
> $upstream_status, предположу, что такое поведение обеспечивается за счет
> max_fails.

Нет, это я ошибся: если сервер строго один, то запрос будет 
перепосылаться на него же, если ошибка произошла при попытке 
воспользоваться закешированным keepalive-соединением.

> То есть можно игнорировать эти ошибки или может как-то можно их
> минимизировать, скажем, выставив keepalive_timeout на бэкенде больше, чем
> что-либо на прокси (правда не знаю что)?

Если клиенту возвращается 502 - значит, получить ответ не удалось.  
Если же ошибка 502 видна только в $upstream_status - то это может 
быть нормальным следствием того, что бекенд закрыл 
keepalive-соединение.  Может, впрочем, и не быть.

> > Задержки в $upstream_connect_time - это скорее всего либо потери 
> > пакетов, либо переполненная listen queue на бекенде (что на 
> > Linux'е при настройках по умолчанию выглядит как потеря 
> > SYN-пакета).
> 
> Вряд ли это переполненная очередь на бэкенде, там сейчас  backlog=65535 и
> net.core.somaxconn = 65535
> net.ipv4.tcp_max_syn_backlog = 65535 и net.ipv4.ip_local_port_range = 16384
> 65535. Такие же задержки возникают и на уровне upstream_header_time,
> например, upstream_header_time > 1, а upstream_connect_time=0.02. Бывает
> вообще только upstream_response_time > 1, а все остальные = 0.02. Это и
> странно, поскольку трафик и нагрузка на бэкенде небольшие.

Переполнения очереди лучше посмотреть явно, благо статистику 
система ведёт (а "netstat -s" умеет показывать).  И/или включить 
на бекендах net.ipv4.tcp_abort_on_overflow, чтобы задержек при 
переполнении очереди не было, а сразу была ошибка.

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

-- 
Maxim Dounin
http://nginx.org/