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

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

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

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

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru