性能指标之资源指标-CPU-谁占用了CPU-函数级-tProf

如果查看函数级的CPU资源占用细节，可以查看tprof报告。本节介绍打报告的方法，以及一些基本的分析思路。

1、 打tprof报告方法

抓取perfpmr文件 60秒。

#perfpmr.sh 60

从结果文件中取出tprof.sum

或直接抓取tprof

#tprof –uskejzlt –x sleep 60

2、分析思路

首先看是Kernel、User、Shared Library中的那个方面占比消耗高。例如，如果是share lib占比比较高，则找到对应的share lib分页，查看具体哪个lib占用CPU高，再查看这个特定的lib中哪个函数占用CPU高。

如果通过以上方法不能定位到一个应用层的函数，而是定位到消耗CPU最高的是个系统函数。不但不认识这个系统函数，也看不出谁调用了这个系统函数，因为一些系统层的函数是通用函数（比如h_cede_end_point），从这类函数并不能看出是谁在调用。这种情况，可以通过这个系统函数相邻的那些能看懂的函数来猜测，因为占用CPU高的函数往往是同一个应用、同一个模块、同一类系统调用导致，他们具有扎堆出现的特点。

如果是kernal->lock占 2~3% cpu就是很多了。

如果定位到一个进程有问题，可以用Truss –c –p pid查看一个进程在干什么，比如，是在做fork，还是文件读写。

3、示例1

注：本例中具体函数名为化名。

总体查看，本例中Shared Library消耗最高，仅ProcessAAA的Shared Library就占57.72%。

找到Shared Library分页，查看具体哪个Shared Library占用CPU高

其中占比最大的是/a/b/bin/comaaa.so，顺其向下搜索/a/b/bin/comaaa.so

可以发现，加解密的函数消耗CPU最明显；EBuildChar单个函数竟然占用了整个CPU的16.33%。

4、示例2

这是一个通过相邻函数来猜测问题点的例子。

Nmon图中，Cicsas是干正经活儿的主力函数，而j2pg莫名其妙的高就需要深入查查。





wait占用CPU高就不太正常了，但具体是什么导致的wait不太清楚，一般是通过相邻函数来猜测。

接下来j2pg是个系统函数，这样的异常占用的CPU非常高，这里我们就可以合理猜测，wait是由于j2pg引起的。

而j2pg是个什么鬼呢？网上一查，是个系统函数，但没有什么解释，从名字上看，貌似是个JFS2文件系统做Page操作的函数。

好，此时我们做一个深入分析。

J2pg的CPU占用全部是Kernel，那么我们跳到Kernel的分页。



占用CPU最多的是h_cede_end_point，它是指thread退出hypervisor的CPU占用。如果经常看tprof报告的人清楚，这个函数可以说是经常在有CPU问题的时候出现，各类情况都可能出现h_cede_end_point占kernel高。

此时，我们还得依靠“周围”猜测。

接下来的四个函数中，有两个貌似是和j2pg有关的，因为是j2开头的（j2_inode.c），他们分别是.syncHashList和.iSyncNeeded。

还记不记得，总的CPU消耗breakdown中，sync也是排名靠前的



我们来看看sync的解释：在Linux/Unix系统中，在文件或数据处理过程中一般先放到内存缓冲区中，等到适当的时候再写入磁盘，以提高系统的运行效率。sync命令则可用来强制将内存缓冲区中的数据立即写入磁盘中。用户通常不需执行sync命令，系统会自动执行update或bdflush操作，将缓冲区的数据写入磁盘。

到这里，似乎水落石出，是由于应用多度频繁的调用sync函数去做缓存到磁盘的同步导致的系统态CPU高。

那么sync这个函数是不是可以从应用里去掉呢？具体分析这个应用，调用sync只是为了确保日志写到磁盘，这个系统本身是做监控的系统，整个系统挂了也不会影响交易运行，它写不写日志，日志有没有进磁盘，根本不重要。况且这个系统还有个数据库，监控数据由数据库负责安全性。调优方法：直接去掉sync。

长按识别二维码