<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>При connect-таймауте в 300 миллисекунд любой потерянный пакет<br>
будет приводить к таймауту.  А какой-то процент потерянных пакетов - это<br>
нормальное состояние любой сети, так что нет причин удивляться<br>
тому, что часть соединений при таких настройках таймаутится.</div></blockquote><div>Да, какая-то часть таймаутиться будет, это нормально. Я ожидал другого времени в логе +- 300мс.<br></div><div>Если таймаут поднять и умрет ДЦ, то 1/3  запросов в api будет с сильно увеличенным временем ответа, а это приведет к тормозам всего сервиса. Локально обрабатывать трафик - железо разное.<br></div><div>Завтра подниму до 700, посмотрим на результат.<br></div><div class="gmail_extra"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Кроме того, следует понимать, что время внутри nginx'а обновляется<br>
единожды за итерацию цикла обработки событий.  В результате если<br>
обработка какого-то события занимает существенное время и/или<br>
таких событий много, это может сказаться как на latency операций в<br>
целом, так и на точности работы отдельных таймаутов.  Поскольку<br>
300 миллисекунд - время достаточно малое, это может быть заметно,<br>
если сервер сильно нагружен и/или где-то блокируется.<br></blockquote><br></div><div class="gmail_extra">Сейчас ~ 150 rps на хост, машина не нагружена более чем на 40%. ~ в каких временных пределах может быть погрешность?<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">В связи с вышеизложенным не могу не отметить, что в вашем конфиге<br>
видны следы стороннего модуля отправки статистики в graphite.<br>
Судя по коду[1], в tcp-режиме этот модуль блокирует рабочий процесс<br>
при отправке накопленной статистики на сервер.  Это, скажем мягко,<br>
малопригодное для production-использования решение, так что стоит<br>
начать с простого - убрать модуль совсем, и посмотреть на<br>
результат.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Большое спасибо, отправил замечание. У нас UDP.<br>nginx.conf: <a href="https://ufile.io/w25u7">https://ufile.io/w25u7</a><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Александр<br></div></div></div>
<br><div class="gmail_quote">15 июня 2017 г., 18:24 пользователь Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<span class="gmail-"><br>
On Thu, Jun 15, 2017 at 05:21:38PM +0300, Алексанр Платонов wrote:<br>
<br>
</span><div><div class="gmail-h5">> Добрый день.<br>
><br>
> У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и<br>
> распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же<br>
> хостах.<br>
><br>
> Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на<br>
> случайном хосте получает ошибку:<br>
> front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed<br>
> out (110: Connection timed out) while connecting to upstream, client:<br>
> 217.69.135.0, server: site, request: "GET<br>
> /files/images/1284_1284/58/b4/<wbr>58b455be4b559395714059e5.jpg<br>
> HTTP/1.0", upstream: "fastcgi://<a href="http://217.69.137.52:8081" rel="noreferrer" target="_blank">217.69.137.52:8081</a>"<wbr>, host: "site"<br>
><br>
> после получения ошибки nginx проксирует запрос на другой сервер и там все<br>
> отрабатывает нормально.<br>
><br>
> front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET<br>
> /files/images/1284_1284/58/b4/<wbr>58b455be4b559395714059e5.jpg HTTP/1.0" 200<br>
> 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:<br>
> <a href="http://217.69.137.52:8081" rel="noreferrer" target="_blank">217.69.137.52:8081</a>, <a href="http://217.69.137.51:8081" rel="noreferrer" target="_blank">217.69.137.51:8081</a> upstream_response_time: 0.677, 0.981<br>
> upstream_status: 504, 200 upstream_cache_status: - "tid:"<br>
> 13063-1497530259.494-217.69.<wbr>135.0-163-2446289<br>
><br>
> Меня волнует это так как увеличивается время ответа и всегда есть некий<br>
> фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает таймаут и<br>
> как его избежать?<br>
><br>
> Файл nginx-debug с одной проблемной сессией: <a href="https://uploadfiles.io/eokgp" rel="noreferrer" target="_blank">https://uploadfiles.io/eokgp</a><br>
> Файл конфигурации nginx: <a href="https://ufile.io/w8x56" rel="noreferrer" target="_blank">https://ufile.io/w8x56</a><br>
> Список upstream: <a href="https://ufile.io/3tt84" rel="noreferrer" target="_blank">https://ufile.io/3tt84</a><br>
> Cписок параметров fastcgi: <a href="https://ufile.io/gdzaa" rel="noreferrer" target="_blank">https://ufile.io/gdzaa</a><br>
> Sysctl: <a href="https://ufile.io/cdboz" rel="noreferrer" target="_blank">https://ufile.io/cdboz</a><br>
><br>
> Снимал несколько раз tcpdump и наблюдал следующую картину:<br>
> 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду<br>
> через 13ms, не пересылая данные вообще.<br>
> 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от<br>
> бэкенда и через ~ 780 мкс от своего SYN.<br>
><br>
> типовой ss -i<br>
> ESTAB      0      0          <a href="http://217.69.134.124:40538" rel="noreferrer" target="_blank">217.69.134.124:40538</a>        217.69.137.52:tproxy<br>
><br>
>      cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865<br>
> segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600<br>
><br>
> Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в логе<br>
> вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?<br>
<br>
</div></div>При connect-таймауте в 300 миллисекунд любой потерянный пакет<br>
будет приводить к таймауту.  А какой-то процент потерянных пакетов - это<br>
нормальное состояние любой сети, так что нет причин удивляться<br>
тому, что часть соединений при таких настройках таймаутится.<br>
<br>
Кроме того, следует понимать, что время внутри nginx'а обновляется<br>
единожды за итерацию цикла обработки событий.  В результате если<br>
обработка какого-то события занимает существенное время и/или<br>
таких событий много, это может сказаться как на latency операций в<br>
целом, так и на точности работы отдельных таймаутов.  Поскольку<br>
300 миллисекунд - время достаточно малое, это может быть заметно,<br>
если сервер сильно нагружен и/или где-то блокируется.<br>
<br>
В связи с вышеизложенным не могу не отметить, что в вашем конфиге<br>
видны следы стороннего модуля отправки статистики в graphite.<br>
Судя по коду[1], в tcp-режиме этот модуль блокирует рабочий процесс<br>
при отправке накопленной статистики на сервер.  Это, скажем мягко,<br>
малопригодное для production-использования решение, так что стоит<br>
начать с простого - убрать модуль совсем, и посмотреть на<br>
результат.<br>
<br>
[1] <a href="https://github.com/mailru/graphite-nginx-module/blob/master/src/ngx_http_graphite_module.c#L2204" rel="noreferrer" target="_blank">https://github.com/mailru/<wbr>graphite-nginx-module/blob/<wbr>master/src/ngx_http_graphite_<wbr>module.c#L2204</a><br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div></div>