From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup |
Date: | 2025-02-11 19:42:21 |
Message-ID: | 4qacnswlyykgj6p2gon4pvv7r2cb4adtedguer6pmaktr4xdve@om6ej7u4qw7p |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alena Rybakina | 2025-02-11 19:43:30 | Re: explain analyze rows=%.0f |
Previous Message | Melanie Plageman | 2025-02-11 19:29:14 | Re: pgbench with partitioned tables |