☰

Nginx 在 Debian10 高负载下失败，但在 Debian9 上不会失败

tag-icon • tag-icon nginx linux-networking load-balancing tcp debian-buster
Nginx 在 Debian10 高负载下失败，但在 Debian9 上不会失败

我们从未遇到过任何与 nginx 相关的问题。我们使用 5 个 nginx 服务器作为许多 spring boot 应用服务器前面的负载均衡器。

多年来，我们一直在 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 秒，然后消失。

在内核日志中，我们有时会看到：2 月 1 日 17:11:04 kt104 内核：[1033003.285044] TCP：request_sock_TCP：端口 443 上可能发生 SYN 泛洪。正在发送 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 上从未见过这种情况。

然后我在debian10上安装了稳定版本nginx 1.16，看看这是否是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: ...

但它没有帮助。

这似乎是与网络相关的问题。但我们在应用服务器上没有遇到过这种情况。但由于负载均衡器/nginx 机器必须处理外部和内部流量，因此负载当然较低。

调试起来非常困难，因为它只发生在高负载下。我们尝试使用 ab 对服务器进行负载测试，但无法重现该问题。

有人可以帮助我并提示我如何开始进一步调试这种情况吗？

答案1

accept_mutex 的默认值从 on 变为 off。将其重新设置为“on”后，Nginx 又可以每秒处理 10k 个请求了。我猜是 multi_accept 和 accept_mutex 的组合导致了我的麻烦。

顺便说一下，这些设置并不推荐，我们将其更改为使用 repeatport 等更现代的设置。请按照 Nginx 博客上的指南进行自己的设置。Nginx 很棒。

相关内容