如何分析AWR主机负载_Host CPU、内存分页与Swap交换区活动

AWR中判断CPU是否真高需计算BUSY_TIME/(BUSY_TIMEIDLE_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_time12,933,418、idle_time269,466,546实际利用率仅约 4.6%远没到警戒线通常 80% 才需干预。容易踩的坑DB CPU 等待事件高 ≠ 主机 CPU 高——它只反映数据库进程在 CPU 上执行的时间但主机可能还有大量非 Oracle 进程如备份脚本、监控 agent在抢资源这部分不会体现在 DB CPU 里忽略 IOWAIT_TIME如果它突然飙升比如从几十升到上万即使 BUSY_TIME 不高也说明 CPU 大量时间在等磁盘本质是 I/O 卡住导致的“假性空闲”不比对 LOADAWR 的 LOAD 值如从 4 升到 9反映的是运行队列长度若持续 CPU 核数NUM_CPUS112哪怕 CPU 利用率才 30%也可能出现任务排队、响应延迟识别内存分页paging是否已成问题真正危险的信号不是“用了 Swap”而是“正在频繁换入换出”——这在 AWR 的 Operating System Statistics 里体现为 PIpage in和 POpage out持续非零尤其当它们数值接近或超过每秒百 KB 级别时说明内核正疲于奔命地搬数据。常见错误现象误把 SWAP_FREE_BYTES68,719,472,64064GB当成“内存很充裕”——其实只要 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 实例若启用了 AMMmemory_target或 ASMMsga_target而主机又开了 Swap就可能出现“Oracle 想扩 SGA系统却把刚分配的页 swapped out”的恶性循环。这不是配置错而是内核 OOM killer 和 Oracle 内存管理策略的底层博弈。实操建议 Tellers AI Tellers是一款自动视频编辑工具可以将文本、文章或故事转换为视频。