共计 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 的执行计划出现了错误,导致执行时间过长,并发执行量过大,占用了大量物理内存。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)