Hello! 2013/7/25 Timo Seven: > 在实际应用中发现只要对方qps一提高到5000以后,这个recvfrom的系统调用就会慢。而几百qps的才0.008毫秒这样的情况。 > > 我nginx是用作一个单纯的proxy来使用的,所有请求都会返回给后端。 > 这是很常见的现象。对于一个资源固定的服务系统来说,吞吐量和操作延时本来就是一对矛盾。当吞吐量提高时,一般会伴随着操作延时的相应增长。 在你这个例子中,进一步确定造成 recvfrom 延时增长的原因,可以考虑使用 on-CPU time 和 off-CPU time 火焰图工具进行分析: https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt-off-cpu 注意你需要对 kernel 空间进行采样(第二个工具暂不支持 kernel 空间采样,但你可以很容易地进行修改),毕竟这里你感兴趣的是系统调用内部的性能问题。 同时抄送给 openresty 中文邮件列表:https://groups.google.com/group/openresty 希望你加入此列表并在那里交流这样的问题。谢谢合作! Regards, -agentzh
Hello! 2013/7/25 Timo Seven > > 下面这个是我用你的ngx-sample-bt 生成的火焰图。 发现很多都是一些tengine的自己的内部函数,但是其实我都应该没有用到。但是我看占用cpu时间还都挺长的,这个是不是要不要在编译的时候不加载这些模块。 > 建议下回提供原始的 .svg 文件,而不是 .jpg,因为 .svg 文件支持交互,可以看到更多的信息。 从你自己的分析来看,貌似你还不太会看火焰图 :) 从你提供的 .jpg 图片看,connect 系统调用是大头,你可以考虑启用 ngx_proxy 的上游连接池,避免短连接造成的频繁的 connect() 调用的开销,见这里的文档:http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive 下一个大头是 writev 系统调用,降低此调用整体开销的一个常见办法是增大各级缓冲区的大小,比如 proxy_buffer_size 配置指令: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size 还有 output_buffers 配置指令。 再有一个大头 epoll_wait 则无所谓了。有趣的是,在这个图上,并没有看到 recvfrom :) 值得一提的是,你这里生成的是用户态的 on-CPU 火焰图。你还可以尝试生成 off-CPU 火焰图以及核心态的火焰图 :) Regards, -agentzh
Hello! 2013/7/25 Timo Seven > > Hi yichun > > > 前面弄错了,弄的是用户空间的,下面这个是内核空间的,但都是16进制的代码。粗略看下都是tcp/ip方面的代码。 你这里的 kernel 函数帧都是地址,说明你没有安装 kernel 的调试符号包,所以无法从地址对应到函数名。比如在我的 Fedora 系统上是 kernel-debuginfo 这个包。 Regards, -agentzh