Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-02-12T21:52:52Z
Lists: pgsql-hackers
Attachments
- v2-0001-Bump-pgbench-soft-open-file-limit-RLIMIT_NOFILE-t.patch (text/x-patch) patch v2-0001
- v2-0002-Bump-postmaster-soft-open-file-limit-RLIMIT_NOFIL.patch (text/x-patch) patch v2-0002
- v2-0003-Reflect-the-value-of-max_safe_fds-in-max_files_pe.patch (text/x-patch) patch v2-0003
On Tue, 11 Feb 2025 at 22:18, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andres Freund <andres@anarazel.de> writes: > > My suggestion would be to redefine max_files_per_process as the number of > > files we try to be able to open in backends. I.e. set_max_safe_fds() would > > first count the number of already open fds (since those will largely be > > inherited by child processes) and then check if we can open up to > > max_files_per_process files in addition. Adjusting the RLIMIT_NOFILE if > > necessary. > > Seems plausible. IIRC we also want 10 or so FDs available as "slop" > for code that doesn't go through fd.c. Attached is a patchset that does this. I split off the pgbench change, which is in the first patch. The change to postmaster is in the second. And the 3rd patch is a small follow up to make it easier to notice that max_safe_fds is lower than intended.
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