Re: Potential "AIO / io workers" inter-worker locking issue in PG18?

Поиск
Список
Период
Сортировка
От Marco Boeringa
Тема Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Дата
Msg-id 5ced59ef-72b1-4880-921a-5204413b0b22@boeringa.demon.nl
обсуждение исходный текст
Ответ на Re: Potential "AIO / io workers" inter-worker locking issue in PG18?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Potential "AIO / io workers" inter-worker locking issue in PG18?
Список pgsql-bugs
Hi Andras,

I am not really a Linux / Ubuntu expert. Can you give me a suggestion 
for how to create such a CPU profile for the specific PostgreSQL 
processes getting stuck?

Marco

Op 6-10-2025 om 18:13 schreef Andres Freund:
> 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 по дате отправления: