AIX 服务器 CPU 长期 90%：从 nmon 画像到 DataStage 僵尸进程的定位与清理

AIX 服务器 CPU 长期 90%：从 nmon 画像到 DataStage 僵尸进程的定位与清理

1. 事件摘要

• 现象：AIX 服务器 CPU 长期 ~90%，ETL 跑批无法按时完成
• 证据：nmon 一天画像 + topas 实时监控，前列进程显示为 uvsh/phantom（Owner 多为 dsadm）
• 定位：通过 ps -fp <PID> 取证，确认为 IBM DataStage 相关的 phantom + DSD.OshMonitor/oshWrapper 进程，且 PPID=1（孤儿）、运行时间极长，属僵尸/残留
• 处置：批量列出并有序清理孤儿 phantom（确认作业不在运行后 kill -9）
• 结果：第二天跑批总时长缩短约 1 小时，CPU 使用恢复正常区间

快速自查清单（5分钟版）

遇到 AIX 服务器 CPU 持续高占用时，按此顺序检查：

• topas 确认高 CPU 进程的 Owner 是谁？
• 是 dsadm 且进程名含 phantom/osh/uvsh？→ 90% 是本文场景
• ps -fp <PID> 确认 PPID 是否 = 1？
• TIME 列是否异常长（天级/月级）？
• 都符合？→ 执行进程清理

不符合？ → 考虑其他场景（应用程序 Bug/死循环/外部攻击等）

2. 背景与症状：从全局监控到精确定位

2.1 系统级画像

用 nmon 采集一天资源曲线，确认 CPU 长时处高位，磁盘与内存压力无异常峰值伴随 → 初步判断为计算密集或空转。

2.2 实时放大

topas 2s 间隔观察，多条进程各占 7%~9% CPU，累计接近总使用率。列表中反复出现 uvsh / phantom，用户为 dsadm（典型 DataStage 引擎账号）。

要点：先总后分。nmon 判"是否真高"、topas 找"谁在高"。

3. 取证与定位：从"看名字"到"拿证据"

3.1 直接按进程名搜索失败的原因

• 现象：ps -ef | grep -i uvsh、ps -ef | grep dsadm 一度查不到（或名字不一致）
• 原因：
  • topas 的 Name 列可能是可执行短名或被截断显示
  • DataStage 并行引擎父子进程层级复杂，常由 phantom/osh/oshWrapper 拉起，uvsh 在不同视图下显示不一
  • 部分"残留/半僵尸"在 /proc 下信息不完整，ps 行为不稳定（个案）

补充说明：这也是为什么排障时"从 topas 抓 PID，再用 ps -fp 反查"比"grep 进程名"更可靠——PID 是唯一且稳定的标识符。

3.2 用 PID 反查拿到"铁证"

对 topas 里高 CPU 的 PID，逐个执行：

ps -fp <PID> # 取 UID/PID/PPID/C/TIME/CMD
procmap <PID> | head # 必要时确认可执行路径

关键发现：

phantom DSD.OshMonitor DS_CORE_BDPAL_UNION_10 … # 进程命令
PPID=1 # 父进程 ID 为 1
TIME=607071:09 / 519476:38 # 极长运行时间

以及典型命令行：

/opt/IBM/InformationServer/Server/DSEngine/bin/oshWrapper RT_SCxxxx/… \\
-impexp_charset ASCL_MS936 -input_charset UTF-8 -output_charset UTF-8 …

3.3 这说明了什么

• 产品归属：IBM InfoSphere DataStage 并行引擎（Parallel Engine）

• 角色：

  • phantom：DataStage 后台执行/监控进程
  • DSD.OshMonitor：并行作业运行状态监视器
  • osh/oshWrapper：并行作业执行外壳
  • RT_SCxxxx：Job 编译生成的运行目录
  • 参数中的 charset：说明作业涉及文件导入/导出与字符集转换

• 状态判断：

  关于 PPID=1 的两种可能：

• 正常守护进程：系统服务在启动时主动设计为由 init 进程（PID 1）直接管理，这是正常且推荐的做法（如 sshd、nginx 等系统服务）
• 孤儿进程：原本有父进程，但父进程意外退出/崩溃后，这些"孤儿"被 init 进程自动收养，PPID 从原来的值变成 1

本案例中的判断依据：

• ✅ PPID=1：父进程已不存在
• ✅ TIME 极长：显然超出任何正常作业的运行时长
• ✅ 持续高 CPU 占用：空转消耗资源
• ✅ 命令行特征：指向 DataStage 作业执行进程

综合以上特征，可以确认这些 phantom/oshWrapper 进程属于孤儿进程（作业早已结束/异常，进程未正常退出），而非正常的系统守护进程。

结论：CPU 高占用的"元凶"是残留的 DataStage phantom/oshWrapper 孤儿进程，它们在作业异常中止后未被正确清理，持续空转耗 CPU。

4. 处置与验证：安全、有序地"摘除噪音"

4.1 列表化目标

ps -fu dsadm | grep phantom | grep -v grep
#ps -fu dsadm # 以完整格式显示 dsadm 用户的所有进程
#grep -v grep # 排除包含 "grep" 的行

聚焦两类特征：

• PPID=1（孤儿）
• TIME 或 STIME 显著异常、C（CPU%）长时间不低

4.2 清理操作

kill -9 <PID>

4.3 复核系统状态

topas # 实时查看 CPU 是否下降

4.4 结果

• 同日 CPU 负载显著下降
• 次日跑批总时长缩短约 1 小时，符合"清除了无效 CPU 占用"的预期

5. 复盘：僵尸进程产生的典型场景

高 CPU 未必是"单一大进程"，也可能是多条残留进程的总和。下表总结了 DataStage 孤儿进程的常见诱因：

标志性表征（黄金三要素）：