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/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru