PostgreSQL could not fork new process for connection
前几天在使用 PostgreSQL 数据库的过程中遇到这样一个错误。
could not fork new process for connection: Resource temporarily unavailable
看字面意思是无法克隆一个新的进程供连接使用，资源暂时不可用。下面是程序提示的各种错误。
知识点介绍
PostgreSQL 数据库是一个进程架构的模型设计。它有一个主进程 Postmaster Process，当有客户端发起链接请求时，Postmaster 主进程负责创建一个后端的客户端进程 Client Process，之后由这个进程负责客户端的这次请求操作。
错误出现怀疑是连接数的设置问题，但是遇到过数据库连接数达到最大值的情况。PostgreSQL 数据库当连接数达到最大值时，报错是 FATAL: sorry, too many clients already。
通过下面的方法，可以排除是数据库连接数不足的问题。
SELECT COUNT(*) FROM pg_stat_activity;
SELECT * FROM pg_settings WHERE name LIKE '%max_connections%';
发现当前连接数还远没有达到最大连接数 max_connections 参数设置的值。
再看错误提示是资源暂时不可用
服务器资源无非就是 CPU、内存和磁盘 IO 这些，决定去看看服务器的资源使用情况，是否存在特别明显的瓶颈问题。
使用 Linux 的 top -c 发现当前系统的 CPU 不是很高，系统负载在 1、5、15 分钟内也不是很高没有特别明显的 CPU 问题。
使用 LInux 的 free -h 看剩余内存可用内存都还是比较充足的。内存不足一般会引发 OOM。
使用 LInux 的 df -h 查看磁盘空间还是很足的。
这些都不存在问题，接下来就是排查系统的 IO 了，使用 iostat -d -x 1 观察发现也不存在问题。
怀疑是数据库参数配置问题
涉及到的参数有如下几个参数。阅读 PostgreSQL 关于参数的详解，可以看到。
max_worker_processes 设置系统能够支持的后台进程的最大数量。
max_parallel_workers_per_gather 设置单个 Gather 或者 Gather Merge 节点能够开始的工作者的最大数量。并行工作者会从 max_worker_processes 建立的进程池中取得，数量由 max_parallel_workers 限制。
max_parallel_maintenance_workers 设置单一工具性命令能够启动的并行工作者的最大数目。当前，唯一一种支持使用并行工作者的工具性命令是 CREATE INDEX，并且只有在构建 B- 树索引时才能并行。
max_parallel_workers 设置系统为并行操作所支持的工作者的最大数量。
我之前有一篇文章介绍过 PostgreSQL 数据库的配置文件参数，所以大部分参数我还是比较清楚的，基本可以排查参数问题。
在此问题得到解决之前，重启过数据库服务，重启过程序，但是都扛不住 1 小时。日志文件暴增程序无法访问。
此时我觉得还是要从服务器入手。决定还是去看看 Linux 的一些配置限制。先使用 Linux 的 ulimit -a 去看一下文件句柄数这些，发现这些已经被运维工程师调整过了，继续查看 Linux 资源限制配置文件 /etc/security/limits.conf 发现几个参数的设置是已经被优化过的，数值一般不会达到的那种。搜索了下关于这个文件的介绍，这个文件的作用等等。在一篇关于 Linux 服务器系统文件的介绍中有这样的一个介绍 /etc/security/limits.d 下的文件会覆盖 /etc/security/limits.conf 文件中的参数值，然后就去查看了下 /etc/security/limits.d 中有哪些文件，当时在 /etc/security/limits.d 下只有一个文件 /etc/security/limits.d/20-nproc.conf 在这个文件中有这样的一个设置
* soft nproc 4096
它与 /etc/security/limits.conf 文件中设置的值不同，只有 4096。/etc/security/limits.d 这个文件中有一些设置是我们的运维工程师加进去的，就比如上面这行数据，在该文件中被设置的值是 65535。
到此时抱着试一试的态度我使用如下的命令进行了一个操作，使用 Linux ps 看下用户进程数
ps -elf | grep postgres | wc -l
最后发现得到的值是大于 4096 的
这个时候抱着试一试的态度拿自己的虚拟机测试了下，我将 /etc/security/limits.d/20-nproc.conf 下的参数值从 4096 修改为 10，然后重启服务器，因为需要模拟至少 10 个连接，我就打开 Navicat 客户端不断的创建新的会话执行相同的查询，当打开几个查询后，观察 PostgreSQL 日志文件，发现此时日志文件有大量的错误 LOG: could not fork autovacuum worker process: Resource temporarily unavailable。当我看到有错误 Resource temporarily unavailable 时我的眼前是一亮的，我需要一个环境去验证我的猜想和判断。在经历了漫长的验证之后基本确定了是这个问题。接下来只需要在生产环境中进行修复即可。在生产环境升级后这个问题直到下班前都未再出现过，问题得到解决。
最后总结下，排查问题涉及的几个点：
1、数据库最大连接数设置：
SELECT COUNT(*) FROM pg_stat_activity;
SELECT * FROM pg_settings WHERE name LIKE '%max_connections%';
2、操作系统参数设置：
cat /etc/security/limits.conf
cat /etc/security/limits.d/20-nproc.conf
3、用户连接数去验证是否超过上面的值：
ps -elf | grep postgres | wc -l
4、查看 PostgreSQL 数据库服务主进程下的连接限制
ps -ef | grep /usr/pgsql-12/bin/postgres 获取主进程 ID
备注：这里 /usr/pgsql-12/bin/postgres 是你 PostgreSQL 数据库安装位置，这里的主要目的是获取 PostgreSQL 服务的主进程 ID，当然也有别的方式可以获取你的主进程 ID 号，比如 postmaster.pid 文件
cd /proc/pid
备注：这里进入的是操作系统进程下目录，这里的 pid 就是前面获取的主进程 ID 号
cat limits
备注：这里显示了你的很多限制信息，有兴趣的可以仔细看看都有一些啥。
