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

[Maxim Dounin]

Hello!

On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote:

> пн, 3 сент. 2018 г. в 16:11, Maxim Dounin <mdounin at 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, и это тоже понадобится переделывать.
> 
> да, я про эту магию и говорил. в некоторых случаях можно сделать более умно
> 
> > Так что если порты очень жмут - то проще поднять
> 
> не жмут. мы научились с этим жить.
> просто в процессе исследований пришла мысль, про которую я и написал.
> было бы круто в какие-нибудь планы разработки ее включить

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

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

Соединения в keepalive'е - что клиентские, что к бэкендам - никак 
не должны влиять на завершение рабочих процессов при reload'е.  
Они просто закрываются при получении сигнала о перезагрузке 
конфигурации и/или если соединение переходит в keepalive, когда 
рабочий процесс завершается.  Если влияют - приносите подробности, 
будем разбираться.

-- 
Maxim Dounin
http://mdounin.ru/