更为精准的物理内存使用分析工具

DBA经常和内存打交道，内存也是DBA做数据库运维监控中最容易蒙圈的东西，这是因为虚拟内存（VM）这种机制带来的复杂分析问题。最简单的方式是去看内存使用率或者内存空闲空间，不过这种监控数据在大多数情况下并没有任何用处。因为LINUX/UNIX上的内存回收默认是LAZY回收模式，只要物理内存还不至于没有可用的了，那么暂时不会回收内存。如果大量的物理内存都消耗在文件缓冲上，那么过早的回收缓冲会加重操作系统IO的福安。另外因为NUMA的问题，以及SWAP的存在，让物理内存分析更加困难了。以前用Oracle数据库的时候，Oracle自身已经把内存和操作系统的问题解决得相当好了，所以内存管理和监控方面对DBA来说压力还不大。

随着开源数据库和国产数据库的日益普及，DBA面临的内存问题也越来越具有挑战性。有时候明明物理内存还有十几个GB的空闲，但是SWAP已经用了一小半了。而且平时也没啥问题，当我们不把它当回事的时候，数据库突然宕机了。

于是我们就认真的去学习了一大堆NUMA架构,SWAP，OOM KILLER等方面的知识之后，才把这些事情搞清楚了。NUMA架构下，如果使用OS默认的vm.overcommit_memory参数时，多个NUMA节点的物理内存使用可能不均衡。当某个节点的物理内存不足时，那马另外一个节点存在很大量空闲内存也会产生大量的不必要的SWAP。因此我们总是希望随时都能够掌握物理内存的使用情况到底怎样，是不是存在风险。不过我们真的很难弄清楚物理内存的真实使用情况和风险情况。

还有一个让内存分析十分头痛的是共享内存的使用，比如我们的数据库系统，都会使用共享内存作为公共缓冲，这样大量进程ATTACH的共享内存会被重复统计，让我们的内存使用总量的统计总是无法准确。

我们来看一个系统的情况：

可以看到上面例子里服务器物理内存使用了91.68%，空闲空间为500多M，不可用内存是84.69%（可用内存为15.31%）。这似乎有点看不懂了。实际上这个也很好理解，物理内存使用了91.68%，不过有很多物理内存都是可以释放的，不可释放或者不能SWAP的内存有84.69%，当前物理内存的15.31%还是可以被使用的。我们利用D-SMART里的物理内存分析工具来看看当前系统的内存实际使用情况。

从这个工具看的更清晰一些，这个系统共有64GB的内存，系统尚未使用的内存大小是460M左右，这个和Mem free的指标是一致的（采样数据有一定差异）。可用内存大小是9GB左右，和上面的指标也对的上。因为没有启用大页，因此PAGETABLE占了4GB，有点太多了。实际上我们分析物理内存的风险的时候，重点需要关注的是系统可用内存的大小和SWAP的使用率。不过在某些存在突发内存使用高峰的场景中，光关注这些还是不够的。能够随时了解物理内存的实际使用情况依然是我们最需要的内存监控项。

这么看起来确实挺累的。有没有更好的办法来分析内存呢？能不能让我看清楚物理内存都用了多少，都被谁用了呢？答案肯定是有的，那就是smem工具。Smem工具和linux上的其他工具之间的最大区别就是，它能分析物理内存的真实使用情况。

smem安装比较容易，可以去https://www.selenic.com/smem/download/ 下载一个适合你的操作系统的版本。解压后，把smem放到/usr/bin 目录下，smem.8拷贝到/usr/share/man/man8目录下，就完成安装了。此后，我们可以使用man smem来学习如何使用smen。

还是回到刚才那个例子。我们来看一下内存的使用情况。

这个内存使用情况是不是看的清楚一些了。Kernel占用了22%的物理内存，其中9.82%是CACHE，这些都是可释放的。用户占用了72.92%的物理内存，其中16.48%是CACHE，可以释放。

我们再来看看哪些用户使用了较多的物理内存。上面的PSS是指占用的物理内存，RSS是我们传统意义上看到的物理内存。因为这个统计里包含了共享内存，因此RSS占用物理内存的比例是98.49%，似乎物理内存总共被使用的也只有91%多点，为什么会出现这种情况呢？这是因为共享内存被重复计算了好多遍。而PSS则是更为精准的物理内存占用比例。

从这个例子的输出我们可以看出，ceph占用了最多的物理内存，大约是46.53%。排在第二位的ora112是Oracle 11.2数据库的账号，占用了16.44%的物理内存。值得注意的是ora112的swap占用居然也高达200%，这说明了共享内存也有一部分被SWAP了。这对于Oracle数据库来说，是会严重影响性能的。一旦遇到这种情况我们一定要引起警惕。