崔增顺
作者崔增顺2017-02-17 17:21
系统运维工程师, 民生银行

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

字数 12384阅读 10371评论 7赞 31

平常看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 得到进程的线程信息。

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

[标题]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

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

31

添加新评论7 条评论

#hunshiwangren技术支持, 中国电信集团系统集成有限责任公司
2019-06-01 16:07
不错不错,好东西
#lztjcom系统工程师, fuwuqi
2019-04-15 14:18
很实用,分析问题思路清晰,故障定位准确
#dhl999027系统架构师, 北京华胜天成科技股份有限公司
2019-04-05 21:19
不错 实用
#swlhfa系统工程师, IBM
2019-03-26 14:28
这样的文章就要顶起来
#myfuller系统工程师, rongke
2019-03-26 10:21
非常不错的资料
#caopeibao系统工程师, 南京壹进制信息技术股份有限公司
2019-03-25 17:30
谢谢分享!
#wuwenpin软件开发工程师, 南京
2018-11-15 20:48
非常不错的资料,学习了!
Ctrl+Enter 发表

本文隶属于专栏

PowerVC专栏
本专栏主要分享PwerVM和PowerVC相关方面的架构、实施、运维等经验,以及企业私有云建设的相关经验及总结。
AIX运维专栏
专注于AIX系统运维,系统管理。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30