Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
От | Andres Freund |
---|---|
Тема | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? |
Дата | |
Msg-id | 5epj4zwoyudmqopdnjwf2sgykp676frlwofvp52khymqopfzwj@fnakznx7i7iv обсуждение исходный текст |
Ответ на | Re: Potential "AIO / io workers" inter-worker locking issue in PG18? (Marco Boeringa <marco@boeringa.demon.nl>) |
Ответы |
Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
|
Список | pgsql-bugs |
Hi, On 2025-10-06 18:09:25 +0200, Marco Boeringa wrote: > I should have phrased it better. The high processor and core activity is not > unexpected. The code is designed to saturate the processor and maximize > throughput by careful design of the Python threading stuff. It is just that > all the jobs send to PostgreSQL via ODBC for the specific step in the > processing and with the small Italy extract, should return in less than 10 > seconds (which they do in those lucky runs I do not observe the issue), but > some of the jobs for the specific step don't, e.g. 30 jobs return within 10 > seconds, then the remaining 14 unexpectedly get stuck for 2 hours before > returning, all the while staying at the same high core usage they were > initiated with. > So some of the PostgreSQL database sessions, as I already explained show up > in pgAdmin as 'active' with no wait events or blocking pids, simply take an > excessive amount of time, but will ultimately return. We need a profile of those processes while they use excessive amount of time. If they don't have wait events they're using CPU time, and seeing a profile of where all that time is spent might provide enough information where to look in more detail. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: