共计 1426 个字符，预计需要花费 4 分钟才能阅读完成。
| 导读 | PG 数据库遇到内存问题要立即进行分析的场景并不多，因为大多数 PG 数据库的内存使用率过高的报警并不意味着内存使用情况异常，内存真的不够用了。因为 PG 数据库是使用 DOUBLE BUFFERING 机制的，大量的内存很可能被 BUFFER/CACHE 占用了。 |
前几天写了 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 的执行计划出现了错误，导致执行时间过长，并发执行量过大，占用了大量物理内存。
