记一次生产数据库系统内存使用过高的案例

本文主要是介绍记一次生产数据库系统内存使用过高的案例，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

墨墨导读：根据监控平台信息，发现数据库平台节点2内存使用率过高，达到98%。通过查询占用内存较高的进程、检查TFA状态、同步TFA配置等方式，使得系统恢复正常运作。

概述

根据监控平台信息，发现某数据库平台节点2内存使用率过高，内存使用率达到98%。

1. 查询占用内存较高的进程

内存使用率暂用最高的为asmcmd daemon，这个进程究竟在做什么导致消耗这么高的内存呢？

记下来跟踪一下该进程过程。

在这些进程上进行strace跟踪发现，无法连接到ASM实例以及对套接字文件不存在等大量无效调用。

进一步的分析/tmp/clsecho_stderr_file.txt发现，但随着CPU的增加，这些进程正在系统地从系统中获取更多交换空间。

这就很巧了该目录为TFA的诊断目录。说明当前TFA存在问题

2. 检查TFA状态节点1运行正常，节点2没有运行，多次手动启动没有反应，报错如下：

说明TFA 节点互联状态已经失效了。

3. 同步TFA配置

如果另一个节点TFA存在问题，那么可以在正常节点进行同步配置。

4. 后续处理

TFA配置完成后，内存的使用率就开下降，内存释放。

5. 总结

TFA(Trace File Analyzer Collector)是个11.2版本上推出的用来收集Grid Infrastructure/RAC环境下的诊断日志的工具，它可以用非常简单的命令协助用户收集RAC里的日志，以便进一步进行诊断；TFA是类似diagcollection的一个oracle 集群日志收集器，而且TFA比diagcollection集中和自动化的诊断信息收集能力更强大。

建议生产环境数据库均关闭TFA自动收集、分析功能（Autodiagcollect）从而避免类似情况发生影响生产环境数据库的正常运行。

注：关闭自动收集、分析功能不影响数据库正常运行，不影响TFA的日志收集、整合以及打包功能。

root用户执行：

tfactl set autodiagcollect = OFF

墨天轮原文链接：https://www.modb.pro/db/28043（复制到浏览器中打开或者点击“阅读原文”即可）。

这篇关于记一次生产数据库系统内存使用过高的案例的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！