Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring
От | Jakub Wartak |
---|---|
Тема | Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring |
Дата | |
Msg-id | CAKZiRmzxj6Lt1w2ffDoUmN533TgyDeYVULEH1PQFLRyBJSFP6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
Hi Andres, On Sun, Sep 21, 2025 at 6:29 PM Andres Freund <andres@anarazel.de> wrote: [..] > This seems too low-level for end user docs, while not explaining that the > impact is due to a high max_connections value, rather than a large number of > actually established connections. How about something like > > Note that for optimal performance with <literal>io_uring</literal> Linux > kernel version >= 6.5 is recommended. Older Linux versions, high values > of <xref linkend="guc-max-connections"/> will slow down connection > establishment and termination. Agreed, attached v2. Just one nitpick -- wouldn't '>> On << older Linux versions ' sound better there? [..v1 patch] > > To me this seems too verbose, particularly because the majority of users > encountering it have zero chance to address the issue. And it's not like most > real world workloads are particularly affected, if you run with > max_connections=20k and have 100/connections second, you'll have a *lot* of > other problems. > Here's the full log of a start with the fallback branch forced: [..] > Close to half the lines are the new warning. 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. -J.
Вложения
В списке pgsql-hackers по дате отправления: