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

[Maxim Dounin]

Hello!

On Mon, Oct 17, 2016 at 07:42:31PM -0400, waster wrote:

> Доброго времени суток,
> 
> Для раздачи HLS настроена схема из двух серверов cache-origin, где ts-чанки
> отдаются cache, а все запросы на m3u8-плейлисты проксируются на origin. На
> cache настроено проксирование с keepalive. Для примера приведу
> соотвествующие куски конфига cache:
> 
> upstream hls01 {
>     server X.X.X.X:80 fail_timeout=10 max_fails=3;
>     keepalive 500;
> }

[...]

> В большинстве случаев все запросы к upstream обрабатываются быстро и без
> проблем, но в логах периодически появляется ошибка 502 "upstream prematurely
> closed connection while reading response header from upstream". Я включал
> логирование $upstream_status и видно, что в этот момент возвращается 502.
> Также снимал дамп трафика,  в этот момент видно, что шлется RST-пакет. Эта
> проблема очень похожа на ту, которая описана тут:
> https://github.com/h2o/h2o/issues/281
> 
> В чем может быть причина, и можно ли как-то избавиться от 502 на cache? 

Соединение с бекендом, какое бы оно ни было постоянное, 
периодически закрывается.  Если это происходит в тот момент, когда 
nginx послал в соединение запрос - с точки зрения nginx'а это 
выглядит как ошибка.

Чтобы nginx имел возможность в такой ситуации перепослать запрос 
ещё раз - стоит описать ещё один server в блоке upstream, можно 
тот же самый.  Тогда вместо возврата 502 клиенту nginx пойдёт на 
следующий сервер в соответствии с настройкой proxy_next_upstream, 
и вернёт пользователю полученный ответ.

> Для примера я также включал логирование различных времен ответов на запросы
> к upstream (request_time, upstream_response_time и др.) и в периоды большой
> нагрузки на cache, периодически наблюдаются задержки с ответами, т.е.
> upstream_connect_time, upstream_header_time, например от 1 до 5 сек. Хотя на
> origin трафик и нагрузка небольшие (см. выше). Пинг между origin и cache
> ~8ms.

Задержки в $upstream_connect_time - это скорее всего либо потери 
пакетов, либо переполненная listen queue на бекенде (что на 
Linux'е при настройках по умолчанию выглядит как потеря 
SYN-пакета).

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