原文：http://czmmiao.iteye.com/blog/1144999

DUMP文件概述

为了增强故障分析能力，IBM的服务器增加了对设备故障当前环境的保存功能，就是保存一份设备故障时的内存、CPU寄存器、IO等设备的数据和状态信息，如果系统并没有停住，只是某个程序死掉，会产生CORE DUMP，在当前目录下产生一个CORE文件。而如果操作系统死掉，则产生System DUMP或者System Crash，通常会引起系统停机。DUMP的记录如下图所示。

作为一般客户通常只需要收集DUMP信息，并反馈给IBM工程师即可。当发生系统DUMP时，机器将会被宕下来。可能的原因包括：系统在进行内核操作时发生了未知的意外或者不能对其进行正常处理，都会引起DUMP。也可以由系统管理员发出命令，强制系统DUMP。
当系统进行DUMP时，DUMP管理设施自动将内核相关的数据(kernel segment0及其他由内核或者内核扩展程序记录在主DUMP表中的内存块)复制到主DUMP设备。可以把DUMP理解为系统当时的一个快照，供以后分析，分析DUMP可以在其他机器上进行，但需要复制一份此机器的内核程序，即unix_mp或unix_mp64.没有对应于DUMP的内核程序是午饭进行DUMP分析的。
DUMP的生成过程

CORE DUMP的生成过程

在进程运行出现异常行为时，例如无效地址访问、浮点异常、指令异常等，将导致系统转入内核态进行异常处理（即中断处理），向相应的进程发出特定信号例如 SIGSEGV、SIGFPE、SIGILL 等。如果应用进程注册了相应信号的处理函数（例如可通过 sigaction 注册信号处理函数），则调用相应处理函数进行处理（应用程序可以选择记录信息后生成 core dump 并退出）；否则将采取默认动作，例如 SIGSEGV 的默认动作是生成 core dump 并退出程序。
进程 coredump 的时候，操作系统会将进程终止并释放其占用的资源，正常情况下，应用进程 coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程，则这些进程会受到影响，至于后果则视其对此异常的具体处理而定。
 由于相关指令已经包含在可执行文件中，core 文件一般只包含进程异常时相关的内存信息。其格式可参考 /usr/include/sys/core.h 或者 AIX 帮助文档的“Files Reference”章节。我们一般需要结合 core 文件以及可执行程序，来分析问题所在
 注：由于进程信号处理本质上是异步的，应用进程注册的信号处理函数中使用的例程需要保证是异步信号安全的，例如不能使用诸如 pthread_ 开头的例程。 
系统 dump 生成过程 
系统异常 dump 的具体过程与应用进程类似，但由于更接近底层，为了避免问题所在的资源（例如文件系统）正好包含在生成 dump 需要使用的资源中，造成 dump 无法生成，操作系统一般会用最简单的方式来生成 dump。例如系统内存小于 4G 的情况下，一般直接将 dump 生成在 pagingspace 中；大于 4G 时，会建专门的 lg_dumplv 逻辑卷（裸设备），默认的dump设备/dev/hd6，次设备是/dev/sysdumpnull保存 dump 信息。在系统重启的时候，如果设置的 DUMP 转存目录（文件系统中的目录）有足够空间，它将会转存成一个文件系统文件，缺省情况下，是 /var/adm/ras/ 下的 vmcore* 这样的文件。
下面是常见的转储设备大小规则
当服务器的内存大于4GB时，在安装AIX时，就会为系统 dump 创建一专用区域，该逻辑卷名就是 lg_dumplv. 其缺省大小是按以下规则分配的：
4GB < = 服务器的内存 〈 12GB lg_dump 的大小为 1GB
12GB < = 服务器的内存 〈 24GB lg_dump 的大小为 2GB
24GB < = 服务器的内存 〈 48GB lg_dump 的大小为 3GB
48GB < = 服务器的内存 lg_dump 的大小为 4GB 
系统 dump 一般可以通过升级微码、提高系统补丁级别、升级驱动等方式解决。
环境变量设置 
可以通过 /etc/security/limits 文件对各用户的基本配置参数包括 core 大小进行限制。或者通过 ulimit 更改当前环境下的 core 大小限制。
默认情况下，应用进程生成 core dump 时都使用文件名 core。为了避免同一工作目录下的进程 core 相互覆盖，可以定义环境变量 CORE_NAMING=true，然后启动进程，这样将生成名为 core.pid.ddhhmmss 的文件。可以使用 file core 命令查看 core 是哪个进程产生的。
默认情况下，应用进程 dump 时会包含所有的共享内存，如果 dump 时想排除共享内存内容，可以在启动进程之前设置环境变量 CORE_NOSHM=true.
系统有一个参数 fullcore 用于控制是否在程序 coredump 时生成完整的 core。为避免信息丢失，建议打开 fullcore。可以使用 lsattr –El sys0 查询是否将 fullcore 打开，使用 chdev -l sys0 -a fullcore=true 将 fullcore 状态更改为打开。如果想让系统DUMP后自动重新启动，（对于远程管理员比较有用，否则管理员必须到现场按开关重新启动计算机，可以执行 lsattr –El sys0 查看autorestart是否为true，使用 chdev -l sys0 -a autorestart=true 将 autorestart状态更改为打开。两者都可以通过smit chgsys的smit菜单来修改

DUMP文件管理

由于DUMP文件较为复杂而且一般都交给IBM工程师进行分析，在次本文不做讨论，下文主要探讨DUMP文件的管理。

查看当前DUMP设备的配置信息

#sysdumpdev -l
primary              /dev/lg_dumplv           ##主DUMP设备 
secondary            /dev/sysdumpnull      ##次DUMP设备 
copy directory       /var/adm/ras            ##DUMP文件拷贝目录 
forced copy flag     TRUE                       ##是否进行提示将DUMP文件复制到外设 
always allow dump    FALSE                  ##总是进行DUMP 
dump compression     ON                     ##是否启用DUMP文件压缩 
type of dump         traditional

注意

1.旧版本的 AIX “always allow dump”可能默认为关闭；为方便系统 crash 时问题定位，建议打开。当该选项设置为true时，当按下服务器reset按钮或者预先设定的DUMP键盘序列的时候系统会自动生成DUMP。

打开命令

#sysdumpdev -KP

关闭命令

#sysdumpdev -kP

或者使用smitty -> System Environments-> Change / Show Characteristics of System Dump 菜单设置。

2.当系统重启的时候，如果设置了force copy flag为true，可以有提示让你将dump复制到外置介质，例如磁带。这样磁盘目录不够的时候，也有机会保留(往往DUMP设备与系统交换分区共用同一逻辑卷，而系统启动后，交换区将被覆盖)一份系统DUMP。

3.如果想允许DUMP文件进行压缩，则使用下列命令

打开命令

#sysdumpdev -CP

关闭命令

#sysdumpdev -cP

sysdump命令使用示例
创建DUMP设备

#mklv -y dumplv -t sysdump rootvg 10

将逻辑卷 hd7 临时指派为主要转储设备：
#sysdumpdev  -p /dev/hd7

估计需要的转储设备大小：
#sysdumpdev  -e 或者 smit dump_estimate

将磁带设备 rmt0 临时指派为辅助转储设备：
#sysdumpdev  -s /dev/rmt0 
显示先前的转储的统计信息：
#sysdumpdev  -L 
永久地将主要转储设备的数据库对象更改到 /dev/newdisk1，输入：
#sysdumpdev  -P  -p /dev/newdisk1 
确定是否存在新的系统转储，输入：
#sysdumpdev  -z 
如果最近发生了系统转储，则会出现与下列相似的输出：
4537344 /dev/hd7
将远程转储文件 /var/adm/ras/systemdump（在主机 mercury 上）指派给主要转储设备，输入：
#sysdumpdev  -p mercury:/var/adm/ras/systemdump 
在主机名和文件名之间必须输入冒号 ：。
指定系统崩溃后转储要复制到其上的目录（如果转储设备是 /dev/hd6），输入：
#sysdumpdev  -d /tmp/dump 
这会在系统崩溃后试图将转储从 /dev/hd6 复制到 /tmp/dump。如果在复制过程中出现了错误，那么系统继续引导，但是丢失了转储。
指定系统崩溃后转储所要复制其上的目录，如果转储设备是 /dev/hd6，输入：
#sysdumpdev  -D /tmp/dump
这会在崩溃后尝试将转储从 /dev/hd6 复制到 /tmp/dump 目录。如果复制失败，那么会提示您一个菜单以允许手工将转储复制到某个外部介质。

errpt报错E87EF1BE的解决方案

E87EF1BE   0926082807 P O dumpcheck      The largest dump device is too small.
信息.断定为存放dump文件的lg_dumplv容量不够.一般推荐的 dump device 值大小为 sysdumpdev –e 估计值的 1.5 倍。
需要扩容.扩容步骤如下:
1.查看lg_dumplv大小的估计值
#sysdumpdev -e
0453-041 Estimated dump size in bytes: 1287651328 
即1.2G
2.现在lg_dumplv大小
#lslv lg_dumplv 
其中PP SIZE:        256 megabyte(s)
       PPs:            4
经计算,现在容量为1G.需要扩容0.2G

3.查看lg_dumplv所在的vg的容量是否够用
 #lsvg rootvg 
  其中 PP SIZE:        256 megabyte(s)
         TOTAL PPs:      1092 (279552 megabytes)
         FREE PPs:       826 (211456 megabytes)
经计算,vg剩余容量为206.5G,因为根盘做了镜像.故,可用剩余容量为103G左右.因pp size为256m,故扩容2pps,即0.5G(其实扩1个pp也可以.2个放心点.)
4.扩容操作
 #extendlv lg_dumplv 2 
如果是PAGING空间的DUMP话，应该 #chps -s n hd6 (n为多少LP）
5.检查当前lg_dumplv的大小.
  #lslv lg_dumplv 
  其中 PP SIZE:        256 megabyte(s)
         PPs:            6
即,现在容量为1.5G.
6.使用dumpcheck命令查看,是否还出现errpt信息
  #/usr/lib/ras/dumpcheck
  #errpt
不出现,则为成功.

参考至:《走进IBM小型机世界》Orian著

http://www.kuqin.com/aixcmds/aixcmds5/sysdumpdev.htm

http://tech.cncms.com/os/unix/83840.html

http://jbweng.blog.163.com/blog/static/677153320101114101013796/

http://www.ibm.com/developerworks/cn/aix/library/0806_chench_core/#2. 应用进程 core dump 分析 |outline