Re: Проблемы с proxy connect timeout

[Maxim Dounin]

Hello!

On Tue, Aug 08, 2017 at 11:13:43AM -0400, d.sibilkov wrote:

> >Модули ngx_stream_proxy_module и ngx_http_proxy_module - это два 
> >совершенно разных модуля, и каждый имеет свои собственные 
> >конфигурационные директивы.
> 
> Как мне тогда понять какой proxy_connect_timeout я использую и в чем
> разница?

Модуль ngx_stream_proxy_module работает исключительно в блоке 
stream{}, и работает с произвольными соединениями.  Модуль 
ngx_http_proxy_module - в блоке http{}, и имеет дело с 
http-запросами в рамках модуля http.

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

> >Для начала стоит разобраться в том, почему "упавший" бекенд 
> >продолжает принимать соединения. И сделать так, чтобы не 
> >продолжал. 
> 
> Он и не продолжает, просто сервер висит с открытым портом, если Вы
> зателнетитесь на любой открытый порт он соединение установит но данные
> никакие ходить не будут т.к. порт никто не слушает - сервис который должен
> слушать порт лежит. 

В том, что бекенд упал, а порт остался открытым - и есть проблема.  
В норме listen-сокет автоматически закрывается, если приложение, 
его открывшее, падает.  И это позволяет детектировать падение 
бекенда на этапе установления соединения.

Вероятно, первопричина проблемы в том, что вы пытаетесь 
использовать systemd.  Который, в свою очередь, падение бекенда 
увидеть не даёт.  Так жить можно, но только в отсутствии нагрузки, 
и когда ожидание таймауту на чтение - это нормально.  Если же 
такое поведение начинает доставлять проблемы, то решений тут 
возможно два:

- выкинуть systemd, чтобы он не скрывал от nginx'а, что происходит 
  с реальным бекендом;

- решать проблему в рамках systemd, и искать в нём соответствующий 
  таймаут.

> >Ну и очевидно, что если у вас бекенды падают, и детектирование 
> >упавшего бекенда знимает 60 секунд, уменьшать fail_timeout до 5 
> >секунд несколько, как бы это сказать, расточительно. Наоборот, 
> >стоит поднять до каких-либо сравнимых значений.
> 
> Так вот мне и нужно чтобы это занимало не 60с (которые срабатывают по
> proxy_read_timeout) а как можно меньше.
> Я судя по всему чего-то не понимаю или мы просто о разных вещах говорим..

Чтобы детектирование проблемы занимало меньше времени, нужно 
либо лечить бекенды (см. выше), либо уменьшать proxy_read_timeout.  
Других вариантов, по большому счёту, нет.

Чтобы после детектирования проблемы минимизировать от неё ущерб - 
надо увеличивать fail_timeout, а не уменьшать, как сделали вы.

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