这是Oracle 11.2.0.4（AIX平台）已知Bug导致的osysmond.bin内存泄漏现象，非配置问题；对应Bug 18701017（每小时泄漏0.23MB）和10165314（crfclust.bdb膨胀），11.2.0.4无官方补丁，临时方案是停用ora.crf并清理CHM数据文件。
crsctl check crs 显示正常但 ps 发现 osysmond.bin 内存持续上涨
这是 oracle 11.2.0.4（尤其 aix 平台）上典型的内存泄漏现象，不是配置问题，而是已知 bug。osysmond.bin 是 cluster health monitor（chm）的采集进程，本应轻量运行，但在某些版本中会每小时泄漏约 0.23 mb 内存，长期不处理可累积至数 gb —— 这正是你看到虚拟内存（vsz）或常驻内存（rss）异常飙高的直接原因。
关键判断点：
- ps aux | sort -rn +3 | head -5 排出前几名里反复出现 osysmond.bin
- 进程启动后内存随时间线性增长，重启后归零又开始涨
- crsctl check crs 全部返回 CRS-4xxx 正常码，说明 CRS 核心服务本身无故障
确认是否触发 Bug 18701017 或 10165314
这两个补丁号对应不同表现但同源：
- Bug 18701017：AIX 上 osysmond.bin 内存泄漏（官方确认，12.1 才修复，11.2.0.4 无官方补丁）
- Bug 10165314：导致 crfclust.bdb 文件无限膨胀，间接加重 osysmond.bin 负载和内存压力
验证方式：
- 查看 $GI_HOME/crf/db/ 下是否存在超大 crf*.bdb 或 *.ldb 文件（如 >500MB）
- 运行 crsctl stat res ora.crf -init -t 确认该资源处于 ONLINE 状态且未报错
- 检查 MOS 文档 ID 18701017 和 10165314 是否与你的平台（AIX 7.1 + 11.2.0.4）匹配
临时止血：停掉 ora.crf 并清理 CHM 数据文件
这不是“关闭监控”，而是规避已知缺陷的必要操作。停用后 CHM 不再采集，但 CRS、CSS、CRSD 等核心高可用功能完全不受影响。
执行顺序必须严格：
- 先确认当前状态：
crsctl stat res ora.crf -init -t - 停止服务：
$GI_HOME/bin/crsctl stop res ora.crf -init - 清理文件：
rm $GI_HOME/crf/db/*/crf*.bdb $GI_HOME/crf/db/*/$(hostname).ldb - 重启服务：
$GI_HOME/bin/crsctl start res ora.crf -init
注意：
- 不要手动删 crf 目录本身，只删其中的 .bdb 和 .ldb
- 若 crsctl start 失败，检查 ohasd 是否运行（ps -ef | grep ohasd），必要时重启 OHAS
为什么不能只调小 memory_target 或 SGA 参数
这类参数控制的是 Oracle 数据库实例的内存，和 osysmond.bin 完全无关。osysmond.bin 是 Grid Infrastructure 层的独立进程，由 ora.crf 资源管理，其内存分配走操作系统 malloc，不受 Oracle 实例内存参数约束。
常见误操作包括：
- 在数据库里执行 alter system set memory_target=... —— 无效
- 修改 /etc/sysctl.conf 的 vm.swappiness —— 可能掩盖症状，但不解决泄漏源
- 试图 kill -9 osysmond.bin 后手动拉起 —— 会被 CRS 自动拉回并继续泄漏
真正有效的动作只有两个：打补丁（11.2.0.4 无官方补丁，需升到 12.1+），或停用 ora.crf 并定期清理数据文件。后者是生产环境最常用、最稳妥的选择。
