AIX的Dump文件学习笔记(原创)

AIX的Dump文件学习笔记(原创)

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