zprofiler三板斧解决cpu占用率过高问题
上周五碰到了一个线上机器cpu占用率过高的问题。问题本身比较简单，但是定位过程中动用了多个zprofiler的主要功能，感觉是一个很好的介绍使用zprofiler定位此类问题流程的案例。
在开始使用zprofiler之前，先使用perf确认瓶颈点是否在native中。（以下操作需要root权限，需要pe协助操作）
如果线上服务器没有安装perf，可以到 http://yum.corp.taobao.com/taobao/6/x86_64/test/aliperf/aliperf-0.3.9-9.el6.x86_64.rpm 下载rpm包，然后安装。
使用 perf top 命令，查看当前系统的热点函数。
如上图所示的情况即表明，热点在java代码中，因为java代码是jit执行的，perf看不到其符号，所以默认归入perf-<pid>.map中。
如果热点在libjvm.so中的函数，可以联系我们团队，协助进一步分析。比如如果热点是jit相关的函数，一般是codecache或者jit相关参数的问题；如果是gc相关的函数，可以用zprofiler分析一下gclog，然后调整gc相关的参数。
排除其他可能，确定是java代码的问题之后，可以先做一个thread dump，在zprofiler上分析一下。
使用 thread dump 中的 运行态线程热点堆栈(load) 功能，就可以看到在运行线程中出现的最多的调用栈。如下图所示：
在开始使用zprofiler之前，先使用perf确认瓶颈点是否在native中。（以下操作需要root权限，需要pe协助操作）
如果线上服务器没有安装perf，可以到 http://yum.corp.taobao.com/taobao/6/x86_64/test/aliperf/aliperf-0.3.9-9.el6.x86_64.rpm 下载rpm包，然后安装。
使用 perf top 命令，查看当前系统的热点函数。
如上图所示的情况即表明，热点在java代码中，因为java代码是jit执行的，perf看不到其符号，所以默认归入perf-<pid>.map中。
如果热点在libjvm.so中的函数，可以联系我们团队，协助进一步分析。比如如果热点是jit相关的函数，一般是codecache或者jit相关参数的问题；如果是gc相关的函数，可以用zprofiler分析一下gclog，然后调整gc相关的参数。
排除其他可能，确定是java代码的问题之后，可以先做一个thread dump，在zprofiler上分析一下。
使用 thread dump 中的 运行态线程热点堆栈(load) 功能，就可以看到在运行线程中出现的最多的调用栈。如下图所示：
其实这里已经看到出问题的堆栈了，但是因为thread dump只是一个快照，当时没敢相信这么快就找到问题所在，所以还是觉得用Hot method Profiling看一下。
Hot Method Profiling 已经有专门的文章介绍，这里就不多说了，看圈子的置顶帖就可以了。
当时分析结果如下图：
这个结果非常明显，排第一的函数占了99%的cpu占用率。而且展开之后的调用栈跟前面在热点堆栈里面看到的调用栈一模一样。基本可以肯定问题就出在这里。
但是产品的小伙伴说这个地方是正常的调用，sql语句很久没有修改，数据库里面数据量也不大。为了一探究竟，决定做一个heap dump，看一下到底在处理什么样的数据？
做完heap dump之后，拷贝到zprofiler系统上分析。大概看了一下 "对象簇视图"，没有什么特别大的对象。
然后又看了一下 “线程概览” ，可以在右边 "正则匹配" 的地方，根据线程名把相关线程过滤出来。
然后展开可以看到各层调用栈上的局部对象。如下图：
鼠标放上去，可以看到对象的内容。这里就可以看到正在查询的sql语句，以及相关的参数。
后来查出来的根本原因是有一个第三方组件没有升级导致的bug。
不过整个过程还是比较有借鉴意义的，希望对大家有帮助。