| 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 |
| 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 |