Re: Automatically sizing the IO worker pool

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Automatically sizing the IO worker pool
Date: 2026-04-11 06:35:18
Message-ID: CA+hUKGLh5vzNfw85aumuMU5WdCnVCpB49LF60q7Vnu0g+2EYGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 30, 2025 at 10:15 PM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> As a side note, I was trying to experiment with this patch using
> dm-mapper's delay feature to introduce an arbitrary large io latency and
> see how the io queue is growing.

FWIW, here's what I came up with while experimenting with that sort of thing:

shared_preload_libraries=io_limit
io_limit.ios_per_second=6000

That differs from eg dm-mapper delays by making everything seem like
slow direct I/O, which seemed more interesting for this project. For
example if you run some continuous workload while you SET
io_limit.ios_per_second to various numbers, with
io_workers_idle_timeout set fairly low, you can monitor the pool
adjustments.

Attachment Content-Type Size
0001-contrib-io_limit-Simulation-of-slow-storage.patch text/x-patch 12.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2026-04-11 07:57:21 Re: pg17: XX000: no relation entry for relid 0
Previous Message SATYANARAYANA NARLAPURAM 2026-04-11 05:26:12 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication