PG数据库内存告警了怎么分析

​前几天写了CPU分析与IO分析的文章，本来昨天想再凑一个内存分析的，不过因为昨天一大早就去拜访客户了，所以今天补上。今天早上本来和优诺的傲寒约好了去他那里取取经，听听他对智能化运维的看法，不过因为一些其他安排临时取消了，十分遗憾。

PG数据库遇到内存问题要立即进行分析的场景并不多，因为大多数PG数据库的内存使用率过高的报警并不意味着内存使用情况异常，内存真的不够用了。因为PG数据库是使用DOUBLE BUFFERING机制的，大量的内存很可能被BUFFER/CACHE占用了。

上面的free命令可以看到32G内存使用了15G多，但是free只剩下599M了，BUFF/CACHE占了15G多。不过如果我们看avAIlable，有9G多，当前这个PG服务器的内存是充足的。从这个例子上看到，我们看fee命令的结果的时候，不应该看free，看available更为准确。

/proc/meminfo可以更详细的看到OS的内存情况，我们可以关注红框里的几个数字。Dirty是FILE CACHE中尚未写入磁盘的脏数据，是无法快速丢弃的内存，如果这个指标持续较高，那么说明OS的回写机制或者磁盘存在性能问题，是需要关注的。PageTalbes如果比较大，对于PG数据库来说，很可能是配置了较大的shared_buffers,但是没有启用HugePages，这样除了会影响PG数据库访问内存的性能外，还会占据大量的不必要的内存。AnonHugePages指标大于零说明没有关闭透明大页，而且已经使用了透明大页，对于PG、Oracle等数据库来说，透明大页的缺点大于优点，会引起内存碎片，建议关闭。另外需要关注的是SWAP的使用率，如果FREE内存很大，但是SWAP使用率超过20%，很可能是OS的NUMA内存方面的配置存在问题，没有全局分配内存。

遇到PG数据库的空闲内存不足的问题，首先通过这些机制分析OS内存是否真的存在风险，如果没有发现明显的风险，暂时就不需要做进一步的分析了。如果真的存在风险，我们还可以继续在OS层面查找。

ps aux –sort -rss |head -20命令可以查出rss使用最高的20个进程。然后找出存在问题的进程，用smem做进一步分析。

如果找到了存在问题的进程，可以用smem进一步去做分析。其中USS是进程私有内存，PSS是私有内存+共享内存的总和。

如果在OS层面找到了存在问题的进程，那么可以使用上面的语句去查找其PG会话的信息，进一步进行定位。一般情况下，PG会话占用较多的内存可能是做VACUUM、ANALYZE、排序，表连接、内存临时表等操作。

如果不存在某个进程使用内存过多，而是大量的进程都占用差不多的内存，那么很可能是数据库并发执行某类SQL，使用了排序，表连接等临时内存分配。这时候就要去分析数据库的性能是否存在问题，导致了某类SQL或者某条SQL并发执行量较大。亦或是某条SQL的执行计划出现了错误，导致执行时间过长，并发执行量过大，占用了大量物理内存。