Re: как правильно закрывать соединения при наступлении keepalive_requests: обсудим ?

[Илья Шипицин]

пн, 3 сент. 2018 г. в 16:11, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то на
> > стороне nginx удивительным образом все хорошо (потому что соединение
> > закрывается по инициативе бекенда)
> >
> > если проксировать с включенным кипэлайвом, то в случаях, когда соединение
> > закрывается по инициативе nginx, на стороне  nginx порт уходит в
> > TIME_WAIT.
> >
> > с одной стороны - несмертельно. все с этим живут.
> > с другой стороны - например, в случае, когда запрос последний (100-й при
> > дефолтном значении keepalive_requests), можно ведь явно добавить
> > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и
> > сэкономить один порт на nginx ?
>
> Теоретически - можно.
>
> Практически - формирование запроса на бэкенд происходит до того,
> как бэкенд выбран и/или установлено или извлечено из кэша
> соединение, которое будет использоваться для отправки запроса.
> Кроме того, один и тот же запрос может быть отправлен на несколько
> разных бэкендов и/или в несколько разных соединений.
>
> Соответственно выставление "Connection: close" по достижении
> keepalive_requests для конкретного соединения к бэкенду -
> потребует достаточно серьёзных переделок в логике работы с
> бэкендами.  Не говоря уже о том, что сейчас при использовании
> keepalive-соединений заголовок Connection выставляется из конфига
> через proxy_set_header, и это тоже понадобится переделывать.
>

да, я про эту магию и говорил. в некоторых случаях можно сделать более умно


>
> Так что если порты очень жмут - то проще поднять
>

не жмут. мы научились с этим жить.
просто в процессе исследований пришла мысль, про которую я и написал.
было бы круто в какие-нибудь планы разработки ее включить


> keepalive_requests.  Или выставить на бэкенде аналогичное
>

на бекенде iis, там нет такой крутилки


> ограничение в значение, которое бы было такое же или меньше, чему
> у nginx'а, и тогда бэкенд будет закрывать соединение сам.
> Собственно, текущее значение по умолчанию keepalive_requests к
>

поднимать keepalive_requests в потолок - была такая ошибка.
мы налетели на примерно такой сценарий

по умолчанию keepalive_requests равен 100. и ... при релоаде старые воркеры
довольно быстро завершаются.
подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40
воркеров. и потом память закончилась

keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :))



> клиентам совпадает с keepalive_requests к бэкендам, так что если в
> роли бэкенда тоже nginx - то при настройках по умолчанию он будет
> закрывать соединение сам.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180903/b1bad27c/attachment.html>