Re: Не понимаю в чем причина кода ответа 504 с ошибкой Connection timed out

[Алексанр Платонов]

Пожалуйста, новые дампы и логи.
https://ufile.io/0ony2
https://ufile.io/bgt1i

2017/06/22 15:53:55 [error] 45615#45615: *89748123 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 176.59.44.27,
server: server, request: "POST
/api/events/batch?app_id=311&uid=uid&usr_latitude=55.50582&adv_id=b309f032e4-4516-8950-cc01093bb398&usr_longitude=37.3288475&timestamp=1492954855
HTTP/1.1", upstream: "fastcgi://217.69.137.58:8086", host: "server"
2017/06/22 15:53:55 [error] 45611#45611: *89788909 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 46.146.189.93,
server: server, request: "POST
/api/events/batch?app_id=311&uid=uid&usr_latitude=0.0&adv_id=f341a189-59573f-a520-9c76b003d6c4&usr_longitude=0.0&timestamp=1498136049
HTTP/1.1", upstream: "fastcgi://217.69.137.35:8086", host: "server"

Есть идеи почему так может быть?

Таймаут поднимаю до 700, посмотрю на результат.

Левый модуль графита и на остальных проектах )

Александр

16 июня 2017 г., 0:42 пользователь Evgeniy Berdnikov <bgx на protva.ru>
написал:

> On Thu, Jun 15, 2017 at 09:07:39PM +0300, Алексанр Платонов wrote:
> > >  А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от
> бэкенда
> > >  пришёл с такой задержкой. Возможно, бэкенд перегружен.
> > >  Возможно, свитчи по пути перегружены трафиком.
> >
> > Дампы:
> > RST: https://ufile.io/09s7w
> > FIN: https://ufile.io/0bkq5
>
>  В обоих дампах время около 2017-06-14 20:41:12, т.е. вчерашний день.
>
> > это вот эти два запроса
> > 2017/06/15 13:12:43 [error] 8449#8449: *729923 upstream timed out (110:
> > Connection timed out) while connecting to upstream, client:
> 128.74.129.198,
> > server: site, request: "GET /api/v1/product/58a2ed54d53f3d224a6b05c5
> > HTTP/1.1", upstream: "fastcgi://217.69.137.168:8080", host: "api.site"
> > 2017/06/15 13:12:43 [error] 8471#8471: *734373 upstream timed out (110:
> > Connection timed out) while connecting to upstream, client:
> 31.173.243.12,
> > server: site, request: "GET
> > /api/v1/counters/5730243396ad843510595f43?adv_
> id=D5D4F8D7-DEB7-4FE0-807E-143651398124&app_id=iphone%
> 2F3782&timestamp=1497521562&uid=uid&usr_latitude=55.
> 0252283782156&usr_longitude=82.93059721079625
> > HTTP/1.1", upstream: "fastcgi://217.69.137.73:8080", host: "api.site"
>
>  А здесь другое время, и другой день. Логи с дампами не стыкуются.
>
> > Возможно  с RST это вторая попытка отправить пакет через RTO + некоторое
> > время, но из debug log nginx я не понял сколько было попыток, вроде одна.
>
>  Nginx не может знать, сколько было ретрансмиссий, эта информация из ядра
>  ему не передаётся. Но потерять в pcap-е пакеты практически невозможно.
>
>  Да, дампы странные. Однако желательна привязка к логам.
>
> > по трем ДЦ ~ хаотично и закономерности я не вижу.
> > Если бы воспроизводилась в одном месте, то я бы видел максимумы ошибок,
> > связанные с одним хостом/дц. Ситуация была бы и на других проектах, но
> пока
> > такого не замечали.
>
>  Это может быть отражением того, что проблема как-то связана с
> конфигурацией
>  nginx для конкретного проекта, возможно, с "левыми" модулями.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170622/f6627a00/attachment.html>