–

在日常运维过程中，经常发现操作系统使用率高的情况，碰倒这种问题如果通过top命令能看到明确的占用内存高的进程还好，好多使用并不能直接看出来哪个进程占用内存高，或者说知道占内存高，但是不知道原因或者如何处理，这就比较难受了。本文总结了我日常运维过程中碰到的内存使用率高的情况，以及我个人的一个排查思路，主要针对linxu平台，希望对大家有帮助，由于能力有限，难免有解释的不对的地方，也欢迎大家在评论区批评指正。

linux系统中能查看内存使用情况的命令有很多，如top、free、vmstat或者查看/proc/meminfo，关于这些命令的具体使用方法就不在仔细介绍了，我只想说几个不容易被大家熟知的知识点： 1、top命令显示的输出，可以按shift+m按内存使用率排序。 2、free命令显示如果swap有被使用到，并不一定是当前真正的被使用到了，而有可能是之前由于某些原因被使用过，而后内存使用降下来了，这个used值并不会再变回0，只有重启才能使这个值变成0。 3、如果想看当前内存和swap使用的情况，可以用vmstat，重点关注swap和memory列的变化。 4、free命令显示的available是linux内核评估出来的当前系统的可用内存，跟used、free、buffer、cache并没有直接的关系，由于linux内存管理很复杂，所以这个值跟以上值的大小比较没有任何意义！！！我们只要知道available是内核评估的内存剩余量，相对来说比较有参考意义。

这里想重点介绍一个我经常使用的内存分析工具—smem。smem是Linux系统上的一款可以生成多种内存耗用报告的命令行工具。与现有工具不一样的是smem可以报告实际使用的物理内存（PSS），这是一种更有意义的指标。可以衡量虚拟内存系统的库和应用程序所占用的内存数量。由于linux使用的是虚拟内存管理技术，所以无论从top、vmstat都很难看出每个进程的真是内存占用情况，使用smem可以更好的衡量内存的占用情况。这个工具使用方法网上也有很多介绍，我也不过多说了主要是解压就能用。

[root@docker01 tmp]# tar -xzvf smem-1.4.tar.gz smem-1.4/.hg_archival.txt smem-1.4/.hgtags smem-1.4/COPYING smem-1.4/smem smem-1.4/smem.8 smem-1.4/smemcap.c [root@docker01 tmp]# cd smem-1.4 [root@docker01 smem-1.4]# ls COPYING smem smem.8 smemcap.c [root@docker01 smem-1.4]# chmod +x smem [root@docker01 smem-1.4]# ./smem -t -k >res_smem =====================>这个就可以直接打开看了

我们要关注PSS列，这一列基本上就是去掉共享内存实际占用的内存的情况，RSS是包含共享内存值。

    操作系统进程systemd-journald提供日志功能，默认配置是在内存中存储日志记录，最大占用4G。RedHat官方给出了systemd-journald对性能的负面影响及其缓解措施，按照建议，将内存占用最大值缩小至500M。但是根据生产实际测试，即使将该值限制到500M，systemd-journald占用内存依然会超过500M，这也是红帽的一个bug，这个就需要打补丁解决。也可以通过重启该服务环境此问题。

    设置了大页以后，只有能使用大页内存的程序才能使用该内存，而大页内存在配置以后，系统启动后立马进行分配出在oracle数据库的最佳实践中，如果SGA比较大，会建议配置大页，大页内存是集成在Linux 2.6内核的一个特性。与传统的4K页面相比，启用大页内存可以使操作系统支持更大的页面。使用大页内存将会减少系统维护page table entries（页表条目，PTE）所消耗的资源，从而提高系统性能。大页内存对于32位和64位的配置都有用。大页内存的大小从2MB到256MB不等，依赖于内核版本和硬件架构。对于Oracle数据库，使用大页内存可以减少操作系统对页面状态的维护，并且能够提升Translation Lookaside Buffer （页面缓冲，TLB）的命中率。如果没有配置大页，而SGA又特别大，很有可能导致pte占用特别大的内存，这个可以通过查看/proc/meminfo中的PageTables确认。

    设置了大页以后，只有能使用大页内存的程序才能使用该内存，而大页内存在配置以后，系统启动后立马进行分配出去，比如配置了30G的大页内存，这部分内存在os启动后就被分配出去了，即使数据库没有启动，我们从free命令看used就是30G。如果你的SGA配置了10G，那相当于有20G的内存是被浪费掉的，因为没有别的进程能占用这个20G内存。所以在配置大页的时候，一定要规划好os内存和数据库内存的关系。

    在Oracle 12c 中Management Database 用来存储Cluster HealthMonitor(CHM/OS,ora.crf) ，Oracle Database QoS Management，Rapid Home Provisioning和其他的数据。ManagementRepository 是受12c Clusterware 管理的一个单实例，在Cluster 启动的时会启动MGMTDG并在其中一个节点上运行，并受GI 管理，如果运行MGMTDG的节点宕机了，GI 会自动把MGMTDB 转移到其他的节点上。这个东西在oracle12c安装的时候是必选项，在19c的时候又变成了可选项，在实际生产中是没啥用处的。而且这个实例的mmnl进程存在内存泄漏的bug，

有三种方案解决该问题： 1、 kill掉该进程，因为mmnl进程会自动启动，所以kill掉以后释放的内存会慢慢再次被mmnl进程占有，只能定时关注该进程，定时kill。 2、安装补丁28831971，需要下载安装对应当前数据库psu版本的补丁，具体有效性需要测试后观察。 3、关闭mgmtdb，关闭后对数据库没有影响，只有在升级psu的时候需要再次打开mgmtdb。

    oracle经常会有一些后台进程出现内存泄漏的bug，我在生产中碰到的一个bug是bug 31425761 ，这个bug会导致mmon的worker process(m000、m001、m002、m003…)出现pga内存的泄漏，一般会有四个类似的进程， 我见过比较夸张的是每一个进程占用的内存到了3g多，总共15g的内存的泄漏。根据mos上的处理方案是需要打补丁，我们一般的应急操作就是kill相关进程，oracle会自动把进程拉起来，没碰到有不好的影响。

    在内存调度中，buff/cache主要用于缓存读写文件系统的数据。所以，如果内存使用率处于较高水平，且buff/cache占用较高时，可以执行slabtop -s c命令查看详细信息，查看输出内容的CACHE SIZE项，找到占用较多的内核调用。从内核调用的名称（NAME项），可以判断出占用较大内存是xfs文件系统或是nfs文件系统等。这种一般就是服务器对文件有较多的IO操作，使用率内存作为cache加速。这种情况就要针对具体的进程具体分析了，可以通过重启os临时缓解或者扩容。

    生产上碰到过一次oracle adg的bug，从12c开始oracle的后台进程TTnn进程用来传输redo log到备库，这个进程在某个版本上会存在内存泄漏的bug，具体bug号记不太清楚了，如果碰到该进程有内存泄漏的情况，可以杀掉该进程，oracle会自动把该进程拉起来，基本上没有不好的影响。

1、以上碰到的内存问题，大部分可以通过定期重启os解决，所以我个人觉得，定期重启操作系统还是非常有必要的，即使是linux。我们好多系统怕麻烦不重启，这种其实风险还是挺大的。有些上千天没重启的服务器，哪天真正需要重启的时候，有可能就起不来了，不如找个时间充足的窗口重启一下，排除下风险。

2、oracle数据库的很多进程内存泄漏的bug，我的很多操作方案是kill进程，这种操作并不受官方支持的，对于不重要的系统可以实施，重要系统还是按照官方的思路打补丁解决。