Отладка времени ожидания шлюза 504, его причина и решение

Мы запускаем следующий стек на нашем веб-сервере Varnish + Nginx + FastCGI (php-fpm) на RHEL 6.6

Это динамичный веб-сайт с различными наборами результатов каждый раз и имеет около 2 миллионов URL, проиндексированных с помощью Google.

• Он работает на nginx / 1.5.12 и PHP 5.3.3 (скоро будет обновлен до последних версий nginx и PHP)
• Nginx подключается к php-fpm, работающему локально на том же сервере через порт 9000

На некоторых страницах мы периодически получаем тайм-аут 504 Gateway, который мы не можем разрешить. URL, которые дают 504, прекрасно работает через некоторое время.
Мы узнаем около 504 из наших журналов, и нам не удалось воспроизвести это, поскольку это случайно происходит на любом URL и работает через некоторое время.

У меня было несколько обсуждений с разработчиком, но, по его мнению, базовый сценарий php почти ничего не делает, и это не должно занимать так много времени (120 секунд), но все равно дает 504 Gateway timeout.

Необходимо установить, где именно проблема возникает:

• Это проблема с Nginx?
• Это проблема с php-fpm?
• Это проблема с базовыми PHP-скриптами?
• Возможно ли, что nginx не может подключиться к php-fpm?
• Разрешится ли это, если мы будем использовать Unix-сокет вместо TCP / IP-соединения с?

URL истекает через 120 секунд с 504

Ниже показана ошибка:
2016/01/04 17:29:20 [ошибка] 1070 # 0: * 196333149 тайм-аут восходящего потока (110: тайм-аут соединения) при подключении к восходящему каналу, клиент: 66.249.74.95, сервер: xxxx, запрос: «GET / Some / url HTTP / 1.1 «, upstream:» fastcgi: //127.0.0.1: 9000 «, хост:» example.com »

Ранее с fastcgi_connect_timeout 150 секунд — раньше он выдавал код состояния 502 через 63 секунды, по умолчанию net.ipv4.tcp_syn_retries = 5 на RHEL 6.6; после этого мы установили net.ipv4.tcp_syn_retries = 6, а затем он начал выдавать 502 через 127 секунд.

Как только я установил fastcgi_connect_timeout = 120, он начал давать код состояния 504. Я понимаю, что fastcgi_connect_timeout с таким высоким значением не годится.

Нужно выяснить, почему именно мы получаем 504 (я знаю его время ожидания, но причина неизвестна). Нужно добраться до первопричины, чтобы исправить это навсегда.

Как я могу подтвердить, где именно проблема?

Вот некоторые из тайм-аутов, уже определенных:

Под сервером nginx.conf:

• keepalive_timeout 5;
• send_timeout 150;

под конкретным vhost.conf:

• proxy_send_timeout 100
• proxy_read_timeout 100
• proxy_connect_timeout 100
• fastcgi_connect_timeout 120
• fastcgi_send_timeout 300
• fastcgi_read_timeout 300

Используются разные значения для тайм-аутов, поэтому я могу выяснить, какой именно тайм-аут был активирован.

Ниже приведены некоторые настройки из sysctl.conf:

• net.ipv4.ip_local_port_range = 1024 65500
• net.ipv4.tcp_fin_timeout = 10
• net.ipv4.tcp_tw_reuse = 1
• net.ipv4.tcp_syn_retries = 6
• net.core.netdev_max_backlog = 8192
• net.ipv4.tcp_max_tw_buckets = 2000000
• net.core.somaxconn = 4096
• net.ipv4.tcp_no_metrics_save = 1
• vm.max_map_count = 256000

Если это плохо написанный код, то я должен сообщить разработчику, что 504 происходит из-за проблемы в коде php, а не из-за nginx или php-fpm, и если это из-за Nginx или Php-fpm, то нужно это исправить.

Заранее спасибо!

======

Дальнейшее обновление:

Есть 2 случая:

1. 504 при 120 секундах с указанной ниже ошибкой:

2016/01/05 03:50:54 [ошибка] 1070 # 0: * 201650845 Тайм-аут восходящего потока (110: Тайм-аут соединения) при подключении к восходящему каналу, клиент: 66.249.74.99, сервер: xxxx, запрос: «GET / some / url HTTP / 1.1 «, upstream:» fastcgi: //127.0.0.1: 9000 «, хост:» example.com «

2. 504 @ 300 секунд с указанной ниже ошибкой:

2016/01/05 00:51:43 [ошибка] 1067 # 0: * 200656359 Тайм-аут восходящего потока (110: Тайм-аут соединения) при чтении заголовка ответа из восходящего потока, клиент: 115.112.161.9, сервер: 192.168.12.101, запрос: «GET / some / url HTTP / 1.1», upstream: «fastcgi: //127.0.0.1: 9000», хост: «example.com»

• В логах php-fpm ошибок не найдено.

• Количество php-fpm процессов также было нормальным. Backend не выглядит перегруженным, так как другие запросы одновременно выполнялись нормально.

• Используется только один пул php-fpm. Один основной (родительский) процесс php-fpm и другие подчиненные (дочерние) процессы обычно находятся в нормальном диапазоне только при соблюдении 5xx. Нет значительного роста числа процессов php-fpm, и даже если он растет, у сервера будет достаточно мощности, чтобы раскошелиться на новые и обработать запрос.