Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87258 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

52 | 案例篇:服务吞吐量下降很厉害,怎么分析?

解决方法
分析吞吐量下降问题的根源
火焰图分析
端口号优化
套接字优化
工作进程优化
连接数优化
动态追踪工具找热点函数
比较系统原理
收集性能指标
bcc
火焰图
perf
思考
性能优化
分析步骤
性能工具
性能问题分析方法

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为。先简单来回顾一下。
所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从而辅助排查出性能问题的瓶颈。
使用动态追踪,便可以在不修改代码也不重启服务的情况下,动态了解应用程序或者内核的行为。这对排查线上的问题、特别是不容易重现的问题尤其有效。
在 Linux 系统中,常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
使用 perf 配合火焰图寻找热点函数,是一个比较通用的性能定位方法,在很多场景中都可以使用。
如果这仍满足不了你的要求,那么在新版的内核中,eBPF 和 BCC 是最灵活的动态追踪方法。
而在旧版本内核,特别是在 RHEL 系统中,由于 eBPF 支持受限,SystemTap 和 ftrace 往往是更好的选择。
网络请求延迟变大 的案例中,我带你一起分析了一个网络请求延迟增大的问题。当时我们分析知道,那是由于服务器端开启 TCP 的 Nagle 算法,而客户端却开启了延迟确认所导致的。
其实,除了延迟问题外,网络请求的吞吐量下降,是另一个常见的性能问题。那么,针对这种吞吐量下降问题,我们又该如何进行分析呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了如何使用动态追踪方法来分析服务吞吐量下降的问题,并通过案例准备和案例分析展示了解决方法。作者首先通过Docker搭建Nginx+PHP应用环境,并使用wrk工具测试Nginx的性能,随后通过观察TCP连接数和系统日志,发现了连接跟踪导致的问题,并提出了相应的优化方法。文章还介绍了端口号优化和火焰图分析的过程,最终通过调整系统参数和优化应用,解决了服务吞吐量下降的问题。整篇文章内容详实,适合需要解决类似问题的技术人员参考。通过实际案例向读者展示了如何使用动态追踪方法来分析服务性能问题,为读者提供了实用的技术指导。文章强调了利用性能工具收集性能指标、比较系统原理和当前状态、借助动态追踪工具找出热点函数的重要性,为读者提供了分析性能问题的方法论。最后,作者邀请读者分享他们的经验,强调在交流中进步的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(31)

  • 最新
  • 精选
  • 2xshu
    老师,有个疑问。 套接字优化部分,你用ss -s输出的两个队列,根据“关于 Linux 网络,你必须知道这些(下)”你讲的内容,当链接处于listening状态是,Send-Q和Recv-Q都是半链接队列,但是你这里却都是调的全连接队列啊?不是应该调整tcp_max_syn_backlog吗?

    作者回复: 嗯,谢谢指出,是文中的步骤不严谨了。实际上应该再加上两步 1. 查看调优 tcp_max_syn_backlog 2. 观察全连接的状况之后再调优全连接队列

    2019-03-25
    17
  • ninuxer
    打卡day55 缺乏由现象联想到可能原因的系统性思维~

    作者回复: 还是需要加强原理的理解

    2019-03-25
    3
    5
  • xfan
    内核选项 tcp_tw_reuse,不是直接修改内核参数就好了么,为什么还有修改后的tag:3 ,这里不太清楚

    作者回复: 嗯 也可以的。打包成镜像的是最后优化的结果

    2019-03-28
    2
    4
  • 泡泡
    wrk命令-c参数用来模拟连接数为1000, 为什么输出中的连接数有1910,不理解

    作者回复: -c是并发数,输出中是每秒请求数,不是一回事

    2019-03-26
    4
  • Maxwell
    在公司局域网下做性能测试,如何判断网络会不会成为压测的瓶颈呢?也就是说如果开了500线程进行压测,会不会因为网络瓶颈,导致请求无法发送到服务器端?

    作者回复: 可以在测试的时候同时观察一下网络吞吐和丢包(比如使用sar)

    2019-03-25
    4
  • burner
    老师,系统cpu只用了一半,但是就出现502和499的请求错误,是否意味这应用服务已经过载,还是系统连接数过载,查看netstat发现有28万失败的连接尝试,

    作者回复: 应用过载了

    2019-08-13
    1
  • 腾达
    net.ipv4.tcp_tw_reuse = 1 这里是影响到socket的客户端(nginx作为一个客户端连接php的服务端)的行为吗? 不是影响到服务端的time_wait数量? 我弄了个tomcat,用ab压测,tw_use=1, 用ss -s看time_wait 还很高啊,1万多。

    作者回复: 嗯 用在客户端上

    2019-04-15
    2
    1
  • 子杨
    服务端端口号不是近似无限的吗,这里怎么又有限制了。

    作者回复: 端口号是16位的,自然有最大限制。你从哪里看到端口号无限?

    2020-07-22
    2
  • 腾达
    老师,针对我提的问题,您的回复是:“不过你可以docker exec到容器内部查看”,我已经逐一对比过容器内的、我已知的参数了。未发现不同。您能否把最后一次的配置参数上传一下到github?

    作者回复: 包括内核选项和Nginx配置吗?

    2019-04-08
  • 腾达
    有2个问题: 1、在做perf,制作火焰图的部分,我自己本地看到的函数热点是类似:inet_sendmsg, tcp_write_xmit, e1000_xmit_frame 之类的,后续再对内核参数net.ipv4.tcp_tw_reuse做设置为1的处理后,函数热点依然是这几个。似乎我的机器上的热点是在发送数据,而不是在端口重用? 2、老师最后1个步骤的镜像,即: $ docker run --name nginx --network host --privileged -itd feisky/nginx-tp:3 $ docker run --name phpfpm --network host --privileged -itd feisky/php-fpm-tp:3 这2个的配置能上传一下到github吗?我自己依照优化步骤修改的参数,放到镜像里去跑,压测后Requests/sec只能达到: 1919,而是用老师的tag=3的镜像,压测后得到Requests/sec是3107。我把我已知的参数都对比了一遍,如下: sysctl net.ipv4.ip_local_port_range='10000 65535' sysctl net.ipv4.tcp_tw_reuse=1 sysctl net.ipv4.tcp_fin_timeout=3 sysctl net.ipv4.tcp_max_syn_backlog=8192 sysctl net.netfilter.nf_conntrack_max=1048576 sysctl net.core.somaxconn=65536 还有nginx、php的backlog=8192,php的max_children=40(我给了40,不是老师的20)。 发现都是一样的。不知道哪里有问题。 老师,你能把优化最后的配置文件上传一份到github吗?

    作者回复: 优化后的配置没有上传到github里面,不过你可以docker exec到容器内部查看

    2019-04-05
收起评论
显示
设置
留言
31
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部