如何处理ASM实例挂起_strace跟踪后台进程与OS层I/O排查-Oracle-PHP中文网

ASM挂起时应attach主进程ora_asm+pid而非辅助进程，用strace -p PID -e trace=io,desc,process -T -s 128聚焦I/O调用；重点关注io_getevents超时、ioctl失败及openat返回ENXIO，结合multipath、udev和/proc/diskstats排查存储链路异常。

ASM实例挂起时怎么用 `strace` 跟踪后台进程

直接 attach 到 asm 的关键后台进程（比如 ora_asm+pid 或 ora_asm_instance_name）是可行的，但必须选对进程、避开 oracle 内部信号干扰。

常见错误是 strace 所有 asm 进程，结果卡在 semop 或 io_getevents 上，误判为 I/O 卡死——其实只是 Oracle 在等 ASM 实例内部同步信号。

优先 attach ora_asm+pid（如 ora_asm_+ASM1），它是 ASM 实例主进程，负责协调磁盘组和 ASM 文件操作
避免 attach ora_asm_pid 类型的辅助进程（如 ora_asm_12345），它们常处于 epoll_wait 等待状态，strace 会显示大量重复休眠，无实际诊断价值
使用 strace -p PID -e trace=io,desc,process -T -s 128：只跟踪 I/O、文件描述符和进程调用，-T 显示系统调用耗时，-s 防止路径截断
如果 strace 输出中频繁出现 io_submit 后长时间无 io_getevents 返回，且伴随大量 EAGAIN，说明底层存储响应慢或队列积压

ASM 挂起是否真由 OS 层 I/O 引起

不能只看 iostat -x 1 的 %util 或 await，ASM 挂起更常源于设备路径异常、多路径切换失败、或 udev 规则导致设备名漂移。

典型现象是 crsctl check cluster 正常，但 asmcmd lsdg 卡住，同时 ls -l /dev/oracleasm/disks/ 显示部分盘为 broken 链接或权限异常。

检查 /proc/diskstats 中对应 ASM 磁盘（如 sdb、mpathb）的 rd_sec/wr_sec 是否长期无增长，若为 0 且 strace 显示 io_submit 成功但无完成事件，大概率是存储链路中断而非性能瓶颈
运行 multipath -ll 看路径状态，如果某条路径显示 failed 或 shaky，而 ASM 正在尝试通过该路径重试 I/O，就会表现为“挂起”而非报错
确认 /dev/oracleasm/disks/ 下的盘是否全部指向真实块设备（ls -l 看 target），udev 规则若未固定 WWID，重启后可能映射错盘，ASM 尝试读取错误设备会静默等待超时

`strace` 输出里哪些系统调用值得重点盯

不是所有系统调用都相关。ASM 对 I/O 的封装很深，真正暴露问题的往往是底层异步接口和设备控制调用。

重点关注三类调用：异步 I/O 完成等待、设备控制命令、文件描述符状态变更。忽略大量 gettimeofday、clock_gettime 和 rt_sigreturn ——它们是 Oracle 自身调度开销，非故障根源。

io_getevents：返回值为 0 且持续超时（>10s），说明异步 I/O 提交后底层无响应，需立刻查存储链路或驱动
ioctl 调用中含 BLKGETSIZE64 或 SG_IO：若返回 EIO 或卡住，表示 ASM 正在探测磁盘容量或发送 SCSI 命令失败，常见于 LUN 不可见或 ACL 未配置
openat 或 open 返回 ENXIO 或 ENODEV：说明 ASM 尝试打开某个 disk path 失败，对应路径已失效，但 ASM 还未触发 failover 逻辑

为什么有时 `strace` 一加就“恢复”，一停又挂

这不是幻觉。strace 本身会强制改变进程调度行为：它让被 trace 进程进入 ptrace_stop 状态，打断 Oracle 的内部超时重试循环；当 strace 退出，进程恢复执行，但某些未清理的等待状态（如未清除的 io_context）会导致后续 I/O 请求直接阻塞。

这往往说明 ASM 已进入某种不一致等待态，比如一个 disk group 的 discovery 过程卡在中间步骤，既没成功也没失败，strace 的介入恰好“重置”了局部状态。

遇到这种情况，不要反复启停 strace，先保存当前 oradebug dump systemstate 266 和 oradebug dump asmsystemstate 1 转储
检查 Alert.log 中最近 5 分钟是否有 ORA-15078（disk group force dismount）、ORA-15196（ASM block corruption）或 ORA-15335（ASM metadata I/O error）
若 strace 停止后立即挂起，且 ps -eo pid,comm,wchan | grep asm_pid 显示 wchan 为 io_schedule 或 do_io，基本可判定是内核层 I/O 子系统异常，需联系存储厂商并收集 dmesg -T 输出

事情说清了就结束