Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring

On 9/22/25 10:45, Jakub Wartak wrote:
> ...
> I see two paths forward:
> 
> 1. either we make it shorter, but I do not know if a multi-sentence
> error message isn't against some project's policy? Feel free to
> readjust as necessary, I'm not strongly attached to the exact wording
> , just to hint people.
> 2. maybe we could emit the warning only in certain criteria, like
> if(max_connections>1000) for example. However Mark (OP) reported it
> even for the value of 100 so it seems we should warn about it like
> always? (and it deteriorated 3x for him @ 1000 max_connections), so
> it's like opening a new can of worms (to establish a proper
> threshold).
> 
> Anyway attached v2 generates:
> 
> 2025-09-22 09:56:21.123 CEST [12144] WARNING:  io_uring combined
> memory mapping creation failed: Unknown error -8192. Upgrade kernel to
> 6.5+ for improved performance
> 2025-09-22 09:56:21.179 CEST [12144] LOG:  starting PostgreSQL 19devel
> on x86_64-linux, compiled by clang-16.0.6, 64-bit
> 2025-09-22 09:56:21.180 CEST [12144] LOG:  listening on IPv6 address
> "::1", port 1236
> 2025-09-22 09:56:21.180 CEST [12144] LOG:  listening on IPv4 address
> "127.0.0.1", port 1236
> 2025-09-22 09:56:21.185 CEST [12144] LOG:  listening on Unix socket
> "/tmp/.s.PGSQL.1236"
> 2025-09-22 09:56:21.197 CEST [12147] LOG:  database system was shut
> down at 2025-09-22 09:55:44 CEST
> 2025-09-22 09:56:21.207 CEST [12144] LOG:  database system is ready to
> accept connections
> 
> BTW: on RHEL/derivatives it was possible to push people in certain
> critical conditions into using kernel-lt/kernel-ml (but that's from
> EPEL repos) , so it's not that they do not have space for maneuver.
> 

The v2 patch got no response for 1+ month, it seems. I see it adds info
to two places - sgml docs and elog().

I'm skeptical about the elog() changes. Maybe the log level change would
be good? But as Andres pointed out the people seeing this may not have a
chance to address the issue.

I don't think we should add references to particular kernel version into
our log messages. We'd need to make sure it does not get stale, stuff
may get backpatched (even if it's unlikely in this case), and so on.
There are likely plenty other places where the behavior (or performance)
depends on the kernel version - so why would this particular case be
special? I just don't see this as very helpful.

I'm not sure about adding the exact kernel version to the docs either.
There's exactly two references to a particular kernel version (and
that's pg_combinebackup/pg_upgrade referencing to 4.5). There's an
implicit understanding that newer kernel versions are faster, especially
for recently introduced features (like io_uring).

It'd probably make sense to have a section about io_uring tuning in
general. Maybe it should mention even the kernel version, not sure. But
it could mention other related stuff, like the need to increase the file
descriptor limit, etc.


regards

-- 
Tomas Vondra