性能分析

今天在测试环境有过代码升级。升级后，在群里有人反映系统访问很慢。运维人员反映服务器 CPU 使用率很高。 运维重启后，没有多久，又有人反映系统访问很慢，这时运维人员说有大量的 Full GC 产生。

在定位到需要优化的单条查询SQL后，我们可以针对此查询“钻取”更多信息，分析为什么会花费怎么长的时间执行，以及如何去优化的大致方向。

在代码的逻辑清晰的情况下，是完全可以知道哪些文件是频繁读写的。但是对性能分析人员来说，通常是面对一个不是自己编写的系统，有时还是多个团队合作产生的系统。这时就会出现很多的推诿和争执。如果可以迅速地把问

总体来说，从问题的表象到原因之间，都是会有证据可循的。而在分析的过程中就是要把证据找出来。层次清晰，逻辑合理，不要绕来绕去把问题复杂化。

之前遇到过 jbd2 引起 IO 高的问题，直接关掉了日志的功能解决的。最近又见类似问题，这里重新整理下对 jbd2 的内容。

top 是一个时间周期内的资源统计。ps 是一个个时间点的资源值。 如果要监控一个系统的整体资源使用率的话，建议用 top 来看。如果要分析到一个具体的线程使用的 CPU 资源时，再

在做性能分析的时候，我们不可避免地判断资源到底够不够用？哪里不够？为什么不够？证据是什么？ 能回复得了这些问题并不容易。 今天就来聊聊一下操作系统资源饱和度应该如何衡量？

初学者对性能分析的感受是：横看成岭侧成峰，远近高低各不同。那么应该怎么学习才能建立起自己的性能分析体系，才能做到千山同一月，万户尽皆春。千江有水千江月，万里无云万里天呢？

目前的压力工具大部分是针对服务端，即模拟「网络 API 请求」，而前端程序基本上是由一系列的「用户交互事件」所驱动，其业务状态是一颗 DOM 树.

平均负载提供了一个快速查看系统整体性能的手段，反映了系统的整体负载状况。但并不能跟CPU使用率并不一定完全对应

在我们对Java应用做性能分析的时候，往往采用log进行问题定位和分析，但是如果我们的log缺乏相关的信息呢？

而从现象到瓶颈的性能分析是最需要一个人有足够的知识宽度的，因为你不知道在寻找瓶颈的过程中会遇到什么样的知识弱点。

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。 本文已参与 「掘力星计划」 ，赢取创作大礼包，挑战创作激励金。 背景 前几天在 7DGroup 的群中，小鹏同学提了一个问题。 群里一顿讨论

想想国内的项目中有多少是性能问题对领导政绩任务的时间和修改成本妥协了。这个问题修改起来复杂吗？从技术上来说，并不复杂。但是性能是个综合考虑的事情。 做性能分析的人要做到的就是问题到底在哪里？要怎么修

性能分析呢，需要的全局观，有人看到找出来的性能结果，觉得怎么问题这么简单。但是当你不知道的时候，要干什么，才是能力。

在性能分析过程中，你可以看到，我都没有直接去看什么代码或 SQL。因为我一直在强调一点就是性能分析一定要有证据链。

Arthas 是 Alibaba开源的一款 Java 诊断工具，能够查看 Java 应用的线程状态、JVM 信息等，支持在线对业务问题诊断，比如查看方法调用的出入参、执行过程、抛出的异常、输出方法执行

在性能分析中，SQL 的分析那是必须的。 不同的库又有着不同的命令，但是总体来说，同一类型的数据库，除了有一些手段上的不同之外，给出的结果基本上都是类似的。