過去3週間、負荷分散としてNginxをテストしてきました。現在、1000 req/secおよび18Kを超えるアクティブな接続の処理に成功していません。上記の数値に達すると、Nginxはハングし始め、タイムアウトコードを返します。応答を得る唯一の方法は、接続の数を劇的に減らすことです。
私のサーバーはこの量のトラフィックを毎日処理でき、実際に処理していることに注意する必要があります。現在、単純なラウンドロビンDNSバランシングを使用しています。
次のハードウェアを備えた専用サーバーを使用しています。
Tomcat6を実行し、ピーク時に2000 req/sec以上を処理し、HTTPおよびHTTPS要求を処理する7台のバックサーバーの負荷を分散する必要があります。
Nginxの実行中のCPU消費量は約15%で、使用量はRAMは約100MBです。
私の質問は次のとおりです。
以下は私の設定ファイルです:
user nginx;
worker_processes 10;
worker_rlimit_nofile 200000;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 10000;
use epoll;
multi_accept on;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#access_log /var/log/nginx/access.log main;
access_log off;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
reset_timedout_connection on;
gzip on;
gzip_comp_level 1;
include /etc/nginx/conf.d/*.conf;
}
#Set the upstream (servers to load balance)
#HTTP stream
upstream adsbar {
least_conn;
server xx.xx.xx.34 max_fails=2 fail_timeout=15s;
server xx.xx.xx.36 max_fails=2 fail_timeout=15s;
server xx.xx.xx.37 max_fails=2 fail_timeout=15s;
server xx.xx.xx.39 max_fails=2 fail_timeout=15s;
server xx.xx.xx.40 max_fails=2 fail_timeout=15s;
server xx.xx.xx.42 max_fails=2 fail_timeout=15s;
server xx.xx.xx.43 max_fails=2 fail_timeout=15s;
}
#HTTPS stream
upstream adsbar-ssl {
least_conn;
server xx.xx.xx.34:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.36:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.37:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.39:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.40:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.42:443 max_fails=2 fail_timeout=15s;
server xx.xx.xx.43:443 max_fails=2 fail_timeout=15s;
}
#HTTP
server {
listen xxx.xxx.xxx.xxx:8080;
server_name www.mycompany.com;
location / {
proxy_set_header Host $Host;
# So the original HTTP Host header is preserved
proxy_set_header X-Real-IP $remote_addr;
# The IP address of the client (which might be a proxy itself)
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://adsbar;
}
}
#HTTPS
server {
listen xxx.xxx.xxx.xxx:8443;
server_name www.mycompany.com;
ssl on;
ssl_certificate /etc/pki/tls/certs/mycompany.crt;
# Path to an SSL certificate;
ssl_certificate_key /etc/pki/tls/private/mycompany.key;
# Path to the key for the SSL certificate;
location / {
proxy_set_header Host $Host;
# So the original HTTP Host header is preserved
proxy_set_header X-Real-IP $remote_addr;
# The IP address of the client (which might be a proxy itself)
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://adsbar-ssl;
}
}
server {
listen xxx.xxx.xxx.xxx:61709;
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
}
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values,
0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 1
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
fs.file-max = 120000
net.ipv4.ip_conntrack_max = 131072
net.ipv4.tcp_max_syn_backlog = 8196
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_keepalive_time = 3600
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824
net.core.netdev_max_backlog = 2500
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
どんな助け、ガイダンス、アイデアも高く評価されます。
ここにいくつかの良い参考文献があります:
http://dak1n1.com/blog/12-nginx-performance-tuning
サーバー障害: https://serverfault.com/questions/221292/tips-for-maximizing-nginx-requests-sec
Dak1n1リンクからの非常によく文書化された構成:
# This number should be, at maximum, the number of CPU cores on your system.
# (since nginx doesn't benefit from more than one worker per CPU.)
worker_processes 24;
# Number of file descriptors used for Nginx. This is set in the OS with 'ulimit -n 200000'
# or using /etc/security/limits.conf
worker_rlimit_nofile 200000;
# only log critical errors
error_log /var/log/nginx/error.log crit
# Determines how many clients will be served by each worker process.
# (Max clients = worker_connections * worker_processes)
# "Max clients" is also limited by the number of socket connections available on the system (~64k)
worker_connections 4000;
# essential for linux, optmized to serve many clients with each thread
use epoll;
# Accept as many connections as possible, after nginx gets notification about a new connection.
# May flood worker_connections, if that option is set too low.
multi_accept on;
# Caches information about open FDs, freqently accessed files.
# Changing this setting, in my environment, brought performance up from 560k req/sec, to 904k req/sec.
# I recommend using some varient of these options, though not the specific values listed below.
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
# Buffer log writes to speed up IO, or disable them altogether
#access_log /var/log/nginx/access.log main buffer=16k;
access_log off;
# Sendfile copies data between one FD and other from within the kernel.
# More efficient than read() + write(), since the requires transferring data to and from the user space.
sendfile on;
# Tcp_nopush causes nginx to attempt to send its HTTP response head in one packet,
# instead of using partial frames. This is useful for prepending headers before calling sendfile,
# or for throughput optimization.
tcp_nopush on;
# don't buffer data-sends (disable Nagle algorithm). Good for sending frequent small bursts of data in real time.
tcp_nodelay on;
# Timeout for keep-alive connections. Server will close connections after this time.
keepalive_timeout 30;
# Number of requests a client can make over the keep-alive connection. This is set high for testing.
keepalive_requests 100000;
# allow the server to close the connection after a client stops responding. Frees up socket-associated memory.
reset_timedout_connection on;
# send the client a "request timed out" if the body is not loaded by this time. Default 60.
client_body_timeout 10;
# If the client stops reading data, free up the stale client connection after this much time. Default 60.
send_timeout 2;
# Compression. Reduces the amount of data that needs to be transferred over the network
gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";
また、sysctl.confのLinuxシステムチューニングに関する詳細情報:
# Increase system IP port limits to allow for more connections
net.ipv4.ip_local_port_range = 2000 65000
net.ipv4.tcp_window_scaling = 1
# number of packets to keep in backlog before the kernel starts dropping them
net.ipv4.tcp_max_syn_backlog = 3240000
# increase socket listen backlog
net.core.somaxconn = 3240000
net.ipv4.tcp_max_tw_buckets = 1440000
# Increase TCP buffer sizes
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = cubic
最小接続アルゴリズムの使用には問題があることがわかりました。に切り替えました
hash $remote_addr consistent;
そして、サービスがはるかに迅速であることがわかりました。
nginxは間違いなく1000req/s以上を処理できるはずです(2つのコアの1つ半を使用してjmeterを備えた安価なラップトップで遊んでいるとnginxで約2800 req/sを取得します)
私が理解しているように、現在のLinuxカーネルで最適なオプションであるepollを使用しています。
Acces_logをオフにしているので、ディスクIOもボトルネックになることはありません(注:access_logをバッファモードに設定して、後でのみ書き込む大きなバッファを使用することもできます)各xkb。これにより、ディスクioが絶えずハンマーで打たれるのを防ぎますが、分析のためにログを保持します)
私の理解では、nginxのパフォーマンスを最大化するには、通常、worker_processesの数をcore/CPUの数に等しく設定し、worker_connectionsの数を増やして、より多くの同時接続を許可します(開いているファイルの数と制限)。ただし、上記で投稿したデータには、それぞれ10k接続が許可された10個のワーカープロセスを備えたクアッドコアCPUがあります。したがって、nginx側では、次のようなことを試してみます。
worker_processes 4;
worker_rlimit_nofile 999999;
events {
worker_connections 32768;
use epoll;
multi_accept on;
}
カーネル側では、tcpの読み取りバッファーと書き込みバッファーを異なる方法で調整します。最小値を小さくし、デフォルト値を小さくし、最大値を大きくします。
エフェメラルポートの範囲はすでに拡大しています。
開いているソケットがたくさんあるので、開いているファイルの数をもっと制限します。
これにより、/ etc /sysctl.confに追加/変更する次の行が表示されます
net.ipv4.tcp_rmem = 4096 4096 25165824
net.ipv4.tcp_wmem = 4096 4096 25165824
fs.file-max=999999
お役に立てば幸いです。