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

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

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

> Hello!
>
> On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote:
>
> > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > > 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, и это тоже понадобится переделывать.
> >
> > да, я про эту магию и говорил. в некоторых случаях можно сделать более
> умно
> >
> > > Так что если порты очень жмут - то проще поднять
> >
> > не жмут. мы научились с этим жить.
> > просто в процессе исследований пришла мысль, про которую я и написал.
> > было бы круто в какие-нибудь планы разработки ее включить
>
> Ну вот я изложил выше - там много всего переделывать, причём - с
> деградацией производительности в некоторых краевых случаях.  При
> этом сама проблема, скажем так, представляется не то чтобы
> критичной.  Так что шансов, что мы решим-таки это место
> переделывать - не очень много.
>

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

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


>
> > > keepalive_requests.  Или выставить на бэкенде аналогичное
> >
> > на бекенде iis, там нет такой крутилки
> >
> > > ограничение в значение, которое бы было такое же или меньше, чему
> > > у nginx'а, и тогда бэкенд будет закрывать соединение сам.
> > > Собственно, текущее значение по умолчанию keepalive_requests к
> > >
> >
> > поднимать keepalive_requests в потолок - была такая ошибка.
> > мы налетели на примерно такой сценарий
> >
> > по умолчанию keepalive_requests равен 100. и ... при релоаде старые
> воркеры
> > довольно быстро завершаются.
> > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40
> > воркеров. и потом память закончилась
> >
> > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :))
>
> Соединения в keepalive'е - что клиентские, что к бэкендам - никак
> не должны влиять на завершение рабочих процессов при reload'е.
> Они просто закрываются при получении сигнала о перезагрузке
> конфигурации и/или если соединение переходит в keepalive, когда
> рабочий процесс завершается.  Если влияют - приносите подробности,
> будем разбираться.
>

воркер же будет обрабатывать запросы по уже установленным соединениям, пока
либо клиент не отключится,
либо пока   воркер сам не закроет (при исчерпании keepalive_requests) ?

а новый релоад приводит к запуску кучи новых воркеров. но не приводит к
завершению старых воркеров ?


>
> --
> 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/df72a579/attachment-0001.html>