如何分析AWR主机负载_Host CPU、内存分页与Swap交换区活动-Oracle-PHP中文网

AWR中判断CPU是否真高需计算BUSY_TIME/(BUSY_TIME+IDLE_TIME)占比，而非单看绝对值；IOWAIT_TIME飙升、LOAD持续超NUM_CPUS、PI/PO频繁交换、Active(anon)断崖下跌等才是真实瓶颈信号。

看懂 AWR 里的 Host CPU 使用是否真高

awr 报告里 busy_time 和 idle_time 看着高或低，不能直接等价于“cpu 瓶颈”。关键得算占比：busy_time / (busy_time + idle_time) 才是真实 cpu 利用率。比如你看到 busy_time=12,933,418、idle_time=269,466,546，实际利用率仅约 4.6%，远没到警戒线（通常 >80% 才需干预）。

容易踩的坑：

DB CPU 等待事件高 ≠ 主机 CPU 高——它只反映数据库进程在 CPU 上执行的时间，但主机可能还有大量非 Oracle 进程（如备份脚本、监控 agent）在抢资源，这部分不会体现在 DB CPU 里
忽略 IOWAIT_TIME：如果它突然飙升（比如从几十升到上万），即使 BUSY_TIME 不高，也说明 CPU 大量时间在等磁盘，本质是 I/O 卡住导致的“假性空闲”
不比对 LOAD：AWR 的 LOAD 值（如从 4 升到 9）反映的是运行队列长度，若持续 > CPU 核数（NUM_CPUS=112），哪怕 CPU 利用率才 30%，也可能出现任务排队、响应延迟

识别内存分页（paging）是否已成问题

真正危险的信号不是“用了 Swap”，而是“正在频繁换入换出”——这在 AWR 的 Operating System Statistics 里体现为 PI（page in）和 PO（page out）持续非零，尤其当它们数值接近或超过每秒百 KB 级别时，说明内核正疲于奔命地搬数据。

常见错误现象：

误把 SWAP_FREE_BYTES=68,719,472,640（64GB）当成“内存很充裕”——其实只要 PI/PO 在动，就代表物理内存已不够用，只是 Swap 空间还没耗尽
忽略 INACTIVE_MEMORY_BYTES 走势：如果它持续减少而 FREE_MEMORY_BYTES 没同步上升，大概率是内存被进程长期 hold 住（比如 PGA 泄漏、未释放的大对象），而非真正释放了
在 Linux/AIX 上查不到具体谁在换页：AWR 不提供进程级 Swap 使用明细，必须结合 /proc/$pid/smaps 中的 Swap: 行或 smem -s swap 手动定位

Swap 活动与 Oracle 内存参数的隐性冲突

Oracle 实例若启用了 AMM（memory_target）或 ASMM（sga_target），而主机又开了 Swap，就可能出现“Oracle 想扩 SGA，系统却把刚分配的页 swapped out”的恶性循环。这不是配置错，而是内核 OOM killer 和 Oracle 内存管理策略的底层博弈。

实操建议：

检查当前模式：SELECT CASE WHEN mt.value>0 THEN 'AMM' WHEN st.value>0 THEN 'ASMM' ELSE 'manual' END FROM v$parameter mt, v$parameter st WHERE mt.name='memory_target' AND st.name='sga_target'
若用 AMM，务必禁用大页（use_large_pages=FALSE）——否则 AMM 会绕过大页机制，反而加剧分页
确认 vm.swappiness 值：Linux 默认是 60，对数据库应设为 1 或 0（仅在绝对必要时 swap），避免内核主动回收 Oracle 进程页
不要只看 PGA_AGGREGATE_TARGET：当 V$PGASTAT 中 bytes processed 远大于 cache hit percentage，说明大量排序/哈希被迫落盘，间接推高 Swap 活动

跨平台验证：从 AWR 跳到主机命令补全真相

AWR 是快照，有滞后性；主机命令是实时毛刺探测器。两者必须交叉验证，否则你会在“报告说一切正常”和“用户喊慢”之间反复横跳。

对应关系要记牢：

AIX 的 vmstat 1 5 输出中，pi/po 列 ≈ AWR 的 PI/PO；avm 持续 > 物理内存 80% 且 fre svmon -G
Linux 的 esxtop（ESXi）或 top（按 f → 选 SWAP 字段）能直接看到每个 oracle 进程的 Swap 使用量，比 AWR 精确到进程级
Windows 任务管理器“性能”页的“提交大小”减去“内存使用量”≈ 当前 Swap 占用，若该值 > 2GB 且增长快，别信 AWR 里那句“SWAP_FREE_BYTES 充足”

最常被忽略的一点：AWR 不采集 /proc/meminfo 中的 Inactive(file) 和 Active(anon)，而这俩才是判断 Oracle SGA 是否被内核当作“可回收缓存”干掉的关键证据——一旦 Active(anon) 断崖下跌，基本就是 SGA 被悄悄 swap out 了。