☰

Время отклика исходящего потока Nginx иногда очень медленное

tag-icon • tag-icon nginx load-balancing
Время отклика исходящего потока Nginx иногда очень медленное

У меня есть сервер Ubuntu, который обрабатывает большой объем трафика и множество сайтов. Иногда Nginx очень долго отвечает (иногда 20–30 секунд, а обычно запрос задерживается еще до этого). Сначала я думал, что это из-за пиков трафика в сочетании с тем, что Passenger плохо с ним справляется, но с тех пор я заменил Passenger на Puma и сбалансировал нагрузку на трафик, но проблема все еще возникает.

Nginx Amplify отправляет мне оповещения о nginx.upstream.response.timeслишком большом значении, например, 14 секунд.

Вот общий обзор установки:

  • Сервер №1 (тот, который иногда реагирует медленно) имеет блоки Nginx для более чем 300 сайтов.
  • сервер блокирует proxy_passблок сервера балансировщика нагрузки (sites.myapp.com) также на сервере №1
  • Балансировщик нагрузки разделяет трафик между этим сервером № 1 (вес 1) и сервером № 2 (вес 2) таким образом, что на сервер № 2 поступает вдвое больше трафика.
  • На обоих серверах №1 и №2 у меня есть еще один серверный блок, который получает трафик от балансировщика нагрузки и proxy_passнаправляет его на сокет Unix, используемый Puma для обслуживания экземпляра моего приложения.

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

Есть идеи, что может быть причиной этого и как отследить проблему? Потому что когда Nginx начинает очень медленно отвечать, трафик даже не перенаправляется на сервер 2.

Обратите внимание, что я знаю, что мне следует переместить все серверные блоки/SSL сайтов и балансировщик нагрузки на отдельный сервер, чтобы, по крайней мере, когда сервер 1 проходит фазу медленного ответа, трафик все равно передавался на сервер 2, но сейчас у меня есть только эти два сервера.

Пример конфигурации сайта:

server {
  server_name www.somesite.com;

  location / {
    proxy_pass                      https://sites.myapp.com;
    proxy_set_header                X-Real-IP       $remote_addr;
    proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header                Cookie $http_cookie;
    proxy_set_header                WLDOMAIN www.somesite.com;
    proxy_cookie_domain             .myapp.com .somesite.com;
    proxy_pass_request_headers      on;
    rewrite ^/(.*)$ /sites/12345/$1 break;
  }
}

Упрощенная конфигурация балансировщика нагрузки:


upstream cluster {
  ip_hash;
  server X.X.X.X:1234 weight=1; #internal ip of server #1
  server Y.Y.Y.Y:1234 weight=2; #internal ip of server #2
}

server {
  server_name sites.myapp.com;
  
  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://cluster;

    proxy_next_upstream error timeout invalid_header http_429 http_500 http_502 http_503 http_504;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }
}

Упрощенная конфигурация восходящего потока:

upstream puma {
  server unix:///var/www/myapp/shared/sockets/puma.sock;
}

server {
  listen 1234;

  root /var/www/myapp/public;

  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://puma;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }

}

Обратите внимание, что эта проблема уже возникала, когда настройка заключалась в том, что различные серверы сайтов просто блокировали proxy_passтрафик на восходящий поток вместо того, чтобы между ними был балансировщик нагрузки, а приложение обслуживалось Passenger вместо Puma.

Если это имеет значение, приложение написано на Ruby on Rails.

решение1

Итак, после включения отладочного вывода в Nginx выяснилось, что проблема была в модуле Nchan в nginx-extrasпакете Phusion Passenger. Он глючный и время от времени зависал. После того, как я избавился от Passenger (заменил его на Puma) и заменил nginx-extrasна , nginxэтой проблемы больше не возникало.

Связанный контент