web-dev-qa-db-ja.com

NginxはDebian 9ではなくDebian 10で高負荷時に失敗します

Nginxで問題が発生することはありませんでした。 5つのnginxサーバーを、多くのSpring Bootアプリケーションサーバーの前のロードバランサーとして使用します。

私たちは何年もの間、デフォルトのnginxパッケージ1.10.3でdebian 9上でそれらを実行していました。次に、nginx 1.14.2を使用して、3つのロードバランサーを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秒間しか発生せず、その後消えます。

カーネルログには、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を使用してサーバーの負荷テストを実行しましたが、問題を再現できませんでした。

誰かが私を助けて、この状況のさらなるデバッグを開始する方法のヒントを教えてもらえますか？

nginxlinux-networkingload-balancingtcpdebian-buster
2
Janning

aceept_mutexがデフォルト値でオンからオフに変更されました。これを「オン」に戻すと、nginxは1秒あたり10kリクエストで再び実行されます。私の問題を引き起こしたのはmulti_acceptとacceot_mutexの組み合わせだと思います。

これらの設定は推奨されず、reuseportなどを使用してよりモダンな設定に変更しました。独自の設定については、nginxブログのガイドラインに従ってください。 Nginxは素晴らしいです。

0
Janning