Как решить nginx - нет прямых апстримов при подключении к апстримному клиенту?

В настоящее время я выполняю нагрузочное тестирование с использованием JMeter в нашей системе сборки на Grails 3, работающей на tomcat. После отправки 20 тыс. Запросов в секунду в журнале ошибок nginx я обнаружил, что при подключении к клиенту в восходящем потоке не было никаких активных восходящих потоков. Наше приложение является мультитенантной базой, поэтому мне нужно выполнять высокие нагрузки. Вот моя конфигурация nginx.

worker_processes  16;
worker_rlimit_nofile 262144;
error_log  /var/log/nginx/error.log;

events {
    worker_connections  24576;
    use epoll;
    multi_accept on;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  600;
    keepalive_requests 100000;
    access_log off;
    server_names_hash_max_size  4096;
    underscores_in_headers  on;
    client_max_body_size 8192m;
    log_format vhost '$remote_addr - $remote_user [$time_local] $status "$request" $body_bytes_sent "$http_referer" "$http_user_agent" "http_x_forwarded_for"';

    proxy_connect_timeout      120;
    proxy_send_timeout         120;
    proxy_read_timeout         120;


    gzip  on;
    gzip_types text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/json application/xml+rss image application/javascript;
    gzip_min_length  1000;
    gzip_static on;
    gzip_vary on;
    gzip_buffers 16 8k;
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_disable "msie6";

    proxy_intercept_errors on;
    recursive_error_pages on;

    ssl_prefer_server_ciphers On;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA;
    include /etc/nginx/conf.d/*.conf;
}

Как мне настроить высокую параллельную нагрузку?

Источник

2 ответа

Для меня проблема была с моей записью proxy_pass. я имел

location / {
        ...
        proxy_pass    http://localhost:5001;
    }

Это заставило восходящий запрос использовать IP-адрес локального хоста IP4 или IP-адрес локального хоста IP6, но время от времени он использовал бы DNS локального хоста без номера порта, что приводило к ошибке восходящего потока, как видно из журналов ниже.

[27/Sep/2018:16:23:37 +0100] <request IP> - - - <requested URI>  to: [::1]:5001: GET /api/hc response_status 200
[27/Sep/2018:16:24:37 +0100] <request IP> - - - <requested URI>  to: 127.0.0.1:5001: GET /api/hc response_status 200
[27/Sep/2018:16:25:38 +0100] <request IP> - - - <requested URI>  to: localhost: GET /api/hc response_status 502
[27/Sep/2018:16:26:37 +0100] <request IP> - - - <requested URI>  to: 127.0.0.1:5001: GET /api/hc response_status 200
[27/Sep/2018:16:27:37 +0100] <request IP> - - - <requested URI>  to: [::1]:5001: GET /api/hc response_status 200

Как видите, я получаю 502 статуса для "localhost:"

Изменение моего proxy_pass на 127.0.0.1:5001 означает, что все запросы теперь используют IP4 с портом.

Этот ответ Stackru оказал большую помощь в поиске проблемы, так как подробно описывал изменение формата журнала, чтобы можно было увидеть проблему.

Источник

Я видел такое поведение много раз во время перф. тесты.

При высокой рабочей нагрузке производительность вашего вышестоящего сервера (-ов) может быть недостаточной, и вышестоящий модуль может пометить вышестоящий сервер (-ы) как недоступный.

Соответствующие параметры (директива сервера):

max_fails=number

устанавливает количество неудачных попыток установить связь с сервером, которые должны произойти в течение времени, заданного параметром fail_timeout параметр, чтобы считать сервер недоступным в течение времени, также установленного fail_timeout параметр. По умолчанию количество неудачных попыток установлено равным 1. Нулевое значение отключает учет попыток. То, что считается неудачной попыткой, определяется proxy_next_upstreamДирективы.

fail_timeout=time

наборы:

  • время, в течение которого указанное число неудачных попыток установить связь с сервером должно считаться недоступным;

  • и период времени, в течение которого сервер будет считаться недоступным.

По умолчанию параметр установлен на 10 секунд.

Источник
Другие вопросы по тегам