如何查看函数级的CPU资源占用细节？ - 聦儿的主页
湖南，衡阳
来源：社区“系统性能测试”专栏http://www.talkwithtrend.com/Column/detail/id/9tProf1、打tprof报告方法抓取perfpmr文件 60秒。perfpmr.sh 60从结果文件中取出tprof.sum或直接抓取tproftprof –uskejzlt –x sleep 602、分析思路首先看是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。curt1、打curt报告方法方法1：抓取perfpmr文件 60秒。perfpmr.sh 60在结果文件trace上产生curt文件curt -i trace.r -m trace.nm -o curt.out方法2：直接敲命令从产生trace开始2、实例讲解分析思路1） 先看System Summary，其中SYSCALL最高2） 从Application Summary看高syscall对应的pid和tid如果生成curt的时候，加入了trace.nm，结果是这样的，有了进程名字。trcnm & trace.nmcurt -i trace.r_all -m trace.nm -o curt.out3） 从System Call Summary看排在前面的进程看到和之前Application Summary看到的几个进程都差不多，找第一个2752538看看，这个进程在干什么。这Process Details for Pid是需要curt的时候 加-pSVC：The name of the system call and its kernel address.4） 这个进程中找前几个动作查看没有trace.nm的效果：2418B8是什么，需要到trace.nm里面搜有trace.nm的效果如果加入了trace.nm，效果是这样的5） 搜索这个动作（3248380），发现有报错猜测，可能是load不到so，并且有statx函数都报错（statx是collect information about symbolic links）一般来说，so被load之后，可以由多个程序共享，当所有程序都不用它的时候，它会被unload。如果总是load不到so，有可能是一个so只被某个程序引用，当这个程序执行完成后，进程销毁，同时也把so unload。所以下次这个程序被调起的时候，so是找不到的，还需要重新加载so。6） 解决方案让另一个长期存活的进程加载so，这样so在系统当中的计数就不会归0，so就不会反复unload、load更多相关文章请点击阅读原文长按二维码关注公众号作者 13:30技术经理, 中国人民银行清算总中心性能指标之资源指标-CPU-谁占用了CPU-函数级-curt字数 999阅读 3691评论 0赞 0续上一篇文章继续介绍如果查看函数级的CPU资源占用细节。
1、打curt报告方法
方法1：抓取perfpmr文件 60秒。perfpmr.sh 60
在结果文件trace上产生curt文件curt -i trace.r -m trace.nm -o curt.out
方法2：直接敲命令从产生trace开始
2、实例讲解分析思路
先看System Summary，其中SYSCALL最高
从Application Summary看高syscall对应的pid和tid
如果生成curt的时候，加入了trace.nm，结果是这样的，有了进程名字。trcnm > trace.nmcurt -i trace.r_all -m trace.nm -o curt.out
从System Call Summary看排在前面的进程
看到和之前Application Summary看到的几个进程都差不多，找第一个2752538看看，这个进程在干什么。这Process Details for Pid是需要curt的时候 加-p
SVC：The name of the system call and its kernel address.
这个进程中找前几个动作查看
没有trace.nm的效果：2418B8是什么，需要到trace.nm里面搜
有trace.nm的效果如果加入了trace.nm，效果是这样的
搜索这个动作（3248380），发现有报错
猜测，可能是load不到so，并且有statx函数都报错（statx是collect information about symbolic links）
一般来说，so被load之后，可以由多个程序共享，当所有程序都不用它的时候，它会被unload。
如果总是load不到so，有可能是一个so只被某个程序引用，当这个程序执行完成后，进程销毁，同时也把so unload。所以下次这个程序被调起的时候，so是找不到的，还需要重新加载so。
解决方案让另一个长期存活的进程加载so，这样so在系统当中的计数就不会归0，so就不会反复unload、load
微信公众号：性能测试与调优
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
关注2536 文章
作者其他文章评论 0 · 赞 8评论 0 · 赞 2评论 2 · 赞 10评论 0 · 赞 4评论 1 · 赞 11&
— talk with trend,talk with technologist
京ICP备号-30如何查看函数级的CPU资源占用细节？ - 的主页
来源：社区“系统性能测试”专栏http://www.talkwithtrend.com/Column/detail/id/9tProf1、打tprof报告方法抓取perfpmr文件 60秒。perfpmr.sh 60从结果文件中取出tprof.sum或直接抓取tproftprof –uskejzlt –x sleep 602、分析思路首先看是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。curt1、打curt报告方法方法1：抓取perfpmr文件 60秒。perfpmr.sh 60在结果文件trace上产生curt文件curt -i trace.r -m trace.nm -o curt.out方法2：直接敲命令从产生trace开始2、实例讲解分析思路1） 先看System Summary，其中SYSCALL最高2） 从Application Summary看高syscall对应的pid和tid如果生成curt的时候，加入了trace.nm，结果是这样的，有了进程名字。trcnm & trace.nmcurt -i trace.r_all -m trace.nm -o curt.out3） 从System Call Summary看排在前面的进程看到和之前Application Summary看到的几个进程都差不多，找第一个2752538看看，这个进程在干什么。这Process Details for Pid是需要curt的时候 加-pSVC：The name of the system call and its kernel address.4） 这个进程中找前几个动作查看没有trace.nm的效果：2418B8是什么，需要到trace.nm里面搜有trace.nm的效果如果加入了trace.nm，效果是这样的5） 搜索这个动作（3248380），发现有报错猜测，可能是load不到so，并且有statx函数都报错（statx是collect information about symbolic links）一般来说，so被load之后，可以由多个程序共享，当所有程序都不用它的时候，它会被unload。如果总是load不到so，有可能是一个so只被某个程序引用，当这个程序执行完成后，进程销毁，同时也把so unload。所以下次这个程序被调起的时候，so是找不到的，还需要重新加载so。6） 解决方案让另一个长期存活的进程加载so，这样so在系统当中的计数就不会归0，so就不会反复unload、load更多相关文章请点击阅读原文长按二维码关注公众号如何查看程序各个线程和函数的cpu占用率_百度知道
如何查看程序各个线程和函数的cpu占用率
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
桌面，任务栏，右键，任务管理器，性能，资源监视器，即可详细查看。望采纳
采纳率：66%
来自团队：
在桌面下面的空的任务栏中右键打开任务管理器即可
任务管理器里面，双击红色框框那里，出来的是大图
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。如何查看函数级的CPU资源占用细节？ - hommecc的主页
江苏，南通
来源：社区“系统性能测试”专栏http://www.talkwithtrend.com/Column/detail/id/9tProf1、打tprof报告方法抓取perfpmr文件 60秒。perfpmr.sh 60从结果文件中取出tprof.sum或直接抓取tproftprof –uskejzlt –x sleep 602、分析思路首先看是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。curt1、打curt报告方法方法1：抓取perfpmr文件 60秒。perfpmr.sh 60在结果文件trace上产生curt文件curt -i trace.r -m trace.nm -o curt.out方法2：直接敲命令从产生trace开始2、实例讲解分析思路1） 先看System Summary，其中SYSCALL最高2） 从Application Summary看高syscall对应的pid和tid如果生成curt的时候，加入了trace.nm，结果是这样的，有了进程名字。trcnm & trace.nmcurt -i trace.r_all -m trace.nm -o curt.out3） 从System Call Summary看排在前面的进程看到和之前Application Summary看到的几个进程都差不多，找第一个2752538看看，这个进程在干什么。这Process Details for Pid是需要curt的时候 加-pSVC：The name of the system call and its kernel address.4） 这个进程中找前几个动作查看没有trace.nm的效果：2418B8是什么，需要到trace.nm里面搜有trace.nm的效果如果加入了trace.nm，效果是这样的5） 搜索这个动作（3248380），发现有报错猜测，可能是load不到so，并且有statx函数都报错（statx是collect information about symbolic links）一般来说，so被load之后，可以由多个程序共享，当所有程序都不用它的时候，它会被unload。如果总是load不到so，有可能是一个so只被某个程序引用，当这个程序执行完成后，进程销毁，同时也把so unload。所以下次这个程序被调起的时候，so是找不到的，还需要重新加载so。6） 解决方案让另一个长期存活的进程加载so，这样so在系统当中的计数就不会归0，so就不会反复unload、load更多相关文章请点击阅读原文长按二维码关注公众号