当前位置：首页 > news >正文

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

news 2025/10/13 7:18:36

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 的两种可能：
1. 正常守护进程：系统服务在启动时主动设计为由 init 进程（PID 1）直接管理，这是正常且推荐的做法（如 sshd、nginx 等系统服务）
2. 孤儿进程：原本有父进程，但父进程意外退出/崩溃后，这些"孤儿"被 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 孤儿进程的常见诱因：

场景类别	具体诱因	典型表现	识别特征
作业异常中止	调度超时强杀 / 人工 Ctrl+C	PPID=1，近期 STIME	单个或少量进程
引擎组件故障	DataStage Engine 崩溃 / 网络抖动	大量同批次残留	多进程同 STIME
资源死锁	FIFO 阻塞 / 字符集转换卡死	长 TIME，低/零 CPU	进程存活但无 CPU 波动
调度配置缺陷	重复拉起未清理 / 缺少退出钩子	同名作业多进程	同 Job 多个 `RT_SCxxxx` 目录
文件系统故障	NFS 挂载点失联 / 磁盘 I/O 错误	进程卡在 D 状态（不可中断）	`ps` 显示 STAT=D