大多数情况下, 顺着报错顺藤摸瓜很快就能找出原因, 但总有例外, 有些报错信息或者日志恰恰让我们南辕北辙. 让我们看看这些案例最终是如何处理的......
案例 1: 图省事, 搞出来个大麻烦
生产中心有几套 VIOS 环境, 正常运行了 1-2 年, 今日发现有 2 套进行健康性检查, 发现执行命令就 hang 在哪里不动了, 又是内存不够用了.
"0403-031 The fork
function failed. There is not enough memory available."
好奇怪, 到底内存被谁用了, vios 好端端的就这样了. 都这个样子, 重启 vios 分区吧. 重启完, vios 顺利登陆, 执行健康性检查没啥问题, 可是用 nmon 看了一下内存使用分配了 4 个 G, 使用 1 个多 G, 慢慢慢慢的就看到内存使用越来越大, 不一会 4 个 G 就用完了, 重启其他 vios 分区一个样子, 连换页空间都用了. 顿时一头雾水. 到底发生了什么呢?
生产中心有几套 VIOS 环境, 正常运行了 1-2 年. 突然出现这种问题, 首先想到的是变更. 梳理了近期变更操作, 近期新部署了 PowerVC,VIOS 进行了补丁升级. VIOS2.1 升级到 VIOS2.2.3.
首先, 重启 vios 分区, 在内存没有用完前赶紧检查那个进程使用的内存.
排名第一的是 vio_daemon, 观察了一会发现内存一会就被他占用完了
第二, 元凶找到了, vio_daemon 到底是干啥的, 问问 IBM800 吧, IBM 回复问我收集一下系统信息.
ioslevel
/etc/security/limits 的输出
反馈后, IBM 告诉我, 我遇到了 bug
vios 版本和 /etc/security/limits stack = -1 完全符合这个 bug 特征.
其实这个 bug 是可以避免的, 我们大多数实施 AIX 的时候, 很容易顺手把 /etc/security/limits. 都改成 - 1, 在大多数情况下, 没啥问题, 但是就是在这个版本下就容易遇到这个问题.
- default:
- fsize = -1
- core = -1
- cpu = -1
- data = -1
- rss = -1
- stack = -1
- nofiles = -1
The problem can be due to a known issue inVIOS 2.2.3.0 thru 2.2.3.3 with vio_daemon having a memory leak that was fixedat 2.2.3.4 with IV64508,or it could be due to incorrect VIOS settings.
Answer
To check your VIOS level, as padmin, run:
$ ioslevel
If your VIOS level is 2.2.3.4 or higher, the problem may be due to the VIOShaving incorrect system settings in /etc/security/limits. If the"stack" size is set to "unlimited" (stack = -1),this exposes a condition where the system can be allowed to pin as much stackas desired causing vio_daemon to consume a lot of memory.
$ oem_setup_env
vi /etc/security/limits ->check thedefault stanza
- default:
- fsize = -1
- core = -1
- cpu = -1
- data = -1
- rss = -1
- stack = -1
- nofiles = -1
In some cases, the issue with vio_daemonconsuming high memory is noticed after a VIOS update to 2.2.3.X. However, aVIOS update will NOT change these settings. It is strongly recommended not tomodify these default values as doing so is known to cause unpredictableresults. Below is an example of the default values:
- default:
- fsize = 2097151
- core = 2097151
- cpu = -1
- data = 262144
- rss = 65536
- stack = 65536
- nofiles = 2000
To correct the problem change the setting back to "default" values.Then reboot the VIOS at your earliest convenience.
案例 2: 装个 AIX, 却装出了信任危机
某制造业用户, 一个新项目着急要上线, 让维保厂商工程师赶紧抓紧准备一个 AIX 资源, 装 AIX 系统按说对 ma 工程师来讲应该轻车熟路, 可是这次装了好几遍, AIX 系统就是进不去.
1 怀疑光盘问题, 更换好几张重装未果, 依旧进不去
2 怀疑 AIX 版本, 更好了两个未果
3 怀疑硬件, 进入 asm 里也没啥报错
首先说下用户设备的背景信息, 设备采购于 2012 年,"天工计划" 中的一款产品 Power710 和 Power730 中的一款, Power710 设备特点: 定位应用服务器, 价格便宜, 也就是不需要 HMC 管理, 使用串口安装的 IVM 部署管理虚拟化环境.
之前这台 710 用作应用服务器. 串口部署过 IVM 环境, 这次重装需要注意串口输出问题.
所以一定要进行如下配置才可以顺利进入系统
第一步: 进入维护模式 如果进入 Maintenance Mode 步骤就省略了
第二步:#export TERM=vt100
# smit chtty
红色标注的两行, 增加 clocal.
- sync
- sync
- sync
- reboot
之后就能顺利进行系统了.
案例 3: 安装 AIX 报出这个错, 新手老手绝对没见过
相信社区大多数人都安装 AIX 几十遍甚至上百遍了, 但是今天安装 AIX 报出这个错, 新手老手绝对没见过
安装 AIX 停在了这里.
其实我也经过了很多各位的排查工作, 最终梳理了一下发现 AIX 安装出问题, 排除硬件介质问题, 多半是配置问题, 那就按照这个思路往下走
首先, 既然是配置就去 profile 文件里看看. 不查不知道, 一查问题果然找到了
有人会说, 你居然犯这么低级的错误. 冤枉啊, 这是 PowerVC 干的怪我背景没说清楚. 这是 PowerVC 部署 aix 出现的问题.
第二, 问题找到了, 那么为什么会出现问题, 部署分区 profile 配置是在 Powervc 设置的, 那就去 Powervc 里找答案吧.
问题出在了这里. PowerVC 纳管了很多主机, 每台主机配置不尽相同, 当初为了省事就配置了 vary 计算模板, 最大 cpu 配置成了 32.
实际部署 AIX 时候, 选择了一台低配的 power 服务器, CPU 配置没有 32, 只有 20 个, 结果被 PowerVC 配置成 25.6. 就这样出现了问题.
反思这个问题, PowerVC, 规划配置模板, 尽量多配置几个计算模板, 与服务器相匹配. 避免此类问题的发生.
通过这个问题还有第二种解法:
kdb 模式下 输入 f, 查看堆栈信息, 也可以顺势查到 profile 配置信息
案例 4: 执行 lsrep, 诡异报出 Insufficient memory
执行 lsrep, 诡异报出 Insufficient memory
检查 vios 分区内存使用情况
似乎跟内存毫无关系.
首先检查了其他 vios 有没有这个问题, 发现均没有此现象发生. 对比 vios 版本及其 lsrep 输出, 发现 vios 版本. 都一样, 唯一不同的是出问题的这个 vios /var/vio/VMLibrary 没有 iso. 把几个 AIX ISO 传到有问题的
这个 vios /var/vio/VMLibrary 下后, 再次执行 lsrep, 成功了
案例 5:PowerHA 给 Oracle 新增表空间, 遭遇 memory croedump
通过 PowerHA 给 Oracle 新增表空间, 使用 C-SPOC 在线添加 LV, 开始给 Datavg 添加, 很顺利, 添加了 10 个很成功, 在继续添加新的 lv 后, 居然报错了. memory croedump.
1, 内存不够用了吗. 看了一下确实有点紧张
hostA:
hostB:
2, 仔细看了一下 Powerha 日志
也没啥有价值的信息
难道真的是内存快用完了导致的.
3, 由于还要给其他 vg 新增 lv, 所以又尝试了一下给其他 vg 添加一下 lv 试试.
居然成功了.
这个问题从内存报错开始容易给人内存不足假象, 实际环境确实也是内存利用率很高, 但是定位最终问题不是内存不足造成的.
首先, 刚开始新增的几个 lv 都顺利, 后几个就失败了, 然后新增其他 vg 的 lv 也成功了, 这个时候就开始怀疑遇到 bug 了.
第二, 一般裸奔的 powerha, 遭遇 bug 的可能性比较大, 检查一下 powerha 补丁情况吧
果然, 基本上就是一个裸奔的 Powerha 环境, 遇到 bug 也就不足为奇了
第三, 既然怀疑是 bug, 那就找点说服力的东西出来. 如下所示
IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEMORY FAULT
A fix is available
Obtain the fix forthis APAR.
Error description
The clpasswdremote utility is core dumping due to
segmentation
fault.
The problem occurs when the user is missing in
/etc/passwd
in one of the nodes in the cluster.
The cspoc.log will log the following:
[========== C_SPOC COMMAND LINE==========]
/usr/es/sbin/cluster/sbin/cl_chpasswd -cspoc-f -r
- -cspoc -grg1 test3
- hacmp13: success:
/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.orig
test3
hacmp14: FAILED: eval clpasswdremote -u test3 -p
- 'raCYOSMwhoJU.' -f 2 -l 0
- hacmp14: cexec[54]: 3735594 Memoryfault(coredump)
- hacmp14: RETURN_CODE=139
- hacmp14: cl_rsh had exit code =139, see cspoc.log
- and/or clcomd.log for more information
- The error report will log a CORE DUMP error with the
- following stack trace:
- main 94
- main 88
- __start 6C
The following symptom code is logged as well:
PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11
- FLDS/main
- VALU/94 FLDS/__start
- Local fix
Ensure that the user exists in /etc/passwd file in all of
the nodes in the cluster.
Problem summary
If a user is not created using cspoc so that it exists on
all nodes in the cluster, then if you try to change that
user's password cluster wide using cspoc, clpasswordremote
will core dump on nodes where the user is not configured.
The smit output will look like:
Changing password for "tstuser"
hack2: cexec 54 : 8781858 Memory fault(coredump)
Problem conclusion
A check was added to clpasswdremote to avoid attempting to
change the password on a node where the user is not defined.
案例 6:V7000 紧急的状态,"紧急" 的处理
使用 PowerVC, 部署 AIX 分区, 结果无法部署, 报了一堆莫名其妙的错误. 怪了前几天还能正常部署. 今天就不能了检查 PowerVC 服务都正常. 登录 HMC 看看有没有建立分区 profile, 发现没有. 无功而返, 返回 PowerVC 继续排查, 到了存储器发现了端倪, 不过看样子挺吓人.
V7000 存储卷运行状况变成了紧急. 登录 V7000 查看, 发现 V7000 没有问题. 那就怪了.
其实 PowerVC 里的关于 V7000 的状态 紧急不能反映 V7000 真正的状态, 而是通信出现了导致. 至于通信出现问题, 事后问网络的人, 我部署的期间, 网络正在变更, 导致 PowerVC 不能下发命令给 V7000,PowerVC 就把 V7000 标记成紧急了.
案例 7: 一次先入为主的异常故障处理!!
一台 P740 服务器通过 SAN 交换机链接一台 DS4700 存储, 在硬件维保商更换一次存储电池 (A 控) 后, 业务中断了.
我司负责数据库以及系统维护, 被客户 CALL 到现场检查问题, 在一番查看后发现 A 控上面所有 LUN 都找不到了, 问题找到后开始排查问题.
询问硬件维保商在更换电池时有没有动到其他东西, 得到了很准确的回答, 我们就换个电池其他啥也没用动. 于是连接存储 SM 把 A 控所有 LUN 切到 B 控, 系统内能看到所有盘, OK 问题在 A 控上面, SM 中看到的存储无报错无问题, 继续把原来 A 控的 LUN 切到 A 控中, 系统又找不到了......
开始删除所有硬盘然后重新识别...... 还是不行......
忙来忙去 两三个小时过去了, 客户在旁边一直说啥时候能搞好啊, 硬件维保商的人没事似的在旁边坐着......
我要去机房看一下, 必须看一下. 客户带着我们下了机房, 然后看了主机以及 HBA 卡连接线, 一切看起来都那么美好. 然后看到了存储 A 控出的那条光纤线......
你妈的插错了!!! 客户用异样的眼光看着硬件维保商......
处理问题切勿先入为主, 任何事要自己确定一下以免有误!!!
案例 8:varyonvg 报错 (LVM 相关) 的分析及处理
AIX 操作系统在做计划内升级操作系统版本变更时, 发现对于 VG 的 varyon 和 varyoff 命令有告警信息, 经分析这只是一个告警信息, 不影响使用, 具体告警信息如下:
系统环境: AIX 5.3 TL12 SP7
首先, 分析当时的报错内容, 从操作内容来看, 可以看到在执行 varyoffvg 命令时底层调用 lqueryvg 子命令时报错, 而 lqueryvg 是一个查询类的命令, 从这个命令的返回内容说明 VG 的定义信息与 VGDA 描述不一致. 对于这类型的告警信息, 重启操作系统时便会自动更新 VG 的相关信息进行自动修正. 而当时计划内的变更是升级操作系统并修改磁盘的 reserve_policy 属性, 因此打完补丁后直接重启操作, 在这个过程中已经把 VG 信息进行了更新.
然后, 分析当时的操作步骤及 LVM 的日志进行验证对应.
当时的操作记录如下, 从操作日志来看, 在重启操作系统前执行过两次 varyoffvg 和一次 varyonvg 的操作:
分析当时的 LVM 的日志, 可以看到第一次 varyoffvg 时出现读取 VG 信息不一致的报错.
在第一次 varyonvg 时出现现样的信息.
在第二次 varyoffvg 时也现现同样的信息.
上面信息是操作系统重启前的信息, 下面分析操作系统重启后 LVM 相关的信息, 从日志中来看, 当操作系统重启后, VG 在 varyon 时返回值为 0, 说明重启过程已经更新了 VG 的信息.
综上所述, 在重启操作系统后已经自动更新 VG 信息, 告警信息已经自动消除.
处理建议: 继续监控.
案例 9: 执行 lspv lsvg -o 等命令时候报错, odm 库修复方法
某公司 4 台机器, 在执行 lspv lsvg -o 等命令时报错如下:
用 strings 命令查看 CuAt 文件, 发现前两行内容不正常, 确定为系统的 ODM 库损坏所致, 通过查看 ODM 库文件的修改时间, 某月某日 10 点 20 分左右有多个 ODM 库文件被修改, 可能被损坏的文件包括 CuAt,CuAt.vc,CuDvdr 三个文件.
尝试修复 ODM 库文件:
方法 1:
1, 用 UE 打开 CuAt 文件, 发现该文件的头信息被篡改, 与正常机器的 CuAt 对比, 损坏的文件体现为该文件的前 7 行内容跟其他 CuAt 文件不一致.
2, 如果要手动修复该文件, 可以将这七行信息按照正常的 CuAt 文件修改, 对于正常的 CuAt 文件来说, CuAt 条目数应该是 32 位 long int 型变量, 第一行 4,5,6,7 列的值表示 CuAt 文件中现有的条目数, odmget 在取值时会参考该数值的大小, 即如果该值为 1, 则只会取到一条记录.
因此如果要修复该文件的话需要知道 CuAt 的确切条目数, 如果将其设置为一个很大的值, 那么在执行 odmget CuAt 之后, 多余的条目会以如下空条目形式显示, 根据该方法可以判断确切的条目数, 再转换为 16 进制写到相应的位置.
方法 2:
1, 对于 HA 环境来说, 每次 verify 成功后, HA 都会保留一份 ha 所用到的 odm 库文件的备份, 位于 / var/hacmp/odmcache/<nodename>/_etc_objrepos 目录, 该备份文件为最后一次有效的 odm 库文件.
2, 我们可以直接找到该文件进行还原, 在备份好 odm 库之后, 可以对涉及到被损坏的文件 CuAt 和 CuAt.vc,CuDvDr 进行在线替换, 替换完之后执行 lspv,lsvg -o 即恢复正常.
来源: http://server.51cto.com/sOS-571483.htm