PostgreSQL 添加索引导致崩溃，参数调整需谨慎--文档未必完全覆盖场景

题目比较混乱，实际上这件事也让我认识到两点问题

1 官方的说明文档，你不能全信，官方文档说明的部分只能是一个大概或者大部分情况，你的情况是否属于这个部分，你的自行评估。

2 参数的调节，是一个漫长的过程，是不断踩坑的过程中总结的，实践是产出经验的地方

3 一些不能使用的命令，在关键时刻，必须使用，这也是我对PostgreSQL的数据库安全担心的地方。

具体案例：

最近遇到一则比较怪的问题，就是关于PostgreSQL大表添加索引，直接引起PostgreSQL crash的问题。故障的现象是，对这张2亿行表添加索引，系统会crash。

以上是当时的情况，从图中和对应日志，我们可以分析到一个问题在添加索引的情况下，且有大量的UPDATE ，在短时间内存使用率持续走高，我们看下面这张图

一开始在添加索引的时候，mem_size_cache持续走低，同时mem_size_rss持续走高。

mem_size_cache是指的操作系统缓存，这是用来缓存磁盘上的数据页的内存，随着添加内存的操作，系统开始检测到内存不足，在不断腾出更多的内存给正在运行的进程。

mem_size_rss 持续走高，RSS 是Resident set size ，这个量是指的在物理内存中实际占用的内存量。

这两个符合在添加索引中内存的消耗，在崩溃的前一刻，系统的mem_size_rss已经接近了20G 整体的内存才32G，shared buffer pool 设置为8G。

从这里分析系统崩溃的主要原因就是内存OOM，然后系统作出了 KILL -9 客户进程的操作，然后系统就开始触发了整体的进程的重启，最后系统进入了recovery_mode，整体进行recoery 的过程在2秒结束。 这说明一个问题，系统OOM 的时候操作系统KILL的是客户的添加索引的进程，而不是主进程。如果是重启一个11T的大库2秒是起不来的,尤其还是要进行recovery 的过程。

POSTGRESQL 数据库崩溃的原因搞清楚了，需要我们注意的有几个地方

1 maintenance_work_mem 的设置是否和官方说的是可以更大一点进行设置，到底应该多大，部分情况下设置的过大，会不会出现我们的问题，因为可能一次批量添加很多索引，那么每个进程都会开启使用maintenance_work_mem的模式，包含了一个添加过程中的多个子进程也都可以进行内存的单独分配，所以如果有批量干一些事情的情况下，maintenance_work_mem一定不要设置太大，否则就会和我们一样，操作系统直接发出KILL -9 的命令直接将客户的进程KILL ，而引发整体的进程的重启。

（下图为官方关于此参数的说明）

2 KILL -9 这个问题已经很明确了，在我们个人的操作中是不允许使用KILL-9 去KILL 客户或者系统的进程，这对PG来说是非常容易出现数据丢失，但是在系统层面，如果发现某个进程使用内存太多，他们会直接发起KILL -9 的工作来将这个进程杀死，好让整体系统进行工作。

这类就产生一个问题，到底要不要KILL -9 ，人工我们可以使用命令 pg_terminal_backend（PID）来操作，或者使用kill term 的方式来，但是操作系统在遇到真正的问题OOM 的情况下，是直接上来就KILL 的。所以POSTGRESQL 目前还避免不了系统级的KILL -9的发生。

总结：在POSTGRESQL 分配一些核心内存使用的时候，要注意大小和一次操作的命令的数量，INDEX 有的时候是批量添加，尤其大表容易发生参数设置不对，导致OOM的情况，同时会发生KILL -9 对相关进程的操作。