首先,来个简单的nginx配置:
user root;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
error_log logs/error.log debug;
events {
worker_connections 10240;
use epoll;
}
worker_rlimit_nofile 30000;
http {
include mime.types;
default_type application/octet-stream;
log_format session '[$time_local] $remote_addr $request_method $uri '
'$upstream_cache_status $status '
'"$http_user_agent" $bytes_sent $request_time $body_bytes_sent $content_length';
access_log logs/access.log session;
sendfile on;
keepalive_timeout 65s;
client_max_body_size 2m;
client_body_buffer_size 512k;
upstream upsream_example{
keepalive 64;
server server1 max_fails=0;
}
server {
listen 80;
server_name starStreamer;
location / {
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_pass http://upstream_example$request_uri;
}
}
nginx通过proxy_pass回源时,可以通过upstream配置长连接,达到减少握手时间的目的。但是有的时候,当访问量不大得情况下,会发现,这个长连接并不是像我们想的那样,按照我们设置的keepalive_timeout超时,而是达到60s,就time_wait。不知道大家有没有碰到过。
这个问题,首先可能是上游服务没有开启keepalive功能。其次就是我们配置的问题了。keepalive缓存队列,是每一个nginx进程一个,而我们默认开启多进程(worker_processes 8),所以相当于开启了server1对应的ip个数*进程数个缓存。而keepalive_timeout的配置,其实是在upstream里面,默认为60s。所以如果轮训一遍缓存队列的时间大于60s,则缓存就会失效。
本文探讨了在nginx配置中遇到回源时Keepalive超时问题,尽管设置了keepalive_timeout为65s,但实际操作中发现连接在60s后进入time_wait状态。可能的原因包括上游服务未启用keepalive功能以及nginx配置中的缓存队列管理。每个nginx进程拥有一个keepalive缓存队列,多进程可能导致队列数量过多,若轮询一次缓存所需时间超过60s,将导致缓存失效。解决方案在于检查上游服务配置和调整nginx的进程与缓存策略。

4964

被折叠的 条评论
为什么被折叠?



