Почему Nginx перестал отправлять запросы upstream серверу после огромной нагрузки?

Question

[Станислав Гордиенко]

Привет,

На проекте используется Nginx как распределитель нагрузки. Вот упрощенная конфигурация:

upstream ima {
    server serverA:3000;
    server serverA:3000 backup;
    server serverA:3000 backup;
    server serverA:3000 backup;
}

server {
    server_name localhost;
    gzip on;

    sendfile on;

    gzip_http_version 1.0;
    gzip_proxied      any;
    gzip_min_length   500;
    gzip_disable      "MSIE [1-6]\.";
    gzip_types        text/plain text/xml text/css
                      text/comma-separated-values
                      text/javascript
                      application/x-javascript
                      application/json
                      application/atom+xml;

    proxy_connect_timeout       10;
    proxy_send_timeout          12;
    proxy_read_timeout          14;

    send_timeout                600;
    client_body_timeout         600;
    client_header_timeout       600;
    keepalive_timeout           600;

    client_max_body_size 50M;
    client_body_buffer_size 20M;

    access_log /home/nginx-access.log;
    error_log /home/nginx-error.log warn;

    location /checksum {
        log_format upstream_logging '$remote_addr - $remote_user [$time_local] '
                                    '"$request" $status $body_bytes_sent '
                                    '"$http_referer" "$http_user_agent" "$gzip_ratio"'
                                    '"$upstream_connect_time" "$upstream_header_time" "$upstream_response_time" "$request_time"';

        access_log /home/upstreams.log upstream_logging;

        proxy_pass http://ima;
        proxy_redirect     off;
        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_set_header   X-Forwarded-Host $server_name;
        proxy_next_upstream error timeout;
        proxy_intercept_errors off;
    }
  }

У нас serverA - это ELB, который ссылается на 16 инстансов сервиса в Kubernetes.

В upstream используется один и тот же сервер serverA пять раз. Это сделали до меня как обходной путь, если первый процессинг выпадет с ошибкой или Pod сервиса не доступен, тогда Nginx переключится на следующий бэкап сервер serverA и снова запустит процесс. Эта затычка работает и успешно.

Но, на выходных запускали нагрузочный тест, слали большой объем данных и запросов одновременно, в понедельник заметили много 499 ошибок в логах Nginx (“GET /result/final/id-goes-here HTTP/1.1” 499 0 “-“ “Our Client Name” “-“ “-“ “-“ “-“ “64.587”), а когда начали дергать этот сервис вручную, то заметили, что он отваливается в ручную по таймауту, возвращая Could not get any response страницу в Postman.

Что интересно, это только Nginx тупил возвращать результат, когда запускали запрос напрямую на upstream сервер (ELB), то он возвращал результат. Предположили, что во время большой нагрузки, Nginx пометил все сервера (одинаковые) в upstream как down, и поэтому ничего не возвращал, подвисал на запросе и отваливался на таймауте. Вопросов появилось больше чем ответов.

Кто-то сталкивался с подобным в своей практике? Как решали? Возможно, есть подобные случаи?

Спасибо.

Comments

[Lynn «Кофеман»]

В error.log то посмотрели?

[Станислав Гордиенко]

Алексей Тен, везде смотрел. Access, Error, все это отправляется в Sumo Logic. Postman отваливался через 1 минуту, когда не мог получить ответ на запрос. Когда Nginx был перегрузен, проблема решилась. Сегодня пытался воссоздать ситуацию идентичной нагрузкой, ничего не вышло. Мистери баг остался подарком к 1 Апреля для меня.