Периодическое падение пропускной способности обратного прокси nginx, что это может быть?

Я тестирую под нагрузкой ящик t2.micro, в котором запущены nginx и postgrest в контейнерах докеров. Nginx действует как прокси перед postgrest. Если я перейду прямо к восходящему потоку (postgrest), я получу хороший график (пики около 900 / rps) Если я перейду через nginx, я получу такой график

введите описание изображения здесь

ЦП не перегружен (всего около 50%)

Это используемый конфиг nginx. Все, что комментируется, было опробовано безрезультатно. Я также играл со значениями worker_connections и другими подобными вещами. Чем может быть вызвано это периодическое падение?

    worker_processes  2;

    #worker_rlimit_nofile              2048;
    events {
        #  multi_accept                    on;
        worker_connections              1024;
        use                             epoll;
    }
    http {
        resolver 127.0.0.11 ipv6=off;
        include mime.types;
        #tcp_nodelay                     off;
        #tcp_nopush                      on;
        upstream postgrest {
            server postgrest:3000;
            keepalive 64;
        }
        server {
            listen       80;
            server_name  localhost;
            charset utf-8;

            location /rest/ {
                default_type  application/json;
                #proxy_buffering off;
                proxy_pass http://postgrest/; # Reverse proxy to your PostgREST
            }
        }
    }

person Ruslan Talpa    schedule 31.10.2016    source источник
comment
График задержки также интересен, он составляет примерно 10 мс до первого падения, затем перескакивает примерно до 1 с и в основном остается там, немного отражая график пропускной способности, но не возвращается к 10 мс. Также ошибок нет, каждый запрос 200 ОК   -  person Ruslan Talpa    schedule 31.10.2016
comment
новая разработка. Если я заставлю контейнеры использовать хост-сеть, производительность будет хуже, падение упадет почти до нуля. Кто-нибудь знает, как сравнить сетевые настройки для режима хоста и моста, чтобы увидеть, какие параметры отличаются?   -  person Ruslan Talpa    schedule 31.10.2016


Ответы (1)


Виновником были (по умолчанию) настройки ядра tcp. При прохождении через прокси-сервер nginx система использовала все локальные порты, затем все остановилось (падение) до тех пор, пока старые соединения TCP не могут быть полностью закрыты (они были в time_wait в течение 60 секунд). Настройка этих параметров устранила проблему.

#tcp settings
net.core.somaxconn
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_tw_reuse
net.ipv4.ip_local_port_range

#nginx configs
proxy_set_header  Connection "";
proxy_http_version 1.1;

В статье ниже более подробно рассказывается о том, что именно происходило, и о параметрах для настройки.

https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads

person Ruslan Talpa    schedule 01.11.2016
comment
Ссылка WBM на статью, которая больше не существует https://web.archive.org/web/20170215035502/https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads - person Ruslan Talpa; 06.09.2020
comment
чтобы проверить, действительно ли это ваша проблема, запустите netstat -tan | awk '{print $6}' | sort | uniq -c и посмотрите, много ли у вас подключений TIME_WAIT - person Ruslan Talpa; 06.09.2020