openGauss 数据库报错 "failed: Too many open files"

我接手的那套 openGauss 环境，几乎都是在业务方催得最急的时候出问题。那次是上午十点左右，运营后台突然打不开，紧接着监控告警弹出来，数据库日志里刷屏一样的“failed: Too many open files”。很多刚接触 openGauss 的朋友看到这个报错，第一反应是磁盘满了，或者是文件权限问题，实际上这行报错直指操作系统的文件描述符（File Descriptor，简称 fd）被耗尽。这不算疑难杂症，但要是没搞清楚底层逻辑，光改一个参数根本压不住，后面还会反复炸。

这个报错解决起来不难，难的是找到“为什么默认配置不够”以及“到底是谁把 fd 吃光的”。这篇文章我会从现象、根因、排查、解决四个维度完整拆解，最后再附上我自己的踩坑记录和巡检建议。无论你是在生产环境还是开发环境遇到同类问题，照着这个思路走一遍，基本都能在半小时内定位到根因并恢复。

1. 这个报错长什么样：现象与影响

1.1 报错发生的典型场景

先说现象。openGauss 日志中会出现类似下面的内容：

text复制2024-XX-XX 10:23:45.123 ERROR  failed: Too many open files
2024-XX-XX 10:23:45.124 ERROR  could not open file "global/pg_filenode.map": Too many open files
2024-XX-XX 10:23:45.125 ERROR  connection to client lost

如果你是用客户端工具（比如 Navicat、DBeaver、gsql）连 openGauss，报错信息可能更隐晦，像“server closed the connection unexpectedly”或者“connection refused”。这种时候你不去翻服务端日志，很容易误判成网络问题或认证问题，绕一大圈才发现是服务端 fd 耗尽，根本没法接受新连接。

我遇到过最典型的三个场景：

• 业务侧配置了过大的连接池，几百个应用实例同时连数据库，每个实例又维持几十条长连接，连接数一冲上来，fd 瞬间耗尽。
• 批量任务集中执行，比如跑大批量数据导入、大量分区表同时访问，openGauss 为了管理这些表文件和索引文件，会成批打开文件描述符。
• 数据库侧存在连接泄漏或慢查询堆积，空闲连接不被回收，新连接又不断进来，fd 被一点点吃光。

1.2 报错背后牵连的三个层面

要理解这个报错，必须先建立一个认知框架：openGauss 进程能打开多少个文件，不是数据库单方面决定的，而是由三个层面的限制共同决定。

• 操作系统层面：整个系统允许打开的文件总数，由 fs.file-max 控制。
• 用户/进程层面：单个用户或进程可以打开的文件数，由 ulimit -n 控制，也就是 nofile 软限制和硬限制。
• 数据库层面：openGauss 内部还有一些参数，比如 max_files_per_process，用于限制每个数据库进程额外打开的文件数。

排查的时候，如果只盯着数据库参数调，忽略操作系统层面的限制，就会出现“参数明明改大了，报错却依然存在”的尴尬局面。相反，如果只改系统 ulimit，但数据库内部参数没跟上，高并发场景下依然可能在某个边缘节点上被卡死。所以这篇文章里我坚持一个原则：三层限制必须全部照顾到，一个都不能漏。

2. 根因剖析：文件描述符到底是怎么被耗光的

2.1 什么是文件描述符

文件描述符是操作系统为了管理进程打开的文件而分配的一个非负整数。在 Linux 世界里，“文件”是一个很宽泛的概念：普通文件、目录、socket 连接、管道、设备节点，统统被抽象成文件。openGauss 每接收一个客户端连接，本质上是创建了一个 socket；每扫描一张表，可能要打开对应的数据文件；每加载一个索引，也要打开索引文件。

做个不严谨但好懂的类比：数据库进程就像一个快递站，文件描述符就是快递站里的储物格。每个快递（连接、数据文件、索引文件）都要占一个格子，格子不够了，新快递就进不来。操作系统默认给普通用户进程的 nofile 限制通常只有 1024，也就是说一个进程最多同时打开 1024 个“东西”。生产环境里 openGauss 动辄几百个连接，每个连接又有自己的会话上下文，再加上表、索引、WAL 日志等文件，1024 这个数字根本不够看一眼。

2.2 openGauss 的 fd 消耗逻辑

很多人有个误解，以为“连接数 = 文件描述符数”，所以只盯着 max_connections 调。其实 openGauss 的每个后端进程消耗的 fd 远远不止 socket 那一份。拆开看，一个活跃连接通常会占掉这些描述符：

• 客户端连接对应的 socket 文件描述符；
• 当前会话访问的表、索引对应的文件描述符；
• 临时文件、排序文件对应的描述符；
• 锁文件、统计信息文件、日志文件等基础描述符。

而且要注意，openGauss 是进程池架构，多线程模型下后端进程的数量和连接数并非一一对应，但每个 worker 线程处理查询时打开的文件依然是独立计算的。尤其是在索引扫描、位图扫描、并行查询这些场景下，一个查询可能瞬间打开几十个文件描述符。如果你用的是默认的 max_files_per_process = 1000，听着不少，但几百个连接同时跑关联查询，分分钟就能把它撑爆。

2.3 三层限制到底卡在哪一层

为了帮助你快速定位，我把三层限制的作用关系画成了逻辑链：

• 系统层 fs.file-max 不够：所有进程加起来就开不了那么多文件，通常会伴随内核日志报错。
• 用户层 ulimit -n 不够：openGauss 进程本身被限制住了，无法打开更多文件，这是最常见的爆点。
• 数据库层 max_files_per_process 不够：操作系统允许，但进程池内部对单个进程的文件数做了限制，典型表现是某些后台进程反复报错。

排查的关键是先确认当前 ulimit -n 的值。我见过不少部署文档要求在启动 openGauss 前执行 ulimit -n 1000000，但实际操作时，很多人要么没做这一步，要么在 systemd 服务脚本里没有同步配置 LimitNOFILE，导致启动后进程又退回到系统默认值。这类问题，用 cat /proc/<pid>/limits 一看便知，用户态配置和进程实际生效值经常对不上。

3. 排查思路：一步步定位问题

3.1 先用这三条命令确认现状

遇到报错，先别急着改配置，先花两分钟确认一下当前系统的真实水位。我推荐按顺序执行下面三条命令：

bash复制# 查看系统级文件描述符限制和当前使用情况
cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nr

# 查看 openGauss 主进程实际生效的限制
cat /proc/$(pidof gaussdb)/limits

# 查看 openGauss 进程当前已打开的 fd 数量
ls /proc/$(pidof gaussdb)/fd | wc -l

这三条命令分别回答了三个问题：系统能支撑多少、进程被允许打开多少、进程现在打开了多少。如果第三个数明显接近第二个数，那就是用户级限制触顶了；如果第二、三都不高，但系统整体 file-nr 已经逼近 file-max，就要考虑是不是还有其他进程在抢占系统资源。

file-nr 这个文件里有三个数字，分别是系统当前已分配的文件描述符数量、未分配数量、最大限制。正常情况下，第一个数远小于第三个。如果第一个数长期维持在最大值的 80% 以上，说明系统整体文件句柄压力较大，需要排查是否有其他应用泄漏 fd。

3.2 定位具体进程与 fd 状态

确定了 is 进程层面的压力后，再深入看看到底是什么类型的 fd 占了大头。这里我习惯用两类命令：

bash复制# 统计当前打开的各种文件类型数量
sudo lsof -p $(pidof gaussdb) | awk '{print $5}' | sort | uniq -c | sort -nr | head -20

注意，lsof 在 fd 数量特别大的时候会有点卡，最好挑业务低峰期执行。如果没有 lsof，也可以直接看目录：

bash复制ls -l /proc/$(pidof gaussdb)/fd | head -30

重点是区分三类 fd：socket（网络连接）、REG（普通文件，即数据文件或日志文件）、pipe（管道）。如果是 socket 数量占绝对多数，说明连接数需求确实很高，优先考虑调大连接上限与 nofile；如果是 REG 文件占多数，说明是表、索引文件打开过多，要关注 max_files_per_process 和表数量是否过于庞大。

3.3 判断是“配置不足”还是“fd 泄漏”

这一步非常关键。如果只是单纯配置不足，调大限制后数值会趋于稳定；如果有泄漏，调大也只是把崩溃时间往后推。我自己常用的判断方法是：连续观察 fd 总数在业务平稳期的变化趋势。

bash复制# 每隔 30 秒采样一次，共采样 10 次
for i in $(seq 1 10); do
  echo "$(date +%H:%M:%S) fd_count=$(ls /proc/$(pidof gaussdb)/fd | wc -l)"
  sleep 30
done

如果在没有明显业务波动的时段，fd 数量依然只增不减，那大概率是应用侧存在连接泄漏——比如某些 SQL 异常没有走自动重连清理逻辑，或者应用框架的连接池没有正确归还连接。这种情况下，光调系统参数是治标不治本，必须推动业务侧排查连接管理逻辑。反过来，如果 fd 数量随着连接数同步升降，波动正常，那就是配置容量不够，调参数就能解决。

4. 解决方案：一套组合拳，彻底解决

4.1 调整系统与用户级限制

先说操作系统层面。fs.file-max 一般默认值在几十万到百万级别，大多数场景够用，但在高并发数据库环境下，我还是建议显式调高，避免系统全局触顶。

bash复制# 临时生效
sudo sysctl -w fs.file-max=2097152

# 永久生效
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
sudo sysctl -p

接下来是用户级 nofile。如果 openGauss 是通过普通用户（比如 omm）启动的，就要在 /etc/security/limits.conf 里为这个用户设置软硬限制：

text复制omm soft nofile 1048576
omm hard nofile 1048576

这个配置对通过 PAM 登录的会话生效。但要注意，如果你用 systemd 管理 openGauss 服务，limits.conf 并不会直接作用到 systemd 启动的进程上，这是很多人改完配置发现不生效的根本原因。此时必须在 systemd service 文件里追加：

ini复制[Service]
LimitNOFILE=1048576

改完 service 文件后执行 systemctl daemon-reload，再重启 openGauss 服务。

如果 openGauss 是通过脚本手动启动的，还要确认启动脚本里有没有执行 ulimit -n。强烈建议在启动脚本或者服务环境中统一加上这一句，避免手动敲命令和自动拉起时行为不一致。我处理过不止一个环境，运维同学手动 ulimit -n 65535 后能正常启动，结果一重启服务器，服务起不来，日志里一模一样的 Too many open files，原因就是自启动脚本里没带这一项。

4.2 调整 openGauss 侧参数

系统层和用户层放开后，接着看数据库侧。主要调整两个参数：max_connections 和 max_files_per_process。

max_connections 控制最大连接数，默认值通常在 100 左右。如果应用侧连接池配置过大，需要先评估合理连接数，再同步调整数据库参数。这个参数修改后需要重启数据库生效。

max_files_per_process 控制每个数据库进程可以额外打开的文件数，默认值是 1000。对于生产环境，我一般建议调整为 65536 或更高，具体取决于表数量、连接数和业务复杂度。计算公式可以粗略参考：

text复制max_files_per_process = max_connections * 每连接平均fd + 系统表与日志预留fd

假设单连接平均消耗 10 个 fd，500 个连接就是 5000 个 fd，再加上数据库内部对大量表、索引的访问，65536 这个值通常够用且不会引起内存浪费。

修改方式：

sql复制ALTER SYSTEM SET max_connections = 500;
ALTER SYSTEM SET max_files_per_process = 65536;

注意：max_connections 并不是越大越好。连接数太多会导致上下文切换开销增加，反而拖慢整体性能。更合理的做法是在应用层配好连接池，控制活跃连接数，而不是无脑放开数据库上限。

4.3 重启生效与验证

参数修改后需要重启 openGauss 才能生效。如果你使用的是 openGauss 的 gs_ctl 命令，可以这样操作：

bash复制# 以 omm 用户执行
su - omm
gs_ctl restart -D /your/data/path

重启后，务必按顺序确认三层限制是否全部到位：

bash复制# 确认系统级
cat /proc/sys/fs/file-max

# 确认用户级（注意 su 切换后再执行，或者直接看进程的 limits）
su - omm -c 'ulimit -n'
cat /proc/$(pidof gaussdb)/limits | grep -i 'open files'

# 确认数据库内部参数
gsql -d postgres -c "SHOW max_connections;"
gsql -d postgres -c "SHOW max_files_per_process;"

随后压测或模拟业务流量，观察 fd 使用率是否维持在安全水位。如果使用率稳定在 60% 以下，说明配置余量充足；如果再次逼近上限，就要回到第 3.3 节的方法判断是否存在泄漏。

4.4 Navicat 等客户端连接异常的处理

很多朋友用 Navicat 连 openGauss 时报“server closed the connection unexpectedly”，其实这正是服务端 fd 耗尽后的表现之一。服务端日志里通常能看到前文提到的同类报错，客户端却只会收到一个连接被关闭的模糊提示。

这里有个容易忽略的点：Navicat 或 DBeaver 这类图形化工具，连接配置里往往默认勾选了“自动连接”或“保持连接”，一旦服务端 fd 耗尽，工具会反复重试，反而加剧服务端压力。所以在解决“Too many open files”的告警期间，建议先暂停或缩减客户端的重试频率，等服务端参数调整到位后再恢复。

另外，如果你在客户端连接时看到“remaining connection slots are reserved for non-replication superuser connections”这类提示，那是连接数已经达到了 max_connections 上限，和 fd 耗尽不完全是一个问题，但排查思路类似：先看系统 fd 水位，再看连接数，最后看进程内部打开文件情况。两层问题经常同时出现，我的习惯是一次性都检查一遍，避免按下葫芦浮起瓢。

5. 踩坑记录与日常防护建议

5.1 我踩过的几个坑

第一个坑：只调 ulimit 不调 systemd。之前有一套测试环境，我在 /etc/security/limits.conf 里给 omm 用户设置了 100 万 nofile，ulimit -n 手动执行也显示正常，但 service 方式重启数据库后依然报错。查了半天才发现 systemd 服务文件里没有配置 LimitNOFILE，进程实际限制还是 1024。这个问题很容易被忽略，因为很多 openGauss 部署文档都假设你是前台手动启动的。

第二个坑：max_files_per_process 调得过低。有一次批量导入数据，单个 SQL 涉及几千个分区表，分区文件全部需要打开，默认 1000 完全不够，直接报错。但日志里没有明确提示是哪个参数触发的，还是靠统计进程 fd 数量才定位到。后来我把这个参数调到了 131072，才算彻底稳住。

第三个坑：只看进程 fd 总数，忽视时间趋势。有一回我调完所有参数，fd 数量从 5000 降到了 2000，以为问题解决了，结果两天后又爆了。后来用定时采集脚本查看了趋势，发现 fd 在业务低峰期也缓慢爬升，最终确认是应用侧连接池的 minIdle 配置过高，连接长期不释放，加上某些慢查询持有文件句柄不归还，形成缓慢泄漏。这个教训让我明白，配置调优只是第一步，后续监控必须跟上。

5.2 监控与巡检建议

建议把以下指标纳入巡检，最好跟监控系统打通，设置告警阈值：

• openGauss 进程当前 fd 数量 / 进程 nofile 限制，超过 70% 就告警；
• 系统全局 file-nr / file-max 使用率，超过 80% 就告警；
• 数据库当前活跃连接数，超过 max_connections 的 70% 就告警；
• 慢查询数量与执行时间趋势。

一个很实用的小脚本，可以放到 crontab 里定期执行：

bash复制#!/bin/bash
PID=$(pidof gaussdb)
if [ -n "$PID" ]; then
  FD_COUNT=$(ls /proc/$PID/fd | wc -l)
  NOFILE=$(grep 'open files' /proc/$PID/limits | awk '{print $4}')
  echo "$(date '+%Y-%m-%d %H:%M:%S') fd=$FD_COUNT limit=$NOFILE"
fi

把输出重定向到日志文件，每周扫一遍趋势，基本能在业务受影响之前发现问题。这个脚本特别适合没有完整监控平台的团队，简单但有效。

5.3 常见问题速查表

重要提醒：max_connections 调大的同时，要确认内存是否足够。每个连接都会占用一定的缓存和上下文内存，几百个连接看似不大，算上排序、临时表等消耗，内存压力不可小觑。我在一份配置里把连接数从 100 调到 500，结果静态内存占用直接多出几个 GB，差点把机器打满。

这个报错本身不复杂，但折腾过一轮之后，我最大的感受是“配置一致性”比“单个参数数值”更重要。系统级、进程级、数据库级三处限制必须对齐，再加上一套能反映趋势的监控，才能真正睡得着觉。如果你现在也在为同类问题头疼，按照这篇文章的排查顺序走一遍，你会发现大多数根子上的问题，其实都是初始部署时遗漏了某一层限制设置而已。

最后再分享一个我长期坚持的小习惯：每次调整完这类资源限制参数，我都会把当时的业务峰值连接数、fd 使用率、内存水位这几个数据记录到变更文档里。下次再遇到容量评估，不用猜，翻记录就能找到依据。也建议你在自己的环境里留一份这样的基线数据，配合监控趋势使用，比重建一台环境或者翻聊天记录找历史配置靠谱得多。