55 | 套路篇：分析性能问题的一般步骤
倪朋飞
该思维导图由 AI 生成，仅供参考
你好，我是倪朋飞。
上一节，我们一起学习了，应用程序监控的基本思路，先简单回顾一下。
应用程序的监控，可以分为指标监控和日志监控两大块。
指标监控，主要是对一定时间段内的性能指标进行测量，然后再通过时间序列的方式，进行处理、存储和告警。
而日志监控，则可以提供更详细的上下文信息，通常通过 ELK 技术栈，来进行收集、索引和图形化展示。
在跨多个不同应用的复杂业务场景中，你还可以构建全链路跟踪系统。这样，你就可以动态跟踪调用链中各个组件的性能，生成整个应用的调用拓扑图，从而加快定位复杂应用的性能问题。
不过，如果你收到监控系统的告警，发现系统资源或者应用程序出现性能瓶颈，又该如何进一步分析它的根源呢？今天，我就分别从系统资源瓶颈和应用程序瓶颈这两个角度，带你一起来看看，性能分析的一般步骤。
系统资源瓶颈
首先来看系统资源的瓶颈，这也是最为常见的性能问题。
在系统监控的综合思路篇中，我曾经介绍过，系统资源的瓶颈，可以通过 USE 法，即使用率、饱和度以及错误数这三类指标来衡量。系统的资源，可以分为硬件资源和软件资源两类。
如 CPU、内存、磁盘和文件系统以及网络等，都是最常见的硬件资源。
而文件描述符数、连接跟踪数、套接字缓冲区大小等，则是典型的软件资源。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文从分析性能问题的一般步骤出发，主要介绍了系统资源瓶颈和应用程序瓶颈两个角度的分析方法。在系统资源瓶颈方面，文章详细介绍了CPU性能、内存性能、磁盘和文件系统I/O性能以及网络性能的分析步骤，以及相应的工具和指标。对于应用程序瓶颈，文章提到了资源瓶颈、依赖服务瓶颈和应用自身瓶颈三种性能问题的来源，并提供了相应的分析定位方法。总的来说，本文通过系统资源和应用程序两个角度，为读者提供了全面的性能问题分析指南。文章强调了系统资源和应用程序之间的相互影响，并鼓励读者结合实际经验进行讨论和分享。整体而言，本文为读者提供了系统性能分析的基本框架和方法，对于需要进行性能问题分析的技术人员具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68
《Linux 性能优化实战》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
胡鹏平时用php的xhprof,或是go的prof图，分析代码性能，作者回复: 👍谢谢分享
2019-04-0713
我来也[D55打卡] 集合了各模块套路的套路篇，哈哈。2019-04-037- ninuxer打卡day59 本篇内容综合了之前的几大块的套路～2019-04-034
武文文武老师，请教一个问题排查的思路: 我采用netty作为缓存代理节点的通信框架，目前存在万分之一的概率出现200ms左右的慢请求，正常情况下都是1ms，请问这种问题该如何排查呢，火焰图之类的分析工具无法分析偶发如此低，时间如此短的问题，还请您给指点一下2020-12-1012
Jxin
1.很棒的专栏，长了很多知识。 2.遗憾的是我要排查的问题依旧没有找到解决方案。 3.问题描述: 偶发的服务qps下降(2000下降到200),系统cpu负载和使用率都出现彪高打满,1s左右后恢复。通过pidstat定时跑可以确定，在异常cpu资源使用情况时，只有java进程占用高CPU基本可以确定是jvm进程自身的问题。在cpu上升时打印堆栈信息和嵌入代码发现异常请求耗时打印堆栈，两个方式都打印不到异常堆栈(cpu彪高时两种打印都滞后了，滞后到jvm正常后才打印) 4.请问以上有啥好的排查思路吗?监听内核事件？偶发的，两三天出一次，也不定是出在集群哪台机器，采集事件日志太大了。2020-09-2111
罗杰使用一些简单的命令加应用程序日志，稍微高级一点的工具都没用到过。2022-08-11归属地：陕西- 董皋打卡2020-03-21
雪哥老师我想问一下，千万级并发用户的压测，一般用什么工具啊，或者其他技术手段实现超大并发的性能测试2019-10-172- 如果DAY55，打卡2019-04-23
每日都想上班喜欢老师的讲解2019-04-05
收起评论
