如何通过AWR评估大页内存使用_分析SGA与OS内存映射的命中效率-Oracle-PHP中文网

查v$sgainfo中Granule Size为4194304（4MB）表明SGA组件已启用大页；结合/proc//maps验证实际大页使用量，避免仅依赖AWR或视图判断。

查 `v$sgainfo` 和 `v$memory_dynamic_components` 看 SGA 实际分配是否启用大页

oracle 启用大页（hugepages）后，sga 不会自动全部落入大页池——它只对满足条件的内存段生效，且依赖启动时的 use_large_pages 参数值。常见错误是看到 /proc/meminfo 里 hugepages_free 有余量，就以为 sga 全部用了大页，其实可能只有 shared pool 或 buffer cache 的一部分进了大页。

use_large_pages=TRUE：强制所有可迁移 SGA 组件尝试用大页，失败则实例启动报错（ORA-27123）
use_large_pages=ONLY：更严格，连 PGA 都不许 fallback，生产环境慎用
查 v$sgainfo 中 Granule Size 字段：若为 4194304（4MB），说明该组件已用大页；若为 8388608（8MB），可能是 x86_64 上的透明大页（THP），但 Oracle 官方不推荐 THP 用于 SGA
v$memory_dynamic_components 的 CURRENT_SIZE 是动态值，但不反映底层页大小；需结合 /proc/<pid>/maps</pid> 手动验证

从 AWR 报告里定位大页未命中根源

AWR 本身不直接统计“大页命中率”，但能间接暴露问题：如果 DB CPU 占比异常高、latch: shared pool 或 latch: library cache 等待陡增，且 Physical Reads 未同步上升，大概率是 TLB miss 导致的页表遍历开销——尤其在 SGA > 16GB 且未配足 HugePages 时。

重点看 AWR 的 Instance Efficiency Percentages 区域：Buffer Nowait % 低于 99.5% 或 Redo NoWait % 下降，常伴随大页碎片化
检查 Shared Pool Memory Statistics：若 Free memory (bytes) 波动剧烈，说明 shared pool 在反复收缩/扩展，而每次 resize 都可能触发非大页内存申请
对比两份 AWR：SGA 调大前后若 parse time elapsed 显著增加，不是 SQL 问题，而是新分配的 shared pool 段没落到大页上

用 `/proc/<pid>/maps</pid>` 和 `grep -i huge` 验证 OS 层映射真实情况

这是最硬的证据。AWR 和视图都是 Oracle 自报，而 /proc/<pid>/maps</pid> 是内核视角的真实内存布局。Oracle 进程（如 ora_smon_<sid></sid>）的 maps 文件里，带 huge 标记的行才是真·大页映射。

先查 Oracle 进程 PID：ps -eo pid,comm | grep pmon → 得到 pmon PID，再用 ps -o ppid= -p <pid></pid> 找到数据库实例主进程 PID
执行：grep -i huge /proc/<pid>/maps | awk '{sum += $2-$1} END {print sum/1024/1024 " MB"}'</pid>，结果即为实际使用的大页内存量
若结果远小于 SGA_TARGET，说明部分 SGA 落在常规 4KB 页上；此时再查 grep -v huge /proc/<pid>/maps | grep rw | awk '{sum += $2-$1} END {print sum/1024/1024 " MB"}'</pid>，这部分就是“危险区”——TLB 压力来源
注意：Linux 透明大页（THP）会在 maps 中显示为 htlb，但 Oracle 对其支持不稳定，建议在内核启动参数中禁用：transparent_hugepage=never

调整 `vm.nr_hugepages` 时必须避开的三个时间点

大页内存是静态预分配的，不能热增。改完 /etc/sysctl.conf 后立即 sysctl -p 并不等于立刻生效——内核要找连续物理内存块，而 Oracle 实例运行中会锁住大量内存页，导致 nr_hugepages 设置失败或静默截断。

重启数据库前必须停掉所有 Oracle 进程（包括 tnslsnr），否则 ipcs -m 里残留的共享内存段会抢占物理页，让 hugepages 分配失败
不要在 AWR 快照生成中（默认每小时整点）改参数，此时 MMAN 进程频繁访问 SGA，容易引发 ORA-27123 或实例挂起
避免在 RMAN 备份期间调整，备份进程会 pin 住 buffer cache 中大量块，大幅降低大页可用连续内存空间
安全做法：在维护窗口先 shutdown immediate → sysctl -w vm.nr_hugepages=<new_value></new_value> → cat /proc/meminfo | grep -i huge 确认生效 → 再 startup