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

在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 ，利用这个命令，可以看到进程中的所有线程情况。