пн, 3 сент. 2018 г. в 16:11, Maxim Dounin <[email protected]>:
> 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 > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
