Linux下top+pstack+gdb的组合拳定位程序进程线程问题并调试

摘要: 在Linux 下如果发现程序运行异常,比如CPU, 内存占用很高,可以采用linux下自带的一些命令,帮助我们找到问题所在。

在Linux 下如果发现程序运行异常,比如CPU, 内存占用很高,可以采用linux下自带的一些命令,帮助我们找到问题所在。
一、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显示

当然如果是JAVA应用,其实还有一个可以辅助的命令, jstack ,利用这个命令,可以看到进程中的所有线程情况。

上一篇: elasticsearch high level rest api分页查询数据
下一篇: Agile Data Science 2.0书中代码.
 评论 ( What Do You Think )
名称
邮箱
网址
评论
验证
   
 

 


  • 微信公众号

  • 我的微信

站点声明:

1、一号门博客CMS,由Python, MySQL, Nginx, Wsgi 强力驱动

2、部分文章或者资源来源于互联网, 有时候很难判断是否侵权, 若有侵权, 请联系邮箱:summer@yihaomen.com, 同时欢迎大家注册用户,主动发布无版权争议的 文章/资源.

3、鄂ICP备14001754号-3, 鄂公网安备 42280202422812号