PostgreSQL 18 и io_method=io_uring: у кого какие цифры в проде?

[Kutz]

Обновили основной кластер с 16.6 до 18.3 (Patroni, три ноды, NVMe). Главное, ради чего шли — асинхронный ввод-вывод. Потестил три режима на аналитической реплике, тяжёлый отчёт с seq scan по таблице на 400 ГБ, кеш холодный:

io_method = sync (по-старому) — 211 секунд
io_method = worker (дефолт, io_workers = 3) — 96 секунд
io_method = io_uring — 79 секунд

То есть на чтениях с диска ускорение больше чем вдвое. На OLTP-нагрузке разницы почти нет, что ожидаемо — там всё из shared_buffers. io_workers поднял до 8 по числу ядер реплики, стало ещё чуть лучше дефолта.

Кто ещё гонял 18-ку под реальной нагрузкой? Интересуют грабли, особенно с io_uring.

[icu2]

Гоняем с февраля, грабли есть.

1. io_uring в контейнерах: дефолтный seccomp-профиль Docker и большинства k8s-дистрибутивов режет syscall'ы io_uring. Симптом — постгрес не стартует с ошибкой could not setup io_uring queue. Либо кастомный seccomp-профиль, либо оставайтесь на worker — в контейнерах он и так даёт большую часть профита.
2. AIO в 18-ке покрывает только чтения: seq scan, bitmap heap scan, vacuum. Обычные index scan пока мимо, обещают в 19-й. Если у вас чистый OLTP по индексам — чуда не ждите, вы его и не увидите.
3. Старые ядра: на RHEL 8 и клонах с 4.18 io_uring либо нет, либо он дырявый. Astra 1.8 с ядром 6.6 — ок, Альт p11 — ок.
4. После pg_upgrade в 18-ке наконец переносится статистика планировщика, но расширенную (CREATE STATISTICS) всё равно пересчитывайте руками.

[tx3300]

Мы пока на стейдже, но скажу, что 18-ку стоит брать даже без io_uring. uuidv7() из коробки — выкинули расширение, которым генерили сортируемые uuid, и индексы перестали пухнуть от случайных вставок. Плюс skip scan: составной индекс (client_id, created_at) теперь отрабатывает для запросов без client_id в условии — пара дашбордов ускорилась на порядок без единого нового индекса. В плане это выглядит как обычный Index Scan, смотрите на Buffers: чтений становится в разы меньше.

[wasmsre]

@Kutz, А у тех, кто на Postgres Pro по требованиям заказчика, как с этим? У нас госконтракт, реестровый софт обязателен. В Enterprise-редакции своя реализация асинхронного чтения была и раньше, но интересно, когда они переедут на ванильную 18-ю базу — у них в релизных циклах это обычно плюс полгода-год к мажору.

[fosl0002]

Коллеге выше: PPEE исторически отстаёт примерно на мажор, так и закладывайте. По теме: подтверждаю цифры ТС, у нас на отчётах в стиле «это должно жить в ClickHouse, но живёт тут» (не начинайте) worker дал х1.9, io_uring сверху ещё процентов 15. И не забудьте, что effective_io_concurrency в 18-ке теперь реально работает для seq scan, а дефолт подняли до 16 — на NVMe смело ставьте 64–128.

[krayzie]

Напоминание тем, кто будет переезжать свежим initdb или логической репликацией: в 18-ке контрольные суммы страниц включены по умолчанию. Если старый кластер был без них, pg_upgrade потребует совпадения — либо initdb --no-data-checksums, либо сначала включайте на старом через pg_checksums (даунтайм!). Мы на этом потеряли вечер.