加入我们的微信群，你将获得不仅仅是知识，还能享受免费最新GPT-4o模型微信机器人+Oracle MOS免费查询+职业发展规划咨询+数据库大佬交流，很多志同道合的小伙伴，欢迎加群一起探讨、学习、进步！“选择”比“努力”更重要。扫描下方二维码添加作者微信，回复“DBA理想”即可开启你的数据库学习之旅。PerLean-AI（www.perleanai.com） 致力于让每一个用户都能无障碍地享受最先进的人工智能技术。我们相信，科技应该为每个人服务，而不是仅限于少数专家。
首先，让我们了解一下系统环境。我们的系统运行在AIX 7.1上，数据库版本为Oracle 11.2.0.4 64bit。
问题描述
之前处理过一个数据库查询速度非常缓慢，尤其是在高峰期。此外，登录AIX系统的速度也很慢，用户在尝试登录时常常需要等待较长时间。登录成功后进一步检查，发现内存占用率非常高。这种异常情况可能影响系统的整体性能和用户体验，需要进行详细的分析和优化。
使用nmon工具插件节点资源使用情况：
内存占用检查
为了找出内存占用过高的原因，我们可以使用以下命令：
ps aux | head -1 ; ps aux | sort -rn +3 | head -10
这个命令首先显示所有进程的标题行，然后按内存使用量从高到低排序并显示前十个进程。通过这种方法，我们可以快速识别哪些程序可能导致系统资源的过度消耗，从而采取相应的措施进行优化或调整。
查找问题进程
接下来，用PID找到具体是什么进程占用过多的内存空间是非常重要的一步。我们可以使用以下命令进行查找：
ps -ef | grep
这样，我们可以进一步了解具体是哪个进程导致了内存使用的异常增加，从而采取相应的措施进行优化或排查。
发现问题
经过检查，我们发现是/u01/app/11.2.0/grid/bin/osysmond.bin
这个服务占用了46%的内存资源。这意味着系统的性能可能会受到影响。为了确保系统的稳定运行，建议进一步分析这个服务的内存使用情况，并考虑采取优化措施，例如重新配置或升级硬件资源，以改善系统的整体性能。
根本原因
通过使用MOS查询，我们发现这是由于RAC osysmond.bin
中的一个bug所引起的内存泄漏问题。进一步分析表明，这个bug导致系统的内存无法正常释放，从而造成了内存的持续占用和消耗。文档 ID 为1549693.1。
详细案例
案例1
在crfmond.log
中，报错信息显示osysmond.bin
无法正常运行，并且遇到了与磁盘相关的错误。
案例2
在orarootagent_root.log
中，osysmond.bin
崩溃，并且没有在crflogd.log
或crfmond.log
中写入任何信息。
产生原因
案例1中，问题是由AIX perfstat_disk()
库调用引起的，这个库调用在某些情况下会导致核心转储。
案例2中，问题是由动态更改CPU数量引起的。目前，osysmond.bin
不支持动态更改配置。
解决办法
案例1
这个问题在Bug 16492284中有报告，并且已作为Bug 14541391的重复项关闭。这个基础Bug在版本11.2.0.4（服务器补丁集）和12.1（基础版本）中已修复。
案例2
在更改任何配置（例如添加/删除CPU、磁盘、网卡）后，重新启动ora.crf
资源：
停止crf
：
/bin/crsctl stop res ora.crf -init
启动crf
：
/bin/crsctl start res ora.crf -init
这个操作不需要CRS或数据库停机。
本次临时解决办法
由于客户没有购买Oracle服务，所以临时解决办法是重启ora.crf
服务，这可以在问题发生时立即恢复系统的正常运行，确保业务流程不中断。然而，这只是一个暂时的措施，长期来看仍然需要找到根本原因并进行彻底的修复，以避免同样的问题再次发生。
预防措施
为了防止此类问题的发生，我们应该及时安装相应的补丁。这不仅能够解决现有的问题，还可以提高系统的整体稳定性和安全性，防止未来可能出现的漏洞和攻击。此外，定期检查和更新补丁也是维护系统健康的重要措施。
希望这篇指南能帮助大家更好地解决AIX系统中Oracle 11.2.0.4 RAC内存泄漏的问题。如果有任何疑问或需要进一步的帮助，请随时联系技术支持团队。
