Re: BUG #19505: Some weird spikes postgresql processes in database (up to 200k sometime) without apparent reasons.

Hi,

On 2026-06-22 23:22:53 +0300, Maxim Boguk wrote:
> >> I started investigation of this issue after found that process count of
> >> postgresql on my replica sometime jump to 200k+ (with max_connections=1000
> >> and real connections under 100 most time).

You say upthread:

> Given that situation happens like 1-10 times per hour (and lead for short LA
> spikes up to 10000) - it's seriously affect the database replica
> performance.

I don't immediately see how the kernel worker thread creations leads to such
an LA and/or replica performance issues.


> Update:  issue had been triggered by unconstrained spawn of helper threads
> for io_method=io_uring
> (thousands/ten thousands of helper "iou-wrk-****" threads per bitmap scan).

Note that these are kernel controlled, not postgres controlled.  Newer kernels
will typically start fewer worker threads, because more of the IO can be
handled "full asynchronously" (i.e. without workers).

What is effective_io_concurrency set to?

I assume io_max_concurrency = -1 ends up with io_max_concurrency = 64 (the max
auto-tuned value)?


> Switching to the io_method=worker fixed problem.

Did that actually fix any performance issues?


> Seems io_uring have some unexpected issues with unconstrained threads spawn.

I don't really see how the query you described could trigger that many kernel
worker threads. Within each backend that should be bound by io_max_concurrency
(or perhaps io_max_concurrency * 2, due to the some kernel partitioning).
That's a far cry from 1620.

Across a parallel query it should be bound by by io_max_concurrency *
#postgres processes involved in query.  Assuming an effective_io_concurrency >
64, and io_max_concurrency = 64, your query shouldn't trigger more than 7 * 64
worker threads (due to the number of workers chosen) - clearly not a small
number, but not 1620 (even if it were not within one process). And even if all
16 workers were used, that's 17*64, still a lot less.

If this is happening with a current kernel, I think you need to make a
bugreport to ubuntu.

Greetings,

Andres Freund