public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date: Tue, 11 Feb 2025 17:27:09 -0500
Message-ID: <xvd2cyrtd4wk42ugweydxfcy3bwtaymu4gqmky5fpfcu6xia4m@qbgeq23yncch> (raw)
In-Reply-To: <[email protected]>
References: <CAGECzQQh6VSy3KG4pN1d=h9J=D1rStFCMR+t7yh_Kwj-g87aLQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<7u7dbn6s2i6bf3hjzkbqaexj2bpoblqxwbkffbetl4rjv6dcom@s2uickjc5z53>
	<[email protected]>

Hi,

On 2025-02-11 16:18:37 -0500, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > And when using something like io_uring for AIO, it'd allow to
> > max_files_per_process in addition to the files requires for the io_uring
> > instances.
>
> Not following?  Surely we'd not be configuring that so early in
> postmaster start?

The issue is that, with io_uring, we need to create one FD for each possible
child process, so that one backend can wait for completions for IO issued by
another backend [1]. Those io_uring instances need to be created in
postmaster, so they're visible to each backend. Obviously that helps to much
more quickly run into an unadjusted soft RLIMIT_NOFILE, particularly if
max_connections is set to a higher value.

In the current version of the AIO patchset, the creation of those io_uring
instances does happen as part of an shmem init callback, as the io uring
creation also sets up queues visible in shmem. And shmem init callbacks are
currently happening *before* postmaster's set_max_safe_fds() call:


	/*
	 * Set up shared memory and semaphores.
	 *
	 * Note: if using SysV shmem and/or semas, each postmaster startup will
	 * normally choose the same IPC keys.  This helps ensure that we will
	 * clean up dead IPC objects if the postmaster crashes and is restarted.
	 */
	CreateSharedMemoryAndSemaphores();

	/*
	 * Estimate number of openable files.  This must happen after setting up
	 * semaphores, because on some platforms semaphores count as open files.
	 */
	set_max_safe_fds();


So the issue would actually be that we're currently doing set_max_safe_fds()
too late, not too early :/

Greetings,

Andres Freund

[1] Initially I tried to avoid that, by sharing a smaller number of io_uring
    instances across backends. Making that work was a fair bit of code *and*
    was considerably slower, due to now needing a lock around submission of
    IOs. Moving to one io_uring instance per backend fairly dramatically
    simplified the code while also speeding it up.

view thread (16+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
  In-Reply-To: <xvd2cyrtd4wk42ugweydxfcy3bwtaymu4gqmky5fpfcu6xia4m@qbgeq23yncch>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox