主页 / server / 问题 / 1002021
Accepted
Janning
Asked: 2020-02-07 02:52:44 +0800 CST

Nginx 在 Debian10 而不是 Debian9 的高负载下失败

  • 772

nginx 从来没有出现过任何问题。我们在很多 Spring Boot 应用服务器前面使用 5 台 Nginx 服务器作为负载均衡器。

我们多年来一直在 debian 9 上使用默认的 nginx 包 1.10.3 运行它们。现在我们将三个负载均衡器切换到带有 nginx 1.14.2 的 debian 10。首先，一切顺利。然后，在高负载下，我们遇到了一些问题。它开始于

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 秒，然后消失。

在内核日志中，我们有时会出现：Feb 1 17:11:04 kt104 kernel: [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 运行良好，连接到任何上游服务器都没有问题。letencrypt 和 SSL_write 的问题向我发出了 nginx 或 TCP 或其他问题的信号。我真的不知道如何调试这种情况。但我们可以可靠地重现它，大多数时候我们在 debian10 服务器上遇到高负载并且在 debian 9 上从未见过它。

然后我在 debian10 上安装了稳定版 nginx 1.16 看看这是否是 nginx 中已经修复的 bug：

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 对服务器进行负载测试，但我们无法重现该问题。

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

load-balancing nginx tcp linux-networking debian-buster

1 个回答

  1. Best Answer

    accept_mutex 在默认值中从 on 更改为 off。将其重新设置为“on”，Nginx 再次以每秒 10k 个请求的速度愉快地运行。我想这是 multi_accept 和 accept_mutex 的组合导致了我的麻烦。

    顺便说一下，我们不推荐这些设置，我们通过重用端口等更改为更现代的设置。请按照 Nginx 博客上的指南进行自己的设置。Nginx 很棒。

    • 0

相关问题