<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">пн, 3 сент. 2018 г. в 18:15, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Mon, Sep 03, 2018 at 05:43:17PM +0500, Илья Шипицин wrote:<br>
<br>
> пн, 3 сент. 2018 г. в 17:30, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>>:<br>
> <br>
> > Hello!<br>
> ><br>
> > On Mon, Sep 03, 2018 at 04:45:31PM +0500, Илья Шипицин wrote:<br>
> ><br>
> > > пн, 3 сент. 2018 г. в 16:11, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>>:<br>
> > ><br>
> > > > On Sun, Sep 02, 2018 at 11:12:31PM +0500, Илья Шипицин wrote:<br>
> > > ><br>
> > > > > есть такое наблюдение. если проксировать на апстрим БЕЗ киэлайв, то<br>
> > на<br>
> > > > > стороне nginx удивительным образом все хорошо (потому что соединение<br>
> > > > > закрывается по инициативе бекенда)<br>
> > > > ><br>
> > > > > если проксировать с включенным кипэлайвом, то в случаях, когда<br>
> > соединение<br>
> > > > > закрывается по инициативе nginx, на стороне  nginx порт уходит в<br>
> > > > > TIME_WAIT.<br>
> > > > ><br>
> > > > > с одной стороны - несмертельно. все с этим живут.<br>
> > > > > с другой стороны - например, в случае, когда запрос последний (100-й<br>
> > при<br>
> > > > > дефолтном значении keepalive_requests), можно ведь явно добавить<br>
> > > > > "Connection: Close" ? тем самым помочь бекенду закрыть соединение, и<br>
> > > > > сэкономить один порт на nginx ?<br>
> > > ><br>
> > > > Теоретически - можно.<br>
> > > ><br>
> > > > Практически - формирование запроса на бэкенд происходит до того,<br>
> > > > как бэкенд выбран и/или установлено или извлечено из кэша<br>
> > > > соединение, которое будет использоваться для отправки запроса.<br>
> > > > Кроме того, один и тот же запрос может быть отправлен на несколько<br>
> > > > разных бэкендов и/или в несколько разных соединений.<br>
> > > ><br>
> > > > Соответственно выставление "Connection: close" по достижении<br>
> > > > keepalive_requests для конкретного соединения к бэкенду -<br>
> > > > потребует достаточно серьёзных переделок в логике работы с<br>
> > > > бэкендами.  Не говоря уже о том, что сейчас при использовании<br>
> > > > keepalive-соединений заголовок Connection выставляется из конфига<br>
> > > > через proxy_set_header, и это тоже понадобится переделывать.<br>
> > ><br>
> > > да, я про эту магию и говорил. в некоторых случаях можно сделать более<br>
> > умно<br>
> > ><br>
> > > > Так что если порты очень жмут - то проще поднять<br>
> > ><br>
> > > не жмут. мы научились с этим жить.<br>
> > > просто в процессе исследований пришла мысль, про которую я и написал.<br>
> > > было бы круто в какие-нибудь планы разработки ее включить<br>
> ><br>
> > Ну вот я изложил выше - там много всего переделывать, причём - с<br>
> > деградацией производительности в некоторых краевых случаях.  При<br>
> > этом сама проблема, скажем так, представляется не то чтобы<br>
> > критичной.  Так что шансов, что мы решим-таки это место<br>
> > переделывать - не очень много.<br>
> ><br>
> <br>
> с деградацией не надо, конечно.<br>
> из того, что вы изложили - непонятно, каким именно бекендом обработается<br>
> запрос - кажется, что<br>
> можно предположить "если к первому бекенду это последний запрос -<br>
> принудительно пишем Connection: close"<br>
> <br>
> другое дело, что в момент, когда выставляется хедер, непонятно про бекенд<br>
> вообще ничего - это да.<br>
<br>
Сейчас запрос создаётся до того, как что-либо становится известно <br>
про бэкенды.  И используется этот единожды созданный запрос - для <br>
всех последующих обращений к любым бэкендам.  Таких обращений <br>
может быть много, в соответствии с proxy_next_upstream.  Более <br>
того, иногда "много" - это штатное поведение, скажем при <br>
"proxy_next_upstream http_404" предполагается, что nginx <br>
перебирает бэкенды, пока не найдёт тот, на котором есть <br>
соответствующий ресурс.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Чтобы выставить "Connection: close" - надо менять логику так, <br>
чтобы запрос создавался уже в процессе обращения к бэкенду, когда <br>
соединение с бэкендом уже установлено или получено из кэша.  И <br>
соответственно делать так, чтобы запрос для каждого обращения на <br>
бэкенд в рамках proxy_next_upstream - создавался заново.<br></blockquote><div><br></div><div>с точки зрения протокола http (кроме 2-й версии), в рамках каждого запроса (на каждый бекенд) отправляется свой заголовок  <br></div><div>"Connection: Close" (или Keep-Alive)</div><div><br></div><div>кажется, что поменять его во время запроса - не поздно.</div><div><br></div><div>то, что на http_404 будет отправляться Connection: close - не криминал, пусть отправляется<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > > > keepalive_requests.  Или выставить на бэкенде аналогичное<br>
> > ><br>
> > > на бекенде iis, там нет такой крутилки<br>
> > ><br>
> > > > ограничение в значение, которое бы было такое же или меньше, чему<br>
> > > > у nginx'а, и тогда бэкенд будет закрывать соединение сам.<br>
> > > > Собственно, текущее значение по умолчанию keepalive_requests к<br>
> > > ><br>
> > ><br>
> > > поднимать keepalive_requests в потолок - была такая ошибка.<br>
> > > мы налетели на примерно такой сценарий<br>
> > ><br>
> > > по умолчанию keepalive_requests равен 100. и ... при релоаде старые<br>
> > воркеры<br>
> > > довольно быстро завершаются.<br>
> > > подняли до 4 миллиардов, и на каждый релоад получили плюсом еще 40<br>
> > > воркеров. и потом память закончилась<br>
> > ><br>
> > > keepalive_requests - это ОЧЕНЬ удобный способ завершать http- воркеры :))<br>
> ><br>
> > Соединения в keepalive'е - что клиентские, что к бэкендам - никак<br>
> > не должны влиять на завершение рабочих процессов при reload'е.<br>
> > Они просто закрываются при получении сигнала о перезагрузке<br>
> > конфигурации и/или если соединение переходит в keepalive, когда<br>
> > рабочий процесс завершается.  Если влияют - приносите подробности,<br>
> > будем разбираться.<br>
> ><br>
> <br>
> воркер же будет обрабатывать запросы по уже установленным соединениям, пока<br>
> либо клиент не отключится,<br>
> либо пока   воркер сам не закроет (при исчерпании keepalive_requests) ?<br>
<br>
Keepalive-соединения nginx впрове закрывать в любой момент, и <br>
именно это он и делает - в любой момент времени, когда бы рабочий <br>
процесс не попросили завершиться.<br>
<br>
Поэтому в случае http - время завершения старых рабочих процессов <br>
определяется длительностью запросов, и не зависит от того, <br>
используется ли keepalive или нет.<br>
<br>
> а новый релоад приводит к запуску кучи новых воркеров. но не приводит к<br>
> завершению старых воркеров ?<br>
<br>
Reload приводит к запуску новых рабочих процессов, а также к <br>
команде на плавное завершение старым рабочим процессам.  Плавное <br>
завершение - подразумевает закрытие всех keepalive-соединений, и <br>
выход в тот момент, когда открытых соединений (точнее - работающих <br>
таймеров) не останется, то есть тогда, когда доработают все <br>
существующие запросы.<br></blockquote><div><br></div><div>понаблюдаем<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>