嵌入式 如何定位死循环或高CPU使用率(linux)

如何定位死循环或高CPU使用率(linux)

确定是CPU过高

使用top观察是否存在CPU使用率过高现象

找出线程

对CPU使用率过高的进程的所有线程进行排序

ps H -e -o pid,tid,pcpu,cmd --sort=pcpu |grep xxx

得到如下结果,其中线程2909使用了7.8%的CPU.

2907 2913 0.0 ./xxx

2907 2909 7.8 ./xxx

也可以通过查看/proc中的信息来确定高CPU线程. 打印了4列,线程ID,线程名,用户时间和内核时间(排名未分先后)

awk ‘{print $1,$2,$14,$15}‘ /proc/2907/task/*/stat

找出调用栈

使用gdb attach nmsagent所在的进程,在gdb中使用 info threads显示所有线程

gdb gdb>attach 2907

gdb>info threads

得到如下结果,可以发现2909线程的编号是12

13 Thread 0xad5f2b70 (LWP 2908) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

12 Thread 0xad58eb70 (LWP 2909) 0x006e0422 in __kernel_vsyscall ()

11 Thread 0xad52ab70 (LWP 2910) 0x006e0422 in __kernel_vsyscall ()

10 Thread 0xad4f8b70 (LWP 2911) 0x006e0422 in __kernel_vsyscall ()

9 Thread 0xad4c6b70 (LWP 2912) 0x006e0422 in __kernel_vsyscall ()

8 Thread 0xad3feb70 (LWP 2913) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

7 Thread 0xace08b70 (LWP 2914) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

6 Thread 0xac607b70 (LWP 2915) 0x006e0422 in __kernel_vsyscall ()

5 Thread 0xac5e6b70 (LWP 2916) 0x006e0422 in __kernel_vsyscall ()

4 Thread 0xac361b70 (LWP 2917) 0x006e0422 in __kernel_vsyscall ()

3 Thread 0xac2fdb70 (LWP 2918) 0x006e0422 in __kernel_vsyscall ()

2 Thread 0xac1fcb70 (LWP 2919) 0x004ef0d7 in mq_timedreceive () from /lib/tls/i686/cmov/librt.so.1

* 1 Thread 0xb78496d0 (LWP 2907) 0x006e0422 in __kernel_vsyscall ()

使用thread 切换线程,使用bt显示线程栈

gdb>thread 12 gdb>bt

得到如下线程栈

#0 0x006e0422 in __kernel_vsyscall ()

#1 0x001cca26 in nanosleep () from /lib/tls/i686/cmov/libc.so.6

#2 0x001fc2dc in usleep () from /lib/tls/i686/cmov/libc.so.6

#3 0x0806b510 in OspTaskDelay ()

#4 0x0805c710 in CDispatchTask::NodeMsgSendToSock() ()

#5 0x0805cc74 in DispatchTaskEntry ()

#6 0x0806a8e9 in OspTaskTemplateFunc(void*) ()

#7 0x00d4780e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0

#8 0x002027ee in clone () from /lib/tls/i686/cmov/libc.so.6

ps + strace

得到进程ID 21465 ps -e |grep cmu 4996 ? 00:00:25 cmu_fjga_sp3 21465 pts/5 00:08:10 cmu

得到线程时间, 其中最占CPU的是 EpollRecvTask 21581

ps -eL |grep 21465

21465 21579 pts/5 00:00:00 CamApp

21465 21580 pts/5 00:00:00 TimerMan Task

21465 21581 pts/5 00:09:02 EpollRecvTask

21465 21582 pts/5 00:00:00

使用 strace -p 21581 得到线程栈

时间： 2024-10-12 12:30:45

嵌入式 如何定位死循环或高CPU使用率(linux)的相关文章

制造高CPU使用率的简单方法

原文:制造高CPU使用率的简单方法 在群里有人问制造CPU占用率高的场景用来做测试.所谓做好事难,干“坏”事还不容易?这个需求有很多方法可以实现,比如使用一些压力测试工具.我首先想 到的是HASH JOIN.这个联接比较消耗CPU资源,拿两大表HASH JOIN一下,最好是包含大字段的,开多几个进程,CPU使用率马上飙升到80-90%! 下面就使用一张系统视图进行HASH JOIN来实现,简单快捷. DECLARE @i BIGINT WHILE (1=1) BEGIN SELECT @i =

[Java] HashMap 导致的高 CPU 使用率

今天在生产环境遇到一个问题,Java 应用程序的 cpu 使用比例很高,导致整台机器的 cpu 使用率高达 90% ,正常情况下是 20% 左右. 把 Thread dump 导出来,利用 IBM Thread Analyzer for Java 工具进行分析.总共有60 多个在线线程,其中有 15 个线程都在执行同一个文件中的同一句代码,最顶层的调用是 HashMap.get() . HashMap 的底层数据结构是数组 + 链表进行存储,链表用于处理 hash 碰撞的情况.正常情况下链接是线

【转载】php-fpm的高CPU使用率排查方法

1.CPU使用率监控 sar -P ALL 1 100 输出结果如下:CPU %user %nice %system %iowait %steal %idleall 85.54 0.00 5.69 0.00 0.00 8.76 0 74.75 0.00 25.25 0.00 0.00 0.00 1 98.00 0.00 2.00 0.00 0.00 0.00 2 89.22 0.00 3.92 0.00 0.00 6.86 3 91.00 0.00 2.00 0.00 0.00 7.00 4 7

.Net 调式案例—实验4 高CPU（High CPU）回顾

原文地址:http://blog.csdn.net/directionofear/article/details/8033506 如果Web应用程序经常遇到的问题按频率排名的话,我觉得 第一名unhandled exception 第二名high memory 第三名high cpu 这篇文章介绍web应用程序中cpu使用率过高问题相应的数据收集方式和调试问题的方法. 对ASP.NET Web应用程序CPU使用率过高的问题,从宏观上分分类,大概就这么几种情况, 大量请求 过多循环 GC频繁 数据

Linux性能优化从入门到实战：04 CPU篇：CPU使用率

??CPU使用率是单位时间内CPU使用情况的统计,以百分比方式展示. $ top top - 11:46:45 up 7 days, 11:52, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 198 total, 1 running, 197 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st K

（原创）性能测试中，Oracle服务器定位CPU使用率高的瓶颈（SQL）

本篇博客记录一次性能测试过程中,定位对CPU使用率高的瓶颈问题,主要定位SQL为准 一.用SQL命令定位1.首先用TOP命令监控系统资源,如果是AIX系统,就用topas,进入TOP命令的滚动刷新数据时,发现userCPU高达98%!! 保持top的状态下,按shift+p,可以将所有进程按CPU使用率高低排序,这样可以了解消耗CPU最多的进程是哪些 可以看到,当前userCPU使用率高达98%,且此时TPS不再随并发数上升了,可以认为已经达到性能瓶颈了,且是由CPU瓶颈造成的 2.排序完后,将

.NET定位CPU使用率过高问题

摘要: 当一个.net应用在生产环境CPU突然居高不下,如何快速准确的定位问题所在,并且对实时业务影响最小化?如何不抓Dump也不用live debug就可以知道你的应用在做什么?如何确认你的应用是由于哪个线程的执行造成的CPU升高,该线程正在执行什么代码? 分析:CPU升高的原因有很多, 1.有时候应用的负载大了,CPU自然会受业务请求的增加和增高: 2.有时候因为GC回收使用了过高的CPU资源: 3.有时候是某个线程执行的代码在某种情况下陷入了死循环: 4.有时候是因为锁争用太激烈,某资源上

一个查询交易导致数据库CPU使用率高的问题

这一阵子在做一个查询交易的压力测试,使用的AIX+informix数据库.应用和数据库分别部署在两台机器上.使用loadrunner进行并发测试.相关表的历史数据是20W级别的.使用20个并发进行测试. 测试过程中,应用服务器负载正常,数据库服务器磁盘.网络使用率正常,但是CPU使用率却是98%左右.觉得很奇怪,因为这台机器是测试环境中性能最好的,表现不应该如此.于是先猜测会不会是informix的参数配置不对,于是搜了些informix参数中影响CPU使用率的参数调了一遍,但是现象依旧.对里面

查找CPU使用率过高的线程

1.在编写程序中有时候设置不恰当,休眠时间不够,一般情况下4核的电脑CPU使用率一直大于23%,8核的大于13%就有可能是这种情况 解决方法: 在VS查看并行线程利用CPU使用工具ProcessExplorer,查看CPU占用率过高的线程查看线程ID 和 并行线程ID 相同的然后仔细看那个并行线程的代码 2. 查看代码中是否有死锁的部分,死循环或者是耗时代码,一些需要托管在其它硬件执行的程序 3.其它: 硬件原因:散热不良,驱动问题 病毒爬虫等外界恶意软件: 重复调用一个进程而没有结束: