Да, меняли. У нас есть настройка, которая меняет keepalive_requests в зависимости от характера трафика. Для трафика браузер-нджинкс это 100, для трафика сервер-нджинкс 214748364:

map $ssp_name $needs_keepalive {
    client no;
    default yes;
  }

  map $needs_keepalive $keepalive_requests {
    no 100;
    default 214748364;

}


Олег Паничев | Инженер по эксплуатации | +79626801636 | panic...@segmento.ru <mailto:panic...@segmento.ru> | Санкт-Петербург, 18 линия В.О. 29 | segmento.ru <http://segmento.ru/?utm_source=segmento&utm_medium=cps&utm_campaign=email_sign> | Совместный проект Сбербанк и АФК Система <https://www.interfax.ru/business/636949>
Segmento logo
On 29.03.2019 10:42, Илья Шипицин wrote:
настройку keepalive_requests меняли ? или дефолт ?

пт, 29 мар. 2019 г. в 12:37, Panichev Oleg <panic...@segmento.ru <mailto:panic...@segmento.ru>>:

    Привет!


    Проблема — высокое число timewait коннекшнов между nginx-proxy и
    бэкендами (до 30-40к), уровень трафика — десятки тысяч запросов в
    секунду извне, в основном короткие сессии на несколько запросов.
    Стек Centos 6 настроен на переиспользование tw sockets -
    tw_reuse=1, tcp_fin_timeout низкий (2с).



    nginx/1.14.0, ~ 25 fastcgi backends

    upstream all {
    hash $shard_key consistent;
    server server10.local:9988 max_fails=0 fail_timeout=1s weight=100;
    server server11.local:9988 max_fails=0 fail_timeout=1s weight=100;
    ..
    ..
    ..
    server server33.local:9988 max_fails=0 fail_timeout=1s weight=100;
    server server34.local:9988 max_fails=0 fail_timeout=1s weight=100;
    keepalive 100;
    }

      fastcgi_pass all;
      fastcgi_keep_conn on;
      fastcgi_next_upstream off;
      fastcgi_buffers 16 16k;
      fastcgi_buffer_size 32k;
      fastcgi_connect_timeout 20ms;
      fastcgi_read_timeout 75ms;
      fastcgi_intercept_errors on;
      error_page 500 501 502 503 504 = $failover;


    Вероятно, высокое количество TW соединений вызвано
    поведением-настройкой Nginx, а именно необходимостью слать
    заглушку при достижении read timeout до апстрима (75мс), в этом
    случае Nginx закрывает соединение с апстримом принудительно (TCP
    RST), шлет фэиловер респонс клиенту и переоткрывает его снова. Мы
    видим около 30-35 RST пакетов в секунду в направлении бэкендов от
    Nginx, что соотвествует числу фейловеров в секунду по тому же
    апстриму согласно access/error.log.

    Вопрос — верны ли рассуждения о причинах высокого числа TW
    соединений между прокси и бэкендами и как их можно уменьшить
    средствами нжинкс, если это возможно?

    Спасибо

    --

    С уважением, Олег

    _______________________________________________
    nginx-ru mailing list
    nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
    http://mailman.nginx.org/mailman/listinfo/nginx-ru


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Ответить