Назад | Перейти на главную страницу

Nginx как балансировщик нагрузки. Частый тайм-аут восходящего потока (110: тайм-аут соединения) при подключении к восходящему потоку

Я пытаюсь использовать nginx на виртуальной машине centos 7 в качестве балансировщика нагрузки для замены устаревшего аппаратного устройства Coyote Point. Однако в одном из наших веб-приложений мы видим частые и постоянные ошибки тайм-аута восходящего потока в журналах, и клиенты сообщают о проблемах сеанса при использовании системы.

Вот соответствующие биты из нашего nginx.conf

user  nginx;
worker_processes  4;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}

upstream farm {
   ip_hash;

   server www1.domain.com:8080;
   server www2.domain.com:8080 down;
   server www3.domain.com:8080;
   server www4.domain.com:8080;
}

server {
        listen 192.168.1.87:80;
        server_name host.domain.com;
        return         301 https://$server_name$request_uri;
}

server {
    listen 192.168.1.87:443 ssl;
    server_name host.domain.com;

    ## Compression
    gzip              on;
    gzip_buffers      16 8k;
    gzip_comp_level   4;
    gzip_http_version 1.0;
    gzip_min_length   1280;
    gzip_types        text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp;
    gzip_vary         on;

    tcp_nodelay on;
    tcp_nopush on;
    sendfile off;

    location / {
           proxy_connect_timeout   10;
           proxy_send_timeout      180;
           proxy_read_timeout 180; #to allow for large managers reports
           proxy_buffering off;
           proxy_buffer_size   128k;
           proxy_buffers   4 256k;
           proxy_busy_buffers_size   256k;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_pass http://farm;

           location ~* \.(css|jpg|gif|ico|js)$ {
                        proxy_cache mypms_cache;
                add_header X-Proxy-Cache $upstream_cache_status;
                        proxy_cache_valid 200 60m;
                        expires 60m;
                        proxy_pass http://farm;
                 }
 }

 location /basic_status {
    stub_status;
    }

    error_page 502 502 = /maintenance.html;
    location = /maintenance.html {
    root /www/;
 }
}

В журналах я часто вижу записи вроде

2015/03/13 15:22:58 [error] 4482#0: *557390 upstream timed out (110: Connection timed out) while connecting to upstream, client: 72.160.92.101, server: host.domain.com, request: "GET /tapechart.php HTTP/1.1", upstream: "http://192.168.1.50:8080/tapechart.php", host: "host.domain.com", referrer: "https://host.domain.com/tapechart.php"
2015/03/13 15:23:14 [error] 4481#0: *557663 upstream timed out (110: Connection timed out) while connecting to upstream, client: 174.53.144.4, server: host.domain.com, request: "GET /bkgtabs.php?bookingID=3105543&show=0 HTTP/1.1", upstream: "http://192.168.1.50:8080/bkgtabs.php?bookingID=3105543&show=0", host: "host.domain.com", referrer: "https://host.domain.com/bkgtabs.php?bookingID=3105543&show=0"
2015/03/13 15:23:19 [error] 4481#0: *557550 upstream timed out (110: Connection timed out) while connecting to upstream, client: 50.134.133.213, server: host.domain.com, request: "GET /tbltapechart.php?numNights=30&startDate=1-Aug-2015&roomTypeID=-1&hideNav=N&bookingID=&roomFilter=-1 HTTP/1.1", upstream: "http://192.168.1.50:8080/tbltapechart.php?numNights=30&startDate=1-Aug-2015&roomTypeID=-1&hideNav=N&bookingID=&roomFilter=-1", host: "host.domain.com", referrer: "https://host.domain.com/tapechart.php"
2015/03/13 15:23:37 [error] 4483#0: *561705 upstream timed out (110: Connection timed out) while connecting to upstream, client: 74.223.167.14, server: host.domain.com, request: "GET /js/multiselect/jquery.multiselect.filter.css HTTP/1.1", upstream: "http://192.168.1.55:8080/js/multiselect/jquery.multiselect.filter.css", host: "host.domain.com", referrer: "https://host.domain.com/fdhome.php"
2015/03/13 15:23:40 [error] 4481#0: *561099 upstream timed out (110: Connection timed out) while connecting to upstream, client: 74.223.167.14, server: host.domain.com, request: "GET /img/tabs_left_bc.jpg HTTP/1.1", upstream: "http://192.168.1.55:8080/img/tabs_left_bc.jpg", host: "host.domain.com", referrer: "https://host.domain.com/fdhome.php"
2015/03/13 15:23:45 [error] 4481#0: *557214 upstream timed out (110: Connection timed out) while connecting to upstream, client: 75.37.141.182, server: host.domain.com, request: "GET /tapechart.php HTTP/1.1", upstream: "http://192.168.1.50:8080/tapechart.php", host: "host.domain.com", referrer: "https://host.domain.com/tapechart.php"
2015/03/13 15:23:52 [error] 4482#0: *557330 upstream timed out (110: Connection timed out) while connecting to upstream, client: 173.164.149.18, server: host.domain.com, request: "GET /bkgtabs.php?bookingID=658108460B&show=1&toFolioID=3361434 HTTP/1.1", upstream: "http://192.168.1.50:8080/bkgtabs.php?bookingID=658108460B&show=1&toFolioID=3361434", host: "host.domain.com", referrer: "https://host.domain.com/bkgtabs.php?bookingID=658108460B&show=1&toFolioID=3361434"
2015/03/13 15:24:14 [error] 4481#0: *557663 upstream timed out (110: Connection timed out) while connecting to upstream, client: 174.53.144.4, server: host.domain.com, request: "GET /bkgtabs.php?bookingID=3105543&show=0 HTTP/1.1", upstream: "http://192.168.1.50:8080/bkgtabs.php?bookingID=3105543&show=0", host: "host.domain.com", referrer: "https://host.domain.com/bkgtabs.php?bookingID=3105543&show=0"
2015/03/13 15:24:15 [error] 4481#0: *557752 upstream timed out (110: Connection timed out) while connecting to upstream, client: 24.158.4.70, server: host.domain.com, request: "GET /bkgtabs.php?bookingID=2070569 HTTP/1.1", upstream: "http://192.168.1.50:8080/bkgtabs.php?bookingID=2070569", host: "host.domain.com", referrer: "https://host.domain.com/tapechart.php"
2015/03/13 15:24:15 [error] 4482#0: *558613 upstream timed out (110: Connection timed out) while connecting to upstream, client: 199.102.121.3, server: host.domain.com, request: "GET /rptlanding.php HTTP/1.1", upstream: "http://192.168.1.50:8080/rptlanding.php", host: "host.domain.com", referrer: "https://host.domain.com/tapechart.php"
2015/03/13 15:24:17 [error] 4482#0: *557353 upstream timed out (110: Connection timed out) while connecting to upstream, client: 174.53.144.4, server: host.domain.com, request: "GET /js/multiselect/demo/assets/prettify.js HTTP/1.1", upstream: "http://192.168.1.50:8080/js/multiselect/demo/assets/prettify.js", host: "host.domain.com", referrer: "https://host.domain.com/bkgtabs.php?bookingID=3186044"

Первоначально я обнаружил, что мне пришлось установить такое высокое значение proxy_read_timeout, потому что у нас есть 1 очень большой отчет, для которого требуется не менее 20 секунд для полной визуализации для пользователей с умеренным набором данных. Нашим пользователям с самым большим набором данных может потребоваться до 2 минут для создания отчета. Однако он запускается очень редко, обычно реже одного раза в день, и никогда не был URL-адресом в строке GET в журналах.

Четыре внутренних сервера являются идентичными серверами Apache, на всех запущенных httpd 2.2.29 и php 5.5.22, построенных из исходных текстов, и все они используют одну и ту же версию centos и обновлены. Поскольку я изначально видел попадание MaxClients в журналы, я определил следующее на каждом хосте Apache

<IfModule mpm_prefork_module>
    StartServers          10
    MinSpareServers       10
    MaxSpareServers      20
    MaxClients          200
    MaxRequestsPerChild   300
</IfModule>

Сервер nginx и серверы apache расположены в одном центре обработки данных, в одной подсети и vlan, и я не вижу ничего в error_log на стороне сервера apache, указывающего на причину тайм-аутов.

Дополнительные вещи, которые мы пытались устранить, включают

Увеличение proxy_read_timeout до 300.
Удаление настроек Gzip.
Удаление блока местоположения для кеширования css, изображений и javascript.
Включение proxy_buffering. Он отключен из-за большого отчета, позволяющего nginx начать обслуживать его как обработанный (включая индикатор прогресса javascript отчета о строительстве) вместо отображения пустой страницы в течение 20–120 секунд.
Добавление KeepAlive 8/16/32/64 в апстрим.

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

Мне бы очень хотелось разобраться в этом, но я не совсем понимаю, куда идти дальше. Подскажите пожалуйста?

Я столкнулся с чем-то вроде этого в настройке nginx <-> apache2. Apache слишком долго работал под нагрузкой из-за зависания MySQL. Чтобы узнать, сколько времени занимает apache, я изменил формат журнала на:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" %DµSEC" timed

и журнал nginx:

log_format timed_combined '$remote_addr - $remote_user [$time_local]  '

Затем стало легче увидеть, что, хотя apache завершает все запросы, доставка данных обратно в nginx происходит очень поздно (на много секунд).

Я не уверен, почему haproxy помог вашей ситуации, если только один сервер Apache не намного медленнее, чем другие. Это может произойти с идентичными машинами, когда на одной машине есть исправимые ошибки диска. Ошибки должны отображаться в системных журналах.