Trong 3 tuần qua chúng tôi đã kiểm tra Nginx là cân bằng tải. Hiện tại, chúng tôi không thể xử lý hơn 1000 kết nối hoạt động req/sec và 18K. Khi chúng tôi nhận được các con số trên, Nginx bắt đầu treo và trả về mã hết thời gian chờ. Cách duy nhất để nhận phản hồi là giảm số lượng kết nối đáng kể.Nginx Cân bằng tải lưu lượng cao
Tôi phải lưu ý rằng các máy chủ của tôi có thể và xử lý lưu lượng truy cập này hàng ngày và hiện tại chúng tôi sử dụng cân bằng DNS vòng rubin đơn giản.
Chúng tôi đang sử dụng một máy chủ chuyên dụng với HW sau: CPU
- Intel Xeon E5620
- 16GB RAM
- 2T SATA HDD
- 1Gb/s kết nối
- Hệ điều hành: CentOS 5.8
Chúng tôi cần tải cân bằng 7 máy chủ quay lại chạy Tomca t6 và xử lý hơn 2000 lần/giây vào thời gian nhìn trộm, xử lý các yêu cầu HTTP và HTTPS.
Trong khi chạy mức tiêu thụ cpu của Nginx là khoảng 15% và RAM được sử dụng là khoảng 100MB.
Câu hỏi của tôi là:
- Có bất kỳ một cố gắng để cân bằng tải loại này lưu lượng sử dụng nginx?
- Bạn có nghĩ nginx có thể xử lý lưu lượng truy cập như vậy không?
- Bạn có biết bất kỳ điều gì có thể gây ra sự cố không?
- Tôi có thiếu gì đó trên cấu hình của mình không?
Dưới đây là file cấu hình của tôi:
nginx.conf:
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;
}
servers.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;
}
}
sysctl.conf:
# 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
Bất kỳ trợ giúp, hướng dẫn, ý tưởng nào sẽ được đánh giá cao.
Bạn có thực hiện những thay đổi này cho cả máy chủ cân bằng tải và máy chủ phụ trợ hay cái kia hay không? –
Chi tiết xin vui lòng. Mỗi máy chủ nginx có được những điều chỉnh này, nếu ở mức âm lượng cao. – chrislovecnm
Tôi giả sử nếu tôi có các máy chủ cân bằng tải cơ sở dữ liệu (pgpool, không phải máy chủ nginx), nó cũng nên có các cài đặt xem xét kết nối cơ sở dữ liệu sẽ được sử dụng cho mọi yêu cầu. Ngược lại kết nối betwen pgpool và postgres sẽ không giả định các thiết lập này bởi vì có một kết nối liên tục được thiết lập giữa pgpool và postgres, do đó không phải là một kết nối tcp mới establsihed cho mọi yêu cầu cơ sở dữ liệu. Điều này có đúng không? –