作者cuizengshun·2017-02-17 17:21

系统运维工程师·民生银行

[经验分享] 日常分析AIX DUMP入门方法

字数 13267阅读 16674评论 7赞 32

平常看dump的方法：

我们如果遇到宕机的case，一般只能收集dump，然后上传到testcase，开PMR请求
二线技术支持，但是很多时候其实问题并没有那么复杂，我们完全可以在上传数据的同时，
自己在本机解开dump进行初步的分析，对于一些常见的简单问题，可以快速定位处理，
不用那么麻烦开PMS和上传数据，还能在客户面前提升自己的价值，赢得客户更大的信任。

1:检查dump是否成功：
```shell
#sysdumpdev -L
```
确认输出有：
Dump status:0
dump completed successfully

2：把dump转出来
```shell
#snap -r;snap -D
```
snap -D是把dump从dump设备拷贝到/tmp/ibmsupt/dump下面，因为我们直接在本地处理，
所以不用-c再压缩一遍了。

需要注意的是，因为dump默认我们都是压缩的，解开以后会非常大，如果/tmp空间不够的话，
可以在snap的时候用-d /dir 参数更改snap的工作目录为一个空间足够的文件系统里边。

dump目录下，有以下几个文件：
dump.BZ  这个是压缩的dump文件，用dmpuncompressdump.BZ解压。
unix.Z   产生dump主机的aix核心，用uncompressunix.Z 解压。
kdb,kdb_64 产生dump主机的kdb工具，uncompress之！

因为我们分析dump的主机往往和目标主机aix版本不一致，所以收集dump的时候，会把目标主机的
kernel和kdb工具都包含进来，一点要用和dump匹配的kernel和kdb，否则无法分析dump。

3：打开dump。
解开以后，打开dump就简单了，其实就是用dump目录里边的kdb来打开。
```shell
#./kdb dump unix
```

cdtc[/dump/zengdb/53021.000.672/dump]#uncompress unix.Z
cdtc[/dump/zengdb/53021.000.672/dump]#./kdb dump unix
The specified kernel file is a 64-bit kernel
dump mapped from @ 700000000000000 to @ 700000298e185e5
Preserving 1412209 bytes of symbol table
First symbol __mulh
Component Names:
1)  minidump [2 entries]
2)  dmp_minimal [9 entries]
3)  proc [3327 entries]
4)  thrd [5929 entries]
5)  rasct [1 entries]
6)  ldr [2 entries]
7)  iplcb [1 entries]
8)  errlg [3 entries]
9)  mtrc [38 entries]
10)  lfs [1 entries]
11)  bos [2 entries]
12)  ipc [7 entries]
13)  vmm [14 entries]
14)  alloc_kheap [256 entries]
15)  alloc_other [690 entries]
16)  rtastrc [1 entries]
17)  sisraid [2 entries]
18)  sscsidd [4 entries]
19)  aixpcm [14 entries]
20)  efcdd [42 entries]
21)  scdisk [13 entries]
22)  lvm [2 entries]
23)  jfs2 [1 entries]
24)  tty [4 entries]
25)  netstat [10 entries]
26)  goent_dd [10 entries]
27)  vpathdd [60 entries]
28)  scsidisk [374 entries]
29)  efscsi [5 entries]
30)  dump_statistics [1 entries]
Component Dump Table has 10825 entries
          START             END <name>
0000000000001000 0000000003DF7050 start+000FD8
F00000002FF47600 F00000002FFDC940 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
F100070F00000000 F100070F10000000 pvproc+000000
F100070F10000000 F100070F18000000 pvthread+000000
PFT:
PVT:
id....................0002
raddr.....0000000002000000 eaddr.....F200800130000000
size..............00080000 align.............00001000
valid..1 ros....0 fixlmb.1 seg....0 wimg...2
Dump analysis on CHRP_SMP_PCI POWER_PC POWER_5 machine with 12 availableCPU(s)  (64-bit registers)
Processing symbol table...
.......................done
(0)>

现在dump就正式打开，可以作进一步的分析了，以后我会把几种常见故障的分析方法介绍给大家，
如果有想深入研究的话，建议下载AIX官方文档（inforcenter和aix文档盘上都有）里边kdb手册
和汇编手册。

经常我们会遇到一种情况，aix dump 重启了，但是检查errpt的
结果，是user发起的sysdump。errpt的记录往往很简单，我们只能知道
是用户进程发起的，但是却不知道是谁发起的。
    以下是黑龙江移动的一个case，PMR:53657,000,672：

1:先打开dump
symtstest:/toibm/aix/53657.000.672/dump#./kdb dump unix
The specified kernel file is a 64-bit kernel
dump mapped from @ 700000000000000 to @ 7000001824ff56d
Preserving 1421784 bytes of symbol table
First symbol __mulh
Component Names:
1)  minidump [2 entries]
2)  dmp_minimal [9 entries]
3)  proc [1127 entries]
4)  thrd [2367 entries]
5)  rasct [1 entries]
6)  ldr [2 entries]
7)  iplcb [1 entries]
8)  errlg [3 entries]
9)  mtrc [26 entries]
10)  lfs [2 entries]
11)  bos [2 entries]
12)  ipc [7 entries]
13)  vmm [13 entries]
14)  alloc_kheap [512 entries]
15)  alloc_other [890 entries]
16)  rtastrc [1 entries]
17)  sscsidd [2 entries]
18)  efcdd [42 entries]
19)  scdisk [19 entries]
20)  aixpcm [9 entries]
21)  scsidisk [275 entries]
22)  lvm [2 entries]
23)  jfs2 [1 entries]
24)  tty [4 entries]
25)  netstat [10 entries]
26)  goent_dd [10 entries]
27)  PowerPath [1 entries]
28)  efscsi [5 entries]
29)  dump_statistics [1 entries]
Component Dump Table has 5346 entries
          START             END <name>
0000000000001000 0000000003E10050 start+000FD8
F00000002FF47600 F00000002FFDC940 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
F100070F00000000 F100070F10000000 pvproc+000000
F100070F10000000 F100070F18000000 pvthread+000000
PFT:
PVT:
id....................0002
raddr.....0000000002000000 eaddr.....F200800110000000
size..............00080000 align.............00001000
valid..1 ros....0 fixlmb.1 seg....0 wimg...2
Dump analysis on CHRP_SMP_PCI POWER_PC POWER_5 machine with 8 available
CPU(s)  (64-bit registers)
Processing symbol table...
.......................done

2：检查进程状态

(0)> status
CPU     TID  TSLOT     PID PSLOT  PROC_NAME
  0   211037    529 141024    321  diagela_exec
  1    1602D     22   D01A     13  wait
  2    950F5    149  EC060    236  oracle
  3    19033     25   F01E     15  wait
  4    C016F  32960   28102 16424  sysdumpstart
  5     313B  32771    3126 16387  wait
  6    8316B  32899   3415A 16436  loader
  7   117053    279 1020BE    258  loader
  8-63   Disabled
可以看见，系统dump是由于有进程发起sysdumpstart造成的，让我们查看是
谁发起的dump。

3:找出sysdumpstart的父进程

(0)> p *|grep 28102
pvproc+100A000 16424 sysdumps ACTIVE 0028102 0023108 00000009F053C400
0 0001

sysdumpstart的父进程是23108

(0)> p *|grep 0023108
pvproc+1008C00 16419 sh       ACTIVE 0023108002B0C8 000000096052E400
0 0001
pvproc+100A000 16424 sysdumps ACTIVE 0028102 0023108 00000009F053C400
0 0001

***: 现在找到sysdumpstart 的父进程了，是个sh.
(0)> tpid 0023108
               SLOT NAME     STATE    TID PRI  RQ CPUID  CL  WCHAN
pvthread+804900 32841 sh       SLEEP 049145028    0         0
查到这个sh的进程slot是 32841

4：找出sh相关的文件信息

(0)> user -f 32841
   U_fdfree.00000000   cannot_chpt.00000000
   pn_segno.0000000000000000
   pnseg_lock. @ F00000002FF49210 0000000000000000
   maxofile..0000003F   freefile..00000003
   lockcount.00000010   lock table addr.F00000002FF49608
   fd_lock[ 0]..F00000002FF49608 0000000000000000
   fd_lock[ 1]..F00000002FF49688 0000000000000000
   fd_lock[ 2]..F00000002FF49708 0000000000000000
   fd_lock[ 3]..F00000002FF49788 0000000000000000
   fd_lock[ 4]..F00000002FF49808 0000000000000000
   fd_lock[ 5]..F00000002FF49888 0000000000000000
   fd_lock[ 6]..F00000002FF49908 0000000000000000
   fd_lock[ 7]..F00000002FF49988 0000000000000000
   fd_lock[ 8]..F00000002FF49A08 0000000000000000
   fd_lock[ 9]..F00000002FF49A88 0000000000000000
   fd_lock[10]..F00000002FF49B08 0000000000000000
   fd_lock[11]..F00000002FF49B88 0000000000000000
   fd_lock[12]..F00000002FF49C08 0000000000000000
   fd_lock[13]..F00000002FF49C88 0000000000000000
   fd_lock[14]..F00000002FF49D08 0000000000000000
   fd_lock[15]..F00000002FF49D88 0000000000000000

File descriptor table at..F00000002FF49E20:

ufd block (U_fdblks[ 0]) @..F00000002FF49EE0
   ufd_maxfd of this block..0000003F
   fd      0 fp..F1000714700057A0count..00000000 flags. ALLOCATED
   fd      1 fp..F100071450011A00count..00000000 flags. ALLOCATED
   fd      2 fp..F100071450011A00count..00000000 flags. ALLOCATED
   fd     10 fp..F1000714700055C0 count..00000000flags. EXCLOSE ALLOCATED
   fd     62 fp..F100071470005890 count..00000000flags. EXCLOSE ALLOCATED

找到sh打开执行的两个文件。

5：接下来找出这两个文件所在设备和inod：

(0)> file F1000714700055C0
ADDR            COUNT          OFFSET            DATA TYPE   FLAGS

F1000714700055C0     1 000000000000168D F10001003F138BF8VNODE  READ

node.............      1 slot............. 6710955
f_flag. 0000000000000001 f_count........ 00000001
f_options.......... 0000 f_type............. 0001
f_data......... F10001003F138BF8 f_offset....... 000000000000168D
f_dir_off...... 0000000000000000 f_cred......... F100010041B617FC
f_lock@........ F1000714700055F0 f_lock......... 0000000000000000
f_offset_lock@. F1000714700055F8 f_offset_lock.. 0000000000000000
f_vinfo........ 0000000000000000 f_ops.......... 014A2368
vnodefops+000000
VNODE.......... F10001003F138BF8
v_flag.... 00000000 v_count... 0000000D
v_vfsgen.. 00000000 v_vfsp.... F1000100397AC950
v_lock@... F10001003F138C08 v_lock.... 0000000000000000
v_mvfsp... 0000000000000000 v_gnode... F10001003F1388B0
v_next.... 0000000000000000 v_vfsnext. F10001003F128BF8
v_vfsprev. F10001003F148BF8 v_pfsvnode 0000000000000000
v_audit... 0000000000000000

(0)> gnode F10001003F1388B0
GNODE............ F10001003F1388B0 F10001003F1388B0
gn_type....... 00000001 gn_flags...... FFFF8010
gn_seg........ 000000000014802B
gn_mwrcnt..... 00000000 gn_mrdcnt..... 00000000 gn_rdcnt...... 0000000D
gn_wrcnt...... 00000000 gn_excnt...... 00000000 gn_rshcnt..... 00000000
gn_ops........ 0000000001354480 j2_vnops
gn_vnode...... F10001003F138BF8 gn_rdev....... 8000000A00000005
gn_chan....... 00000000 gn_reclk_event 00000000FFFFFFFF
gn_reclk_lock@ F10001003F1388F8 gn_reclk_lock. 0000000000000000
gn_filocks.... 0000000000000000 gn_data....... F10001003F138880
gn_type....... REG gn_flags...... UIOMOVE XPAGER

(0)> i2 F10001003F138880
   ADDRESS          DEVICE          I_NUM    COUNT   TYPE    FLAG
F10001003F138880 8000000A00000005      18878   00013   VREG    ACC

(0)> file F100071470005890
ADDR            COUNT          OFFSET            DATA TYPE   FLAGS

F100071470005890     1 000000000000D5A1 F1000100409173F8VNODE  READ

node.............      1 slot............. 6710964
f_flag. 0000000000000001 f_count........ 00000001
f_options.......... 0000 f_type............. 0001
f_data......... F1000100409173F8 f_offset....... 000000000000D5A1
f_dir_off...... 0000000000000000 f_cred......... F100010041B617FC
f_lock@........ F1000714700058C0 f_lock......... 0000000000000000
f_offset_lock@. F1000714700058C8 f_offset_lock.. 0000000000000000
f_vinfo........ 0000000000000000 f_ops.......... 014A2368
vnodefops+000000
VNODE.......... F1000100409173F8
v_flag.... 00000000 v_count... 00000005
v_vfsgen.. 00000000 v_vfsp.... F1000100397AC8B0
v_lock@... F100010040917408 v_lock.... 0000000000000000
v_mvfsp... 0000000000000000 v_gnode... F1000100409170B0
v_next.... 0000000000000000 v_vfsnext. F1000100408F43F8
v_vfsprev. F1000100408DA7F8 v_pfsvnode 0000000000000000
v_audit... 0000000000000000
(0)> gnode F1000100409170B0
GNODE............ F1000100409170B0 F1000100409170B0
gn_type....... 00000001 gn_flags...... FFFF8010
gn_seg........ 00000000005382A5
gn_mwrcnt..... 00000000 gn_mrdcnt..... 00000000 gn_rdcnt...... 00000005
gn_wrcnt...... 00000000 gn_excnt...... 00000000 gn_rshcnt..... 00000000
gn_ops........ 0000000001354480 j2_vnops
gn_vnode...... F1000100409173F8 gn_rdev....... 8000000A00000004
gn_chan....... 00000000 gn_reclk_event 00000000FFFFFFFF
gn_reclk_lock@ F1000100409170F8 gn_reclk_lock. 0000000000000000
gn_filocks.... 0000000000000000 gn_data....... F100010040917080
gn_type....... REG gn_flags...... UIOMOVE XPAGER
(0)> i2 F100010040917080
   ADDRESS          DEVICE          I_NUM    COUNT   TYPE    FLAG
F100010040917080 8000000A00000004      17255   00005   VREG    ACC

DEVICE栏是设备号(majornumber),8000000A00000005转换成10进制就是10,5
8000000A000000004 就是10,4 我们来看看这两个设备是什么。

(0)> !grep "10,  5" ../lvm/lvm.snap
brw-rw----    1 root    system       10,  5 Oct 20 10:31 hd2
crw-rw----    1 root    system       10,  5 Oct 20 10:31 rhd2
(0)> !grep "10,  4" ../lvm/lvm.snap
brw-rw----    1 root    system       10,  4 Oct 20 10:31 hd4
crw-rw----    1 root    system       10,  4 Oct 20 10:31 rhd4

收集dump的时候，如果用了snap -a或者-L，就会收集lvm信息在/lvm/lvm.snap
文件里边，如果没有收集这个文件，直接在/dev目录下面ls -l也是一样的。我们看到
这次这两个设备是hd2和hd4，在rootvg里边看，是/usr和/文件系统。文件的inode分别
是18878和17255。

6：查找inode对应的文件名

我们现在已经确定的两个文件是 /usr下面的18878和 /下面的 17255，接下来需要在
故障发生的主机上查找这两个inode对应的文件：

![](/home/attachment/201702/17/32725_1487322597.png)
   这下故障的起源找到了，init.cssd是oracle cluster的程序，本次dump是由oracle发起
的，请oracle检查crs的日志，发现是存储问题导致心跳阻塞，引发crs的dump。至此root cause
找到，分析结束。

p * 得到系统进程的信息。

pdt * device table 查看iocont 的值不为0 的线程，表示为被阻塞的io数量。

pdt *|awk '$6!=0'

tpid <pid>  得到进程的线程信息。

th -p <slot> 得到线程信息。

proc <pid> 可以得到该进程的信息，包括线程信息。

ptid [[-x | -d] tid] 通过 tid看进程信息。

svmon * >svmon.out 从dump数据中使用svmon 命令中可以获得内存使用信息。

frs *

vmker *

(1)> vmker

VMM Kernel Data:

(use [ -pta | -dr | -seg | -lrul | -psize] forspecific info)

lke 装载进 kernal的驱动程序

dla看死锁

lk  查看锁信息

lq  查看是不是有锁存在

th -w WSLOCK 查看处于WSLOCK 状态的线程

th -w 查看所有的锁

clk 看复杂锁锁信息。

slk

怎么看所是复杂锁还是简单锁

vmlog

Errorid              =  ISI_PROC

Exceptionvalue        =  0000001C EXCEPT_ERRNO --->/usr/include/sys/errno.h

mst  <thread slot>看寄存器，需要汇编知识。

（intpri） 寄存器

dw lru_file_repage

var

stat 基本状态信息

status CPU上的进程信息

f 堆栈信息

f <threaditongslot>

th *

th -lk 看线程锁总体信息的一个概况。

vmlog

……FFFA--->表明页面被换出

(1)> vmlog

Most recent VMM errorlog entry

Errorid              =  ISI_PROC

Exception DSISR/ISISR  = 0000000000000000

Exceptionsrval        =  0000000000000000

Exception virt addr   =  0000000000000000

Exceptionvalue        =  0000001C EXCEPT_ERRNO ---->errno=28 nospace left on the device

hcal 16进制数字转换为10 进制

dcal 计算器

![](/home/attachment/201702/17/32725_1487322662.png)

[标题]dump状态的意义

环境:(产品,平台,机型,软件版本,等)

问题描述: 我们经常用“sysdumpdev -L”去查看系统是否产生了dump，看到dump status字段有时为0，有时为-2。这代表什么意义呢？

解答:
![](/home/attachment/201702/17/32725_1487322831.png)

Dump status字段的解释可以在/usr/include/sys/dump.h中找到：
![](/home/attachment/201702/17/32725_1487322861.png)

意义如下：
DMPDO_SUCCESS     0        Dump成功完成。
DMPDO_DISABLED   -1         没有定义dump设备。
DMPDO_PART       -2        Dump设备太小，只产生了部分dump。
DMPDO_FAIL       -3        Dump产生过程中失败，或根本没有开始。
DMPDO_IOERROR    -4          在产生dump的过程中，dump设备上出现I/O错误。

kdb的命令，可以参见下面的文档。
http://www.aixchina.net/Document/detail/tid/227013

dump文件分析 AIX

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！