首页
登录 | 注册

linux下定位CPU占用高的进程的问题点

一、Top+pstack+gdb的组合拳

闲言少述,先直接上操作实例,再做原理讲解。

1.1 用top命令找到最占CPU的进程
>top
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
22688 root      20   0 1842m 136m  13m S 110.0  0.9   1568:44 test-program 


1.2 使用pstack跟踪进程栈
此命令可显示每个进程的栈跟踪。
pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。
此命令允许使用的唯一选项是要检查的进程的 PID。


这个命令在排查进程问题时非常有用,
比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),
使用这个命令就能轻松定位问题所在;
可以在一段时间内,多执行几次pstack,若发现代码栈总是停在同一个位置,
那个位置就需要重点关注,很可能就是出问题的地方;


>pstack 22688
Thread 44 (Thread 0x7fa97035f700 (LWP 22689)):
#0  0x00007fa96f386a00 in sem_wait () from /lib64/libpthread.so.0
#1  0x0000000000dfef12 in uv_sem_wait ()
#2  0x0000000000d67832 in node::DebugSignalThreadMain(void*) ()
#3  0x00007fa96f380aa1 in start_thread () from /lib64/libpthread.so.0
#4  0x00007fa96f0cdaad in clone () from /lib64/libc.so.6
Thread 43 (Thread 0x7fa96efe4700 (LWP 22690)):
#0  0x00007fa96f386a00 in sem_wait () from /lib64/libpthread.so.0
#1  0x0000000000e08a38 in v8::base::Semaphore::Wait() ()
#2  0x0000000000dddde9 in v8::platform::TaskQueue::GetNext() ()
#3  0x0000000000dddf3c in v8::platform::WorkerThread::Run() ()
#4  0x0000000000e099c0 in v8::base::ThreadEntry(void*) ()
#5  0x00007fa96f380aa1 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fa96f0cdaad in clone () from /lib64/libc.so.6
Thread 42 (Thread 0x7fa96e5e3700 (LWP 22691)):
#0  0x00007fa96f386a00 in sem_wait () from /lib64/libpthread.so.0
#1  0x0000000000e08a38 in v8::base::Semaphore::Wait() ()
#2  0x0000000000dddde9 in v8::platform::TaskQueue::GetNext() ()
#3  0x0000000000dddf3c in v8::platform::WorkerThread::Run() ()
#4  0x0000000000e099c0 in v8::base::ThreadEntry(void*) ()
#5  0x00007fa96f380aa1 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fa96f0cdaad in clone () from /lib64/libc.so.6
Thread 41 (Thread 0x7fa96dbe2700 (LWP 22692)):
#0  0x00007fa96f386a00 in sem_wait () from /lib64/libpthread.so.0
#1  0x0000000000e08a38 in v8::base::Semaphore::Wait() ()
#2  0x0000000000dddde9 in v8::platform::TaskQueue::GetNext() ()
#3  0x0000000000dddf3c in v8::platform::WorkerThread::Run() ()
#4  0x0000000000e099c0 in v8::base::ThreadEntry(void*) ()
#5  0x00007fa96f380aa1 in start_thread () from /lib64/libpthread.so.0
#6  0x00007fa96f0cdaad in clone () from /lib64/libc.so.6


使用top命令查看指定进程最耗CPU的线程,
下面找到的线程号为 22970.
>top -H -p 22688
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND    
22970 root      20   0 1842m 136m  13m R  100.2 0.9 1423:40 test-program


NOTE:
这里的PID是系统给每个线程分配的唯一的线程号,不是进程号,但名称也是PID。
这两者的具体区别可见:
《linux中pid,tid, 以及 真实pid的关系》
http://blog.csdn.net/u012398613/article/details/52183708


使用线程号PID反查其对应的线程号。
如下就找到了 线程 22970对应的线程10
>pstack 22688 | grep 22970
Thread 10 (Thread 0x7fa92f5fe700 (LWP 22970)):


使用VIM查看进程快照,定位到具体的线程,并查看其调用堆栈;
>pstack 22688 | vim -
Thread 10 (Thread 0x7fa92f5fe700 (LWP 22970)):
#0  0x00007fa96f02a04f in vfprintf () from /lib64/libc.so.6
#1  0x00007fa96f054712 in vsnprintf () from /lib64/libc.so.6
#2  0x00007fa967b3861c in lv_write_log () from /opt/test-program
#3  0x00007fa967b26173 in LvJbuf::pjmedia_jbuf_put_rtp_pkg(pjmedia_rtp_decoded_pkg const*, int*) () from /opt/test-program
#4  0x00007fa96782409f in livesrv::LvAudio::on_rtp_stream(void*, unsigned int, unsigned int) () from /opt/test-program
#5  0x00007fa96781fc87 in livesrv::LvMedia::recv_media(void*, unsigned int, unsigned char, unsigned int) () from /opt/test-program
#6  0x00007fa967818c7f in livesrv::LvChannel::do_recv_media_check_thread2() () from /opt/test-program/node_modules/livesource/Debug/linux/livesource.node
#7  0x00007fa967814699 in recv_media_process2(void*) () from /opt/test-program
#8  0x00007fa96f380aa1 in start_thread () from /lib64/libpthread.so.0
#9  0x00007fa96f0cdaad in clone () from /lib64/libc.so.6

上面的操作基本定位到了具体线程和大概的函数,
如果想查看具体的原因,如现场的函数中变量等的数值等,就要使用的GDB的实时调试功能。
1.3 使用gdb调试实时进程
>gdb attach 22688
:thread 10
:bt
:frame x
:p xxx


二、top用法

2.1 top:动态观察程序的变化
[root@linux ~]# top [-d] | top [-bnp]
参数:
  -d :后面可以接秒数,就是整个程序画面更新的秒数。预设是 5 秒;
  -b :以批次的方式执行 top ,还有更多的参数可以使用喔!
       通常会搭配数据流重导向来将批次的结果输出成为档案。
  -n :与 -b 搭配,意义是,需要进行几次 top 的输出结果。
  -p :指定某些个 PID 来进行观察监测而已。


在 top 执行过程当中可以使用的按键指令:
   ? :显示在 top 当中可以输入的按键指令;
   P :以 CPU 的使用资源排序显示;
   M :以 Memory 的使用资源排序显示;
   N :以 PID 来排序喔!
   T :由该 Process 使用的 CPU 时间累积 (TIME+) 排序。
   k :给予某个 PID 一个讯号 (signal)
   r :给予某个 PID 重新制订一个 nice 值。


2.2 top 也是个挺不错的程序观察工具!
不同于 ps 是静态的结果输出, top 这个程序可以持续的监测 (monitor) 整个系统的程序工作状态,
例如上面的范例一所示啊! 在预设的情况下,每次更新程序资源的时间为 5 秒,
不过,可以使用 -d 来进行修改。 
top 主要分为两个画面,上面的画面为整个系统的资源使用状态,基本上总共有六行, 显示的内容依序是:
? 第一行:显示系统已启动的时间、目前上线人数、系统整体的负载(load)。 
  比较需要注意的是系统的负载,三个数据分别代表 1, 5, 10 分钟的平均负载。
  一般来说,这个负载值应该不太可能超过 1 才对,除非您的系统很忙碌。 
  如果持续高于 5 的话,那么.....仔细的看看到底是那个程序在影响整体系统吧!
? 第二行:显示的是目前的观察程序数量,
  比较需要注意的是最后的 zombie 那个数值,如果不是 0 ,
  嘿嘿!好好看看到底是那个 process 变成疆尸了吧?!
? 第三行:显示的是 CPU 的整体负载,每个项目可使用 ? 查阅。
  需要观察的是 id (idle) 的数值,一般来说,他应该要接近 100% 才好,表示系统很少资源被使用啊! ^_^。
? 第四行与第五行:表示目前的物理内存与虚拟内存 (Mem/Swap) 的使用情况。
? 第六行:这个是当在 top 程序当中输入指令时,显示状态的地方。 例如范例四就是一个简单的使用例子。


至于 top 底下的画面,则是每个 process 使用的资源情况。比较需要注意的是:
? PID   :每个 process 的 ID 啦!
? USER  :该 process 所属的使用者;
? PR    :Priority 的简写,程序的优先执行顺序,越小越早被执行;
? NI    :Nice 的简写,与 Priority 有关,也是越小越早被执行;
? %CPU  :CPU 的使用率;
? %MEM  :内存的使用率;
? TIME+ :CPU 使用时间的累加;
一般来说,如果鸟哥想要找出最损耗 CPU 资源的那个程序时,大多使用的就是 top 这支程序啦!
然后强制以 CPU 使用资源来排序 (在 top 当中按下 P 即可), 就可以很快的知道啦! ^_^。

三、pstack用法

此命令可显示每个进程的栈跟踪。
pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。
此命令允许使用的唯一选项是要检查的进程的 PID。请参见 proc(1) 手册页。


这个命令在排查进程问题时非常有用,比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),
使用这个命令就能轻松定位问题所在;
可以在一段时间内,多执行几次pstack,
若发现代码栈总是停在同一个位置,那个位置就需要重点关注,很可能就是出问题的地方;


示例:查看bash程序进程栈:
/opt/app/tdev1$ps -fe| grep bash
tdev1   7013  7012  0 19:42 pts/1    00:00:00 -bash
tdev1  11402 11401  0 20:31 pts/2    00:00:00 -bash
tdev1  11474 11402  0 20:32 pts/2    00:00:00 grep bash


/opt/app/tdev1$pstack 7013
#0  0x00000039958c5620 in __read_nocancel () from /lib64/libc.so.6
#1  0x000000000047dafe in rl_getc ()
#2  0x000000000047def6 in rl_read_key ()
#3  0x000000000046d0f5 in readline_internal_char ()
#4  0x000000000046d4e5 in readline ()
#5  0x00000000004213cf in ?? ()
#6  0x000000000041d685 in ?? ()
#7  0x000000000041e89e in ?? ()
#8  0x00000000004218dc in yyparse ()
#9  0x000000000041b507 in parse_command ()
#10 0x000000000041b5c6 in read_command ()
#11 0x000000000041b74e in reader_loop ()
#12 0x000000000041b2aa in main ()


四、GDB调试运行中程序的方法

4.1 多线程调试
多线程调试最重要就是下面几个命令:
1. 查看当前进程的线程。
info thread    


2. 切换调试的线程为指定ID的线程。 
thread  


3. 在file.c文件第100行处为所有经过这里的线程设置断点。    
break file.c:100 thread all  


4. 线程开关
在使用step或者continue命令调试当前被调试线程的时候,其他线程也是同时执行的,
怎么只让被调试程序执行呢?通过这个命令就可以实现这个需求。
set scheduler-locking off|on|step,
 . off    不锁定任何线程,也就是所有线程都执行,这是默认值。
 . on     只有当前被调试程序会执行。
 . step   在单步的时候,除了next过一个函数的情况
          (熟悉情况的人可能知道,这其实是一个设置断点然后continue的行为)以外,
          只有当前线程会执行。
 
4.2 调试宏
在GDB下,我们无法print宏定义,因为宏是预编译的。
但是我们还是有办法来调试宏,这个需要GCC的配合。
在GCC编译程序的时候,加上-ggdb3参数,这样,你就可以调试宏了。


另外,你可以使用下述的GDB的宏调试命令 来查看相关的宏。
info macro – 你可以查看这个宏在哪些文件里被引用了,以及宏定义是什么样的。
macro – 你可以查看宏展开的样子。
1、首先获得程序的PID
ps -ef | grep xxxxx  


2、进入调试程序
gdb attach PID  


3、gcore命令生成CORE文件
4、进程信息可以用info  proc显示
5、寄存器信息可以用info reg显示


相关文章

  • 问题描述:生产环境下的某台tomcat7服务器,在刚发布时的时候一切都很正常,在运行一段时间后就出现CPU占用很高的问题,基本上是负载一天比一天高.问题分析:1,程序属于CPU密集型,和开发沟通过,排除此类情况.2,程序代码有问题,出现死循 ...
  • Linux终端查看最消耗CPU内存的进程
    ps auxw|head -1;ps auxw|sort -rn -k3|head -10 2.内存消耗最多的前10个进程 ps auxw|head -1;ps auxw|sort -rn -k5|head -10 4.也可以试试 5.看看 ...
  • 定位Linux下定位进程被谁KILL
    转载请注明出处 http://forever.blog.chinaunix.net 瀚海书香 今天上午有个同事问,自己的进程被莫名其妙的杀死了,想知道是被那个进程误杀了. 第一个想法是用kernel hack系统调用的方式,刚打算翻出hoo ...
  • ipcs此命令的适用范围:RedHat.RHEL.Ubuntu.CentOS.Fedora.SUSE.openSUSE. 1ipcs [-asmq]  [-tclup] ipcs -h 2选项 -i -m -q -s -a -t -p -c ...
  • 《循序渐进Linux》第二版即将出版发行(附封面)
    从<循序渐进Linux>第一版发布,到现在已经近6年了,6年的时间,技术发生了很大的变化,Linux系统的内核版本从2.6.9(RHEL4.x)已经更新到了现在的3.10(Centos7.x),第一版中的部分内容已经陈旧,Lin ...
  • TOP命令行语义分析
    接触 linux 的人对于 top 命令可能不会陌生(不同系统名字可能不一样,如 IBM 的 aix 中叫 topas ),它的作用主要用来监控系统实时负载率.进程的资源占用率及其它各项系统状态属性是否正常. 下面我们先来看张 top 截图 ...

2020 unjeep.com webmaster#unjeep.com
12 q. 0.014 s.
京ICP备10005923号