IBM AIX 持续可用性: 第 6 部分

核心提示：AIX 高级连续可用性工具和特性本章详细介绍 AIX 上的一些高级连续可用性工具和特性，其中一些工具和特性是 AIX V6.1 中新增的，IBM AIX 持续可用性: 第 6 部分，其他工具和特性是最近引入的，还有一些工具是从较早的 AIX V5.3开始出现的， 注意：mdmprpt 命令需要一个原始错误日志文件；它不

AIX 高级连续可用性工具和特性

本章详细介绍 AIX 上的一些高级连续可用性工具和特性。其中一些工具和特性是 AIX V6.1 中新增的。其他工具和特性是最近引入的。还有一些工具是从较早的 AIX V5.3开始出现的。

这里讨论以下工具和特性：

RAS 组件层次结构

轻量内存跟踪（LMT）

snap

微转储和新的转储功能

并发更新

POSIX 跟踪

存储键

xmalloc 调试改进

ProbeVue

功能恢复例程（在无须系统停机的情况下处理内核问题）

AIX 可靠性、可用性和可服务性组件层次结构

高级连续可用性工具和特性可以被看作可靠性、可用性和可服务性（RAS）工具或特性。开发这些功能是为了帮助研究应用程序、组件或子系统的故障和问题，并避免执行完整的系统转储或者停止应用程序或系统。

一些特性使用 RAS 组件层次结构。这把系统划分为一个资源层次结构，可以把 RAS 命令定向到系统的特定部分。使用 RAS 组件层次结构的 RAS 特性是运行时检查、组件跟踪和组件转储。图 1 显示这个分组层次结构。

图 1 组件可靠性、可用性和可服务性

First Failure Data Capture 特性

轻量内存跟踪用来为 First Failure Data Capture（FFDC）提供信息。它是在 AIX Version V5.3 ML3 中引入的。First Failure Data Capture 特性集在 AIX V5.3 TL5 和 AIX 6.1 中得到了进一步扩展。这些特性包括：

Lightweight Memory Trace（轻量内存跟踪，LMT）

Run-Time Error Checking（运行时错误检查，RTEC）

Component Trace（组件跟踪，CT）

Live Dump（活动转储）

这些特性在默认情况下是启用的，可以提供有价值的 First Failure Data Capture 信息，同时保持最低的性能影响。要想启用或禁用所有四个高级 FFDC 特性，应该输入以下命令：

/usr/lib/ras/ffdcctrl -o ffdc=enabled -o bosboot=no

使用快速路径 smitty ffdc 访问 SMIT FFDC 菜单，见示例 1。

示例 1 高级 FFDC 特性

Advanced First Failure Data Capture Features
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Advanced First Failure Data Capture Features [enabled] +
Run bosboot automatically [no] +
F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

关于 FFDC 的更多信息，请参考 IBM eServer p5 590 and 595 System Handbook（SG24-9119）。

轻量内存跟踪

本节描述如何使用轻量内存跟踪（LMT）。轻量内存跟踪是一种可服务性特性。它是一种重要的 First Failure Data Capture 工具，主要供那些可以访问 AIX 源代码或对 AIX 内部原理有深入了解的用户使用。

LMT 实现

轻量内存跟踪（LMT）为 First Failure Data Capture（FFDC）提供跟踪信息。它是一种持续的内核跟踪机制，可以记录在系统操作期间发生的软件事件。系统在初始化时启动 LMT，然后连续运行跟踪。记录的事件保存到每个处理器的内存跟踪缓冲区。

对于每个处理器，有两个内存跟踪缓冲区：一个记录常见事件，一个记录罕见的事件。服务人员可以使用 mtrcsave 命令从系统转储提取出这些缓冲区，或者在正在运行的系统上访问它们。可以用 trcrpt 命令查看提取出的内存跟踪缓冲区，其格式在 /etc/trcfmt 文件中定义。

在实现 LMT 时，非常注意性能问题，这使它对性能的影响非常小。它对高强度内核基准测试的吞吐量的影响只有 1%，对于典型的用户工作负载影响更小。LMT 需要占用少量固定内核内存。跟踪缓冲区所需的默认内存量取决于那些影响跟踪记录保留时间的因素。

轻量内存跟踪在几个方面不同于传统 AIX 系统跟踪。首先，它的效率更高。第二，它在默认情况下是启用的，已经作为 First Failure Data Capture 机制做了显式调优。与传统 AIX 系统跟踪不同，不能用 LMT 只选择性地记录特定的 AIX 跟踪钩子 id。在使用 LMT 时，要么记录所有支持 LMT 的钩子，要么都不记录。

这意味着传统 AIX 系统跟踪适合作为 Second Failure Data Capture（SFDC）工具，因为可以根据最初故障的相关信息更精确地指定感兴趣的跟踪钩子。

传统 AIX 系统跟踪还允许把跟踪信息自动地写到磁盘文件中（比如 /var/adm/ras/trcfile）。轻量内存跟踪没有提供在内存跟踪缓冲区满了时把跟踪信息自动地写到磁盘的选项。如果 LMT 内存跟踪缓冲区满了，它会 “回绕”，这意味着会覆盖最旧的跟踪记录。

LMT 的优点是能够查看在探测到故障之前系统正在做什么。正如前面提到的，每个 CPU 有一个用于常见事件的内存跟踪缓冲区，还有一个用于罕见事件的比较小的内存跟踪缓冲区。

“常见” 缓冲区的目的是保留事件记录一到两秒（换句话说，它的空间足以记录前一到两秒内发生的事件）。“罕见” 缓冲区应该保留事件记录至少一小时。这取决于工作负载、开发人员在 AIX 内核源代码中设置跟踪钩子调用的位置以及跟踪的参数。

启用和禁用轻量内存跟踪

可以用以下命令禁用轻量内存跟踪：

/usr/bin/raso -r -o mtrc_enabled=0

可以用以下命令启用轻量内存跟踪：

/usr/bin/raso -r -o mtrc_enabled=1

注意：在这两种情况下，都必须重新构建引导映像（需要运行 bosboot 命令），修改在下一次重新引导后才会生效。

轻量内存跟踪内存消耗

内存跟踪缓冲区所需的默认内存量是根据那些影响软件跟踪记录保留时间的因素自动计算出来的，从而提供足够大的缓冲区来满足前面提到的保留时间目标。

有几个因素可能减少自动使用的内存量。这个计算在 32 位（unix_mp）和 64 位（unix_64）内核之间有细微的差异。对于 64 位内核，默认计算受到限制：LMT 使用的内存不能超过系统内存的 1/128，单一处理器使用的内存不能超过 256 MB。

32 位内核使用相同的默认内存缓冲区大小计算方法，但是多了一项限制：分配给 LMT（包括所有处理器）的总内存最多 16 MB。表 1 给出几个 LMT 内存消耗示例。

表 1 轻量内存跟踪内存消耗

机器	CPU 数量	系统内存	LMT 总内存：64 位内核	LMT 总内存：32 位内核
POWER3（375 MHz CPU）	1	1 GB	8 MB	8 MB
POWER3（375 MHz CPU）	2	4 GB	16 MB	16 MB
POWER5（1656 MHz CPU共享的处理器 LPAR，60% ent cap，并发多线程）	8 逻辑	16 GB	120 MB	16 MB
POWER5（1656 MHz CPU）	16	64 GB	512 MB	16 MB

输入以下 shell 命令判断 LMT 使用的总内存量（以字节为单位）：

echo mtrc | kdb | grep mt_total_memory

对于 POWER4 和更高级的系统，在发生动态配置事件时，64 位内核会重新计算 LMT 跟踪缓冲区的大小。32 位内核不会调整缓冲区大小；它会继续使用在系统初始化期间计算出的缓冲区大小。

注意：对于这两种内核，当增加一个 CPU 时，固定内存可能不足以分配给 LMT 缓冲区，那么 CPU 分配就会失败。这个错误由 AIX 错误日志中的 CPU_ALLOC_ABORTED 记录表示，详细数据中的 Abort Cause 是 0000 0008（LMT），Abort Data 是 0000 0000 0000 000C（ENOMEM）。

修改内存缓冲区大小

对于 64 位内核，还可以使用 /usr/sbin/raso 命令增加或减少内存跟踪缓冲区大小。这个命令会修改 mtrc_commonbufsize 和 mtrc_rarebufsize 可调优变量。这两个变量是动态参数，所以修改它们不需要重新引导。

例如，要想把每个 CPU 的罕见缓冲区大小设置为 16 个 4 K 页面，应该输入以下命令：

raso -p -o mtrc_rarebufsize=16

关于内存跟踪缓冲区大小调优的更多信息，请参考 raso 命令的文档。

注意：在内部，在任何 64 位内核缓冲区大小调整操作期间，LMT 跟踪会临时暂停。

对于 32 位内核，只能接受默认的（自动计算出的）缓冲区大小，或者禁用 LMT（完全避免缓冲区分配）。

使用轻量内存跟踪

本节描述利用轻量内存跟踪捕捉的信息的各种命令。但是，请牢记，LMT 是为 IBM 服务人员设计的，所以在标准 AIX 文档中没有解释这些命令（以及与 LMT 相关的新参数）。所以，为了帮助用户了解命令的语法，在输入 <command -?> 时，每个命令都会显示使用方法。本节只概述用来操作 LMT 的命令。

LMT 内存跟踪缓冲区被包含在 AIX 系统转储中。可以按照与传统 AIX 系统跟踪缓冲区相似的方法操作它们。最容易的方法是使用 trcdead 命令从转储中提取出 LMT 缓冲区。新的 -M 参数可以把缓冲区解压到 LMT 日志目录中的文件中。默认的 LMT 日志目录是 /var/adm/ras/mtrcdir。

如果转储是压缩的，那么在运行 kdb 之前需要先用 dmpuncompress 命令对转储文件进行解压，如下所示：

dmpuncompress dump_file_copy.BZ

例如，要想从转储映像 dump_file_copy 中提取出 LMT 缓冲区，可以使用：

trcdead -M dump_file_copy

每个缓冲区被提取到一个单独的文件中，每个缓冲区类型还有一个控制文件。这与传统 AIX 系统跟踪中的每 CPU 跟踪选项相似。例如，如果对两处理器系统的转储执行前面的命令，就会创建以下文件：

ls /var/adm/ras/mtrcdir
mtrccommon mtrccommon-1 mtrcrare-0
mtrccommon-0 mtrcrare mtrcrare-1

然后，可以使用 trcrpt 命令的新参数 -M 决定提取的文件的内容格式。trcrpt 命令允许分别查看常见文件和罕见文件。从 AIX V5.3 TL5 开始，可以按照时间次序把常见文件和罕见文件合并在一起。

继续前面的示例，要想查看从转储文件中提取出的 LMT 文件，可以使用：

trcrpt -M common

和

trcrpt -M rare

这些命令会产生大量输出，因此建议使用 -o 选项把输出保存到文件中。

在使用 -M 标志的同时，可以使用其他 trcrpt 参数限制显示的内容。例如，可以使用以下命令只显示 CPU 1 上的 VMM 跟踪事件组钩子 id：

trcrpt -D vmm -C 1 -M common

示例 2 给出显示 VMM 跟踪的 trcrpt 命令的输出：

示例 2 trcrpt 命令的输出

# trcrpt -D vmm -C 1 -M common
ID CPU ELAPSED_SEC DELTA_MSEC APPL SYSCALL KERNEL INTERRUPT
1BE 1 141.427476136 141427.476136 VMM pfendout: V.S=0020.31250 ppage=32B20
client_segment commit in progress privatt
P_DEFAULT 4K
large modlist req（type 0）error=0000

使用 trcrpt 命令是最容易最灵活的查看轻量内存跟踪记录的方法。

snap 命令

snap 命令收集 AIX 系统配置信息、错误日志数据、内核信息和系统转储（如果有的话）。这些信息被压缩为一个 pax 文件。然后，可以把这个文件写到磁带或 DVD 等设备，或者传输给远程系统。snap 命令收集的信息可能有助于识别和解决系统问题。/tmp/ibmsupt 目录包含 snap 命令的输出。

注意：snap 命令收集的信息是供 IBM 服务人员使用的。

snap 使用示例

使用以下命令收集所有系统配置信息：

snap -a

这个命令的输出被写到 /tmp/ibmsupt 目录中。

使用以下命令为 /tmp/ibmsupt 目录中包含的所有文件创建一个 pax 映像：

snap -c

使用以下命令删除 /tmp/ibmsupt 目录中的 snap 命令输出：

snap -r

我们建议按照以下次序运行 snap 命令：

1. 删除 /tmp/ibmsupt 目录中旧的 snap 命令输出：

snap -r

2. 收集所有新的系统配置信息：

snap -a

3. 为 /tmp/ibmsupt 目录中包含的所有文件创建一个 pax 映像：

snap -c

可以在 snap 命令中使用其他几个标志收集相关的系统信息。更多信息参见 snap 手册页：

man snap

微转储功能

系统转储可能由于各种原因无法成功完成。如果在系统崩溃时没有收集转储，往往很难判断崩溃的原因。为了解决这个问题，在 AIX V5.3 ML3 中引入了微转储功能。

微转储是一个小型压缩转储，它在系统崩溃或启动转储时被存储到 NVRAM 中。然后，在重新引导时被写到错误日志中。在完全转储不可用的情况下，可以通过它了解系统状态并进行某些调试。还可以用它快速获取系统崩溃时的快照，而不需要从崩溃的系统获取完整的转储。

微转储显示为错误日志记录，其标签是 MINIDUMP_LOG，描述为 COMPRESSED MINIMAL DUMP。

使用以下命令只显示错误日志中的微转储记录（另外参见示例 3）：

errpt –J MINIDUMP_LOG

微转储格式化器

新命令 mdmprpt 提供微转储格式化功能。这个命令的语法如下：

mdmprpt [-i logfile] [-l seqno] [-r]

如果给出一个序号（seqno），mdmprpt 命令就会显示具有这个序号的微转储。否则，它会显示错误日志中最近的微转储（如果有的话）。它从错误日志中读取对应的微转储记录并解压详细数据。然后，把数据格式化为人可读的输出并发送到 stdout。格式化的输出首先显示症状字符串和其他标题信息。然后显示最近的错误日志记录、转储错误信息（如果有的话）以及每个 CPU 的完整堆栈（包括对应的局部变量、函数名和偏移量）。

注意以下几个要点：

可以使用 –i 标志提供另一个错误日志文件。

使用 –l 标志，后面加上微转储的错误日志记录的序号，就可以显示最近的微转储之外的其他微转储。

使用 –r 标志显示原来保存在 NVRAM 中的原始数据，这不需要解压或格式化。一般来说，这只对调试微转储本身的问题有帮助。

mdmprpt 命令使用未压缩的微转储标题信息对其余部分进行解压和格式化。对于用户发起的转储，会在所有 CPU 上平均地收集数据，因为不知道故障点在哪里。

NVRAM 的大小非常有限，所以系统上的 CPU 越多，为每个 CPU 收集的数据就越少。对于崩溃后的转储，来自崩溃的 CPU 的数据将占用 NVRAM 空间的大部分，其余空间分给其他 CPU。

注意：mdmprpt 命令需要一个原始错误日志文件；它不能处理 errpt 命令的输出。

示例 3 显示一个微转储的部分输出。–g 标志让 snap 收集错误日志文件。

示例 3 微转储的部分输出

# errpt -J MINIDUMP_LOG
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
F48137AC 1002144807 U O minidump COMPRESSED MINIMAL DUMP
# mdmprpt |more
MINIDUMP VERSION 4D32
***************************************************
64-bit Kernel, 10 Entries
Last Error Log Entry:
Error ID: A924A5FC Resource Name: SYSPROC
Detail Data: 0000000600000000 0004A09800000004
000000042F766172 2F61646D2F726173
2F636F7265000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 0000000000000000
0000000000000000 00000000736C6565
7000000000000000 0000000000000000
0000000000000000 0000000000007473
7461727420314630 0A00000000000000
0000000000000000 0000000000000020
2068775F6672755F 69643A204E2F410A
202068775F637075 5F69643A204E2F41
0A00000000000000 0000000000000000
00006E736C656570 203235340A3F3F0A
736C656570203843 0A6D61696E203138
340A5F5F73746172 742036430AFFDC00
0100000000000000 0700000003353736
3545363230300000 0000043532300000
0000105350493200 00000023736C6565
70000000002B0000 0006000000236E73
6C65657000000000 2900000254
Symptom Information:
Crash Location: [000000000042E80C] unknown
Component: COMP Exception Type: 267
Data From CPU #0
***************************************************
MST State:
R0: 000000000018F3E0 R1: F00000002FF46B80 R2: 0000000002C159B0
R3: 00000000000110EE R4: 0000000000000004 R5: 00000000FFFFFFFE
R6: 0000000000010000 R7: 0000000000000100 R8: 0000000000000106