各位好,在生产环境中遇到问题,向大家寻求帮助
先给出想通过本次邮件解决的问题:
1. 在日志记录中,存在较多$request_time 和 $upstream_response_time 执行时间很久的记录,可能是什么原因?与我的配置参数设置或部署结构是否有关?
2. $upstream_response_time 格式会变成2部分 xxxx, xxxx ,可能是什么原因?被拆分的字段代表什么含义?
3. 代理端和处理端配置中的 worker_processes 个数以及 worker_connections个数的目前的设置是否是产生较长执行时间的原因?结合给出的物理机信息,该如何设置才合理?
4. 对于worker_processes设定,cpu绑定,结合物理机信息,到底应该怎么绑定(参照core个数还是逻辑cpu个数)
问题有点多,确实在应用过程中遇到难题,希望大家抽点时间,能帮忙我分析一下,非常感谢!
基于上述问题的一些线索,帮助理解:
在使用nginx完成业务功能时,我们希望了解nginx在接收请求到处理完毕的访问时间($request_time),以及当代理缓存不存在时,访问上游服务器的完整响应时间($upstream_response_time)
我们自定义了如下日志格式:
#各项之间使用 \t 分隔
log_format custom '[$time_local] "$request" $status $bytes_sent $request_time $upstream_response_time';
通过日志分析,我发现存在如下几类日志
#访问上游服务器后的正常日志
[21/Jun/2013:00:00:09 +0800] "GET /carnews/2013/5/12/tp_20130512232510597213.jpg HTTP/1.1" 200 23750 0.134 0.134
[20/Jun/2013:23:30:24 +0800] "GET /carnews/2013/6/9/u_201306091538449644661.jpg HTTP/1.1" 200 21014 2.422 2.385
这部分能理解,上游服务器执行的时间 <= $request_time
#命中代理缓存,快速返回的日志
[21/Jun/2013:01:09:24 +0800] "GET /carnews/spec/4469/c_201111241509118403655.jpg HTTP/1.1" 200 20759 0.000 -
这部分能理解,由于命中缓存,并没有访问上游服务器,所以$upstream_response_time 为 -
且$request_time比较短,甚至为 0.000
#状态也是200,但是执行时间巨长的请求日志
[20/Jun/2013:00:02:33 +0800] "GET /carnews/2012/9/17/u_201209171731357133655.jpg HTTP/1.1" 200 24385 60.212 60.000, 0.212
这部分不太能理解,主要想让大家帮忙分析一下:
1. 为什么$response_response_time 会呈现成两部分 60.000, 0.212。是否与我们配置多个上游服务器有关
2. 大量的日志记录中,存在较多$request_time 和 $upstream_response_time 超过20秒,甚至达到60秒的情况?是否与我们的配置有关。
尽可能多的给出结构和配置信息,便于大家理解和帮我分析
1. 物理部署:一台物理机上存在2个nginx sbin 部署版本。
其中一个作为代理端,hold大量的请求,同时作为代理缓存内容存储,使用80端口
另一个作为处理端,执行业务处理,在80的upstream中被调用,使用8012端口。
共有三台物理机,每台的部署都一样。处理机在代理端配置中,使用upstream组织。
代理缓存的存储磁盘在三台机器上各是各的,会有重复数据。
其中,nginx_proxy代表代理端、nginx代表处理端
每一台机器上的nginx进程情况:
代理端配置:
worker_processes 12;
google_perftools_profiles /tmp/tcmalloc;
events {
use epoll;
worker_connections 65535;
}
http {
upstream y0.autoimg.cn {
server IP1:8012;
server IP2:8012;
server IP3:8012;
}
server{
listen 80;
server_name xxxx(一些列域名);
location ~* ^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp)$ {
add_header Cache-Control max-age=2592000;
proxy_pass http://$host;
proxy_cache tmpcache;
proxy_cache_valid 200 15d;
proxy_cache_key $uri;
}
}
}
====================================================
处理端配置:
worker_processes 12;
google_perftools_profiles /tmp/tcmalloc;
events {
use epoll;
worker_connections 65535;
}
http {
server {
listen 8012;
server_name localhost;
location ~* ^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp|JPE?G)$ {
rewrite "^/([\w\W]*)/.*\.(gif|jpe?g|png|bmp|JPE?G)$" /myredirect last;
}
location /myredirect {
custom_module_directive;
}
}
}
每台物理机的信息