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

平常看dump的方法：

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

1:检查dump是否成功：

#sysdumpdev -L

确认输出有：
Dump status:0
dump completed successfully

2：把dump转出来

#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来打开。

#./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 

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 

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对应的文件：

这下故障的起源找到了，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 计算器

[标题]dump状态的意义

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

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

解答:

Dump status字段的解释可以在/usr/include/sys/dump.h中找到：

意义如下：
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