Nginx не работает при высокой нагрузке с Debian 10, а не с Debian 9

У нас никогда не было проблем с nginx. Мы используем 5 серверов nginx в качестве балансировщиков нагрузки перед многими серверами приложений с весенней загрузкой.

Мы годами запускали их на debian 9 с пакетом nginx по умолчанию 1.10.3. Теперь мы переключили три наших балансировщика нагрузки на debian 10 с помощью nginx 1.14.2. Сначала все идет гладко. Затем при высокой нагрузке возникли проблемы. Это начинается с

2020/02/01 17:10:55 [crit] 5901#5901: *3325390 SSL_write() failed while sending to client, client: ...
2020/02/01 17:10:55 [crit] 5901#5901: *3306981 SSL_write() failed while sending to client, client: ...

В промежутках мы получаем много

2020/02/01 17:11:04 [error] 5902#5902: *3318748 upstream timed out (110: Connection timed out) while connecting to upstream, ...
2020/02/01 17:11:04 [crit] 5902#5902: *3305656 SSL_write() failed while sending response to client, client: ...
2020/02/01 17:11:30 [error] 5911#5911: unexpected response for ocsp.int-x3.letsencrypt.org

Это заканчивается

2020/02/01 17:11:33 [error] 5952#5952: unexpected response for ocsp.int-x3.letsencrypt.org

Проблема действительно выходит только на 30-120 секунд при высокой нагрузке и затем исчезает.

В журнале ядра мы иногда встречаем: 1 февраля 17:11:04 kt104 kernel: [1033003.285044] TCP: request_sock_TCP: Возможный SYN-флуд на порт 443. Отправка файлов cookie. Проверьте счетчики SNMP.

Но в других случаях мы не видим сообщений kernel.log

На обоих серверах debian 9 и debian 10 мы использовали идентичную настройку и имели некоторую настройку TCP:

# Kernel tuning settings
# https://www.nginx.com/blog/tuning-nginx/
net.core.rmem_max=26214400
net.core.wmem_max=26214400
net.ipv4.tcp_rmem=4096 524288 26214400
net.ipv4.tcp_wmem=4096 524288 26214400
net.core.somaxconn=1000
net.core.netdev_max_backlog=5000
net.ipv4.tcp_max_syn_backlog=10000
net.ipv4.ip_local_port_range=16000 61000
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.tcp_fin_timeout=30
net.core.optmem_max=20480

Конфигурация nginx точно такая же, поэтому я просто показываю основной файл:

user www-data;
worker_processes auto;
worker_rlimit_nofile 50000;
pid /run/nginx.pid;

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

http {
    root /var/www/loadbalancer;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;
    server_tokens off;
    client_max_body_size 5m;
    client_header_timeout 20s; # default 60s
    client_body_timeout 20s; # default 60s
    send_timeout 20s; # default 60s

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:100m;
    ssl_buffer_size 4k;
    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

    ssl_session_tickets on;
    ssl_session_ticket_key /etc/nginx/ssl_session_ticket.key;
    ssl_session_ticket_key /etc/nginx/ssl_session_ticket_old.key;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/rapidssl/intermediate-root.pem;

    resolver 8.8.8.8;

    log_format custom '$host $server_port $request_time $upstream_response_time $remote_addr "$ssl_session_reused" $upstream_addr $time_iso8601 "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent";

    access_log /var/log/nginx/access.log custom;
    error_log /var/log/nginx/error.log;

    proxy_set_header Host $http_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-Proto $scheme;
proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=imagecache:10m     inactive=7d use_temp_path=off;
    proxy_connect_timeout 10s;
    proxy_read_timeout 20s;
    proxy_send_timeout 20s;
    proxy_next_upstream off;

    map $http_user_agent $outdated {
    default 0;
    "~MSIE [1-6]\." 1;
    "~Mozilla.*Firefox/[1-9]\." 1;
    "~Opera.*Version/[0-9]\." 1;
    "~Chrome/[0-9]\." 1;
  }

  include sites/*.conf;
}

Тайм-аут восходящего потока сигнализирует о некоторых проблемах с нашими java-машинами. Но в то же время debian9 nginx / loadbalancer работает нормально и не имеет проблем с подключением к любому из вышестоящих серверов. И проблемы с letsencrypt и SSL_write сигнализируют мне о некоторых проблемах с nginx, TCP или чем-то еще. Я действительно не знаю, как отладить эту ситуацию. Но мы можем надежно воспроизвести его в большинстве случаев, когда мы сталкиваемся с высокой нагрузкой на серверы debian10 и никогда не видели этого на debian 9.

Затем я установил стабильную версию nginx 1.16 на debian10, чтобы проверить, не является ли это ошибкой в ​​nginx, которая уже исправлена:

nginx version: nginx/1.16.1
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1c 28 May 2019 (running with OpenSSL 1.1.1d 10 Sep 2019)
TLS SNI support enabled
configure arguments: ...

Но это не помогло.

Похоже, проблема связана с сетью. Но мы не используем его на серверах приложений. Но нагрузка, конечно, ниже, поскольку машина loadbalancer / nginx должна обрабатывать внешний и внутренний трафик.

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

Может ли кто-нибудь помочь мне и подсказать, как начать дальнейшую отладку этой ситуации?