内存监控技术深入解读.docx

《内存监控技术深入解读.docx》由会员分享，可在线阅读，更多相关《内存监控技术深入解读.docx（4页珍藏版）》请在第一文库网上搜索。

1、内存监控技术深入解读【摘要】DBA经常和内存打交道，内存也是DBA做数据库运维监控中最容易蒙圈的东西，以前用OraC1e数据库的时候，内存管理和监控方面对DBA来说压力还不大，随着开源数据库和国产数据库的日益普及，DBA面临的内存问题也越来越具有挑战性。DBA经常和内存打交道，内存也是DBA做数据库运维监控中最容易蒙圈的东西，这是因为虚拟内存（VM）这种机制带来的复杂分析问题。最简单的方式是去看内存使用率或者内存空闲空间，不过这种监控数据在大多数情况下并没有任何用处。因为1INiJX/UNIX上的内存回收默认是1AZY回收模式，只要物理内存还不至于没有可用的了，那么暂时不会回收内存。如果大量的

2、物理内存都消耗在文件缓冲上，那么过早的回收缓冲会加重操作系统IO的福安。另外因为NUMA的问题，以及SWAP的存在，让物理内存分析更加困难了。以前用OraC1e数据库的时候，OraC1e自身已经把内存和操作系统的问题解决得相当好了，所以内存管理和监控方面对DBA来说压力还不大。随着开源数据库和国产数据库的日益普及，DBA面临的内存问题也越来越具有挑战性。有时候明明物理内存还有十几个GB的空闲，但是SWAP已经用了一小半了。而且平时也没啥问题，当我们不把它当回事的时候，数据库突然宕机了。于是我们就认真的去学习了一大堆NUMA架构、SWAP、OOMKI11ER等方面的知识之后，才把这些事情搞清楚了

3、。NUMA架构下，如果使用OS默认的vm.Overcommit_memory参数时，多个NUMA节点的物理内存使用可能不均衡。当某个节点的物理内存不足时，那马另外一个节点存在很大量空闲内存也会产生大量的不必要的SWAPo因此我们总是希望随时都能够掌握物理内存的使用情况到底怎样，是不是存在风险。不过我们真的很难弄清楚物理内存的真实使用情况和风险情况。还有一个让内存分析十分头痛的是共享内存的使用，比如我们的数据库系统，都会使用共享内存作为公共缓冲，这样大量进程ATTACH的共享内存会被重复统计，让我们的内存使用总量的统计总是无法准确。我们来看一个系统的情况:可以看到上面例子里服务器物理内存使用了9

4、1.68乐空闲空间为500多M,不可用内存是84.69%（可用内存为15.31%）。这似乎有点看不懂了。实际上这个也很好理解，物理内存使用了91.68%,不过有很多物理内存都是可以释放的,不可释放或者不能SWAP的内存有84.69%,当前物理内存的15.31%还是可以被使用的。我们利用D-SMART里的物理内存分析工具来看看当前系统的内存实际使用情况。从这个工具看的更清晰一些，这个系统共有64GB的内存，系统尚未使用的内存大小是460M左右，这个和MenIfree的指标是一致的（采样数据有一定差异）。可用内存大小是9GB左右，和上面的指标也对的上。因为没有启用大页，因此PAGETAB1E占了4

5、GB,有点太多了。实际上我们分析物理内存的风险的时候，重点需要关注的是系统可用内存的大小和SWAP的使用率。不过在某些存在突发内存使用高峰的场景中，光关注这些还是不够的。能够随时了解物理内存的实际使用情况依然是我们最需要的内存监控项。这么看起来确实挺累的。有没有更好的办法来分析内存呢？能不能让我看清楚物理内存都用了多少，都被谁用了呢？答案肯定是有的，那就是SnIen1工具。smem工具和1inUX上的其他工具之间的最大区别就是，它能分析物理内存的真实使用情况。Smem安装比较容易，可以去https:WwW还是回到刚才那个例子。我们来看一下内存的使用情况。这个内存使用情况是不是看的清楚一些了。K

6、erne1占用了22%的物理内存，其中9.82%是CACHE,这些都是可释放的。用户占用了72.92%的物理内存，其中16.48%是CACHE,可以释放。我们再来看看哪些用户使用了较多的物理内存。上面的PSS是指占用的物理内存，RSS是我们传统意义上看到的物理内存。因为这个统计里包含了共享内存,因此RSS占用物理内存的比例是98.49乐似乎物理内存总共被使用的也只有91%多点，为什么会出现这种情况呢？这是因为共享内存被重复计算了好多遍。而PSS则是更为精准的物理内存占用比例。从这个例子的输出我们可以看出，ceph占用了最多的物理内存，大约是46.53%o排在第二位的OraII2是OraCIeI12数据库的账号，占用了16.44%的物理内存。值得注意的是OraII2的SWaP占用居然也高达200%,这说明了共享内存也有一部分被SWAP了。这对于OraCIe数据库来说，是会严重影响性能的。一旦遇到这种情况我们一定要引起警惕。-全文完-