[经验分享] 日常分析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对应的文件:

#find / -xdev -inum 17255
/etc/init.cssd
#find /usr -xdev  -inum 18878
/usr/lib/nls/msg/en_US/ksh.cat

   这下故障的起源找到了,init.cssd是oracle cluster的程序,本次dump是由oracle发起
的,请oracle检查crs的日志,发现是存储问题导致心跳阻塞,引发crs的dump。至此root cause
找到,分析结束。

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

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

pdt *|awk '$6!=0'

tpid   得到进程的线程信息。

th -p 得到线程信息。

proc 可以得到该进程的信息,包括线程信息。

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  看寄存器,需要汇编知识。

(intpri) 寄存器

dw lru_file_repage

var

stat 基本状态信息

status CPU上的进程信息

f 堆栈信息

f

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 计算器

>lke 查看系统加载的驱动信息(即 kernal extension)

[标题]dump状态的意义

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

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

解答:
#sysdumpdev -L
Device name:         /dev/lg_dumplv
Major device number: 10
Minor device number: 10
Size:               305415680 bytes
Uncompressed Size:   1783261241 bytes
Date/Time:           Wed Nov28 08:54:21 BEIST 2007
Dump status:         0
dump completed successfully

Dump status字段的解释可以在/usr/include/sys/dump.h中找到:
/*
* Return codes from the system dump.
*/
#define DMPDO_SUCCESS     0
#define DMPDO_DISABLED   -1
#define DMPDO_PART       -2
#define DMPDO_FAIL       -3
#define DMPDO_IOERROR    -4

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

参与11

4同行回答

cuizengshuncuizengshun  系统运维工程师 , 民生银行
kdb的命令,可以参见下面的文档。显示全部

kdb的命令,可以参见下面的文档。

附件:

附件图标kdb_pdf.pdf (1.21 MB)

收起
银行 · 2017-02-17
浏览3511
jeanionjeanion  存储工程师 , SENDI
感谢兄弟分享显示全部

感谢兄弟分享

收起
系统集成 · 2017-03-02
浏览3393
wangqlwangql  系统工程师 , NULL
感谢分享,非常好显示全部

感谢分享,非常好

收起
IT咨询服务 · 2017-02-17
浏览3449
zhanghaiyangzhanghaiyang  系统工程师 , 联合网讯
多谢分享 赞赞 显示全部

多谢分享 赞赞

收起
互联网服务 · 2017-02-17
浏览3356

提问者

cuizengshun
系统运维工程师民生银行
擅长领域: 云计算服务器iaas

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2017-02-17
  • 关注会员:4 人
  • 问题浏览:9183
  • 最近回答:2017-03-02
  • X社区推广