Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup

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

In response to

Responses

Browse pgsql-hackers by date

  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