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
