Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-02-11T19:42:21Z
Lists: pgsql-hackers
Hi, On 2025-02-11 19:52:34 +0100, Jelte Fennema-Nio wrote: > So this starts bumping postmaster and pgbench its soft open file limit > to the hard open file limit. Not sure that's quite the right thing to do for postmaster. What I'd start with is to increase the soft limit to "already used files" + max_files_per_process. That way we still limit "resource" usage, but react better to already used FDs. If io_uring, listen_addresses, whatnot use FDs max_files_per_process would be added ontop. Then we can separately discuss increasing max_files_per_process more aggressively. I don't see a downside to just increasing the soft limit for pgbench. It avoids the stupid cycle of getting "need at least %d open files, but system limit is %ld", increase ulimit, retry, without any non-theoretical downsides. > Doing so is especially useful for the AIO work that Andres is doing, because > io_uring consumes a lot of file descriptors. Yep. One more reason this is a good idea is that we'll also need this for threading, since there all client connections obviously will eat into the "normal file descriptor" budget. Greetings, Andres Freund
Commits
-
Redefine max_files_per_process to control additionally opened files
- adb5f85fa5a0 18.0 landed
-
pgbench: Increase RLIMIT_NOFILE if necessary
- d38bab5edd60 18.0 landed
-
Move extra code out of the Pre/PostRestoreCommand() section.
- 8fb13dd6ab5b 17.0 cited