PostgreSQL 18 preview - 打开文件数限制更新, 为异步IO io_uring做准备

PostgreSQL 18 preview - 打开文件数限制max_files_per_process更新, 为异步IO io_uring做准备

PostgreSQL 18 将max_files_per_process改为控制每个进程额外可打开的文件数，而非总数。继承的文件不再占用该配额。

后端进程可打开的文件总数 = 继承的文件数 + max_files_per_process，确保高并发下仍能分配足够资源，尤其适配将要发布的异步IO方法: io_uring新特性。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=adb5f85fa5a00d6d5759df55feb16dc22b0fc8d7

Redefine max_files_per_process to control additionally opened files master github/master  
author Andres Freund <[email protected]>   
Mon, 24 Mar 2025 22:20:18 +0000 (18:20 -0400)  
committer Andres Freund <[email protected]>   
Mon, 24 Mar 2025 22:20:18 +0000 (18:20 -0400)  
commit adb5f85fa5a00d6d5759df55feb16dc22b0fc8d7  
tree a65425a8f98628242b91b032d791d7d28dc261fd tree  
parent 7d559c8580f722dc40f2c34573e53e33626679e0 commit | diff  
Redefine max_files_per_process to control additionally opened files  
Until now max_files_per_process=N limited each backend to open N files in
total (minus a safety factor), even if there were already more files opened in
postmaster and inherited by backends.  Change max_files_per_process to control  
how many additional files each process is allowed to open.  
The main motivation for this is the patch to add io_method=io_uring, which
needs to open one file for each backend.  Without this patch, even if
RLIMIT_NOFILE is high enough, postmaster will fail in set_max_safe_fds() if
started with a high max_connections.  The cause of the failure is that, until  
now, set_max_safe_fds() subtracted the already open files from  
max_files_per_process.  
Reviewed-by: Noah Misch <[email protected]>  
Discussion: https://postgr.es/m/w6uiicyou7hzq47mbyejubtcyb2rngkkf45fk4q7inue5kfbeo@bbfad3qyubvs  
Discussion: https://postgr.es/m/CAGECzQQh6VSy3KG4pN1d=h9J=D1rStFCMR+t7yh_Kwj-g87aLQ@mail.gmail.com  

AI 解读

该补丁对PostgreSQL的max_files_per_process参数进行了重要调整，以解决高并发场景下的文件描述符限制问题。以下是核心要点解读：

1. 原有问题

• 参数定义限制：原max_files_per_process=N限制每个后端进程总共可打开N个文件（扣除安全预留）。即使postmaster已打开大量文件（如日志、SSL文件）并由子进程继承，这些继承的文件数也会被计入N的限制。
• 高并发瓶颈：当使用需要大量文件描述符的功能（如io_uring每个后端需一个文件）时，若max_connections设置过高，即使系统软硬限制（RLIMIT_NOFILE）足够，postmaster仍可能因set_max_safe_fds()计算方式失败。例如，postmaster已继承100个文件，max_files_per_process=1000时，后端仅能再开900个，导致资源不足。

2. 解决方案

• 参数语义重定义：将max_files_per_process改为控制每个进程额外可打开的文件数，而非总数。继承的文件不再占用该配额。
• 资源分配优化：后端进程可打开的文件总数 = 继承的文件数 + max_files_per_process，确保高并发下仍能分配足够资源，尤其适配io_uring等新特性。

3. 技术影响

• set_max_safe_fds调整：修改相关逻辑，不再从max_files_per_process中扣除已继承文件数，直接将其作为额外可打开的上限。
• 系统限制适配：总文件数仍受系统硬限制（RLIMIT_NOFILE）约束，需确保参数配置不超过此值，避免资源耗尽。

4. 实际收益

• 提升稳定性：避免因继承文件数过多导致后端进程提前达到限制，减少手动调整需求。
• 支持新特性：为io_uring等依赖高文件描述符的功能铺平道路，助力性能优化。
• 简化配置：用户无需复杂计算继承文件数，直接根据额外需求设定max_files_per_process。

5. 评审与讨论

• 经Noah Misch审核，确认修改的合理性与兼容性。
• 讨论线程深入探讨了不同平台适配性及资源管理策略，确保变更安全可靠。

此补丁通过参数语义的巧妙重定义，解决了长期存在的资源分配瓶颈，提升了PostgreSQL在高负载场景下的健壮性与扩展性。