Hacker News Digest

PostgreSQL 18 представил новую опцию конфигурации io_method, дающую пользователям больше контроля над обработкой дискового ввода-вывода. В отличие от версии 17, где использовались только синхронные запросы, в 18 доступны три режима: sync (старое поведение), worker (новый стандарт по умолчанию с фоновыми процессами) и io_uring (асинхронный интерфейс Linux для чтения с диска).

В ходе тестирования с использованием sysbench на базе данных размером ~300 GB на различных конфигурациях EC2 были получены неожиданные результаты. При одиночном подключении и сетевых хранилищах (gp3, io2) версии 18 в режимах sync и worker показали производительность выше, чем 17 и 18 с io_uring. Полные результаты для высококонкурентных сценариев и быстрых NVMe-накопителей еще ожидаются.

• Обсуждение подтвердило, что при использовании локального NVMe диска разница между 17 и 18 версиями PostgreSQL незначительна, но при этом сетевое хранилище всё ещё сильно уступает по производительности.
• Участники отметили, что важно понимать, что при использовании облачного хранилища вы платите не за IOPS, а за то, чтобы кто-то другой имел дело с резервным копированием, репликацией и обслуживанием оборудования.
• Также было отмечено, что в настоящее время PostgreSQL не поддерживает прямой ввод/вывод, но над этим ведётся работа.
• Были высказаны опасения, что использование VPS с локальным диском может повлечь за собой вопросы надёжности, так как такие диски, как правило, не имеют избыточности.
• В контексте обсуждения также поднялся вопрос о том, что влияние на производительность может оказать использование или отсутствие расширения, такого как TimescaleDB.

TL;DR
Чтение напрямую с диска быстрее, чем из кеша в памяти: пропускная способность SSD растёт, а латентность памяти стоит на месте. Нужны новые инструменты.

Эксперимент

• Задача: подсчитать количество десяток в 50 ГБ псевдослучайных int.
• Железо: AMD EPYC 7551P, 96 ГБ DDR4-2133, два Samsung PM983a PCIe 3.0 SSD (3,1 ГБ/с каждый) в RAID-0.
• Ограничения:
  • Память: 13 ГБ/с на поток (3 канала × 2133 МТ/с × 8 Б / 4 NUMA-домена).
  • Диски: 6,2 ГБ/с суммарно.

Код

int* data = mmap(..., size, PROT_READ, MAP_SHARED, fd, 0);
for (...) if (data[i] == 10) count++;

Результаты

• Первый запуск (с диска): 0,61 ГБ/с — ограничение диск.
• Второй запуск (из кеша): 3,71 ГБ/с — всё ещё ниже пропускной способности памяти.
• Бутылочное горлышко: не векторизованный цикл, ~3–4,5 млрд инструкций/с.

• mmap тормозит из-за последовательных page-fault и 4 Кб страниц; io_uring на 6 потоках читает буферы заранее и просто отдаёт готовые.
• Пропущены MAP_POPULATE / MADV_SEQUENTIAL / hugepages — без них сравнение «mmap vs io_uring» нечестое.
• Автор признаёт кликбейтное название «Memory is slow, Disk is fast»; суть: «RAID-0 NVMe даёт больше пропускной канала, чем DDR5-каналов на тестовой машине».
• Под капотом io_uring + O_DIRECT сам управляет кэшем, mmap же полагается на page-cache ядра.
• PCIe-5 ×128 линий серверных CPU уже >1 ТБ/с, что выше DDR5-6400 12-канального узла (~600 ГБ/с), но данные всё равно идут в RAM перед CPU.

Как выжать максимум из файлового IO в Linux на Zig + io_uring

Тест

• Железо: Ubuntu 24.04, 6.14, NVMe, 32 ядер, 756 ГБ ОЗУ (не влияет, direct_io).
• Параметры: 512 КБ блок, очередь 64, 16 ГБ файл, один поток.

Результаты

	fio	Zig
write	4.08 ГБ/с	3.80 ГБ/с
read	7.33 ГБ/с	7.00 ГБ/с

Zig на 5–7 % медленнее fio, но близко к пределу SSD.

Ключевые фишки реализации

1. Полл-режим (IOPOLL) + nvme.poll_queues=16 → прерывания не нужны.
2. Два экземпляра io_uring: один с IOPOLL (только read/write), второй – для остального.
3. Зарегистрированные буферы: память выделяется заранее, пользователь получает/возвращает готовые блоки.
4. Выравнивание:
   • чтение – внутренняя «перехватка» невыравненных запросов;
   • запись – пользователь сам выравнивает, иначе лишние read-modify-write.
5. Без слияния IO внутри библиотеки – проще и гибче на уровне приложения.

Код: steelcake/csio

• Пользователи указывают, что 7 ГБ/с при 512 КБ блоках — это всего ~14 000 IOPS (~70 мкс/IO), и требуется лишь 1 предзагрузка для полной полосы.
• Напоминают, что Zig 0.15.1 всё ещё меняет IO-API, поэтому версию нужно явно указывать в посте.
• Рекомендуют проверить/увеличить логический блок NVMe до 4 КБ через nvme-format вместо хардкода ALIGN=512.
• Разница 4,08 ГБ/с (fio) и 3,80 ГБ/с (Zig) объясняется путаницей GiB ↔ GB.
• Для io_uring важно использовать registered fds — дают заметный прирост.
• Интересуются, как будет работать тот же код на FreeBSD AIO.
• Предлагают вместо «овераллокации» брать выровненную память через page-аллокатор.

• Удалено: устаревшие устройства sga и xenfv; опция -no-user-config.
• Новые пометки: -machine dump-guest-core=on, query-cpus-fast, query-cpu-definitions – deprecated.

Архитектуры

• 68k: поддержка q800 и macos9.
• ARM: новые SoC imx8mn, stm32h735, xlnx-zynqmp-ep108; машины mps3-an547, raspi5; эмуляция FEAT_SVE2, FEAT_MTE2, FEAT_LSE2.
• RISC-V: добавлены zacas, sstc, svadu, smstateen; машины spike-1.11, microchip-polarfire.
• x86: AMD SEV-SNP, Intel AMX, AVX-VNNI; KVM-TCG совместимость.

Устройства

• ACPI: поддержка SRAT для NVDIMM.
• Audio: Intel HDA теперь 24-бит.
• Block: virtio-blk/SCSI – discard=unmap, write-zeroes=unmap.
• Graphics: virtio-gpu – 3D, virglrenderer 1.0.
• NVMe: CMB, PMR, ZNS.
• PCIe: SR-IOV, ARI, ATS, PASID.
• USB: xHCI – USB 3.2 SuperSpeed+.

Прочее

• Multi-process: x-vhost-user-fs и vhost-user-vsock теперь в отдельном процессе.
• Сеть: vhost-vdpa – offloading checksum/TCP.

• QEMU восхищает пользователей: «просто работает», хорошо интегрируется и кажется «магией».
• Его применяют для dev-окружений, запуска ПО на других ОС, разработки новых ОС, а также в облаках.
• KVM ускоряет QEMU, предоставляя аппаратную виртуализацию через page-tables и trap-механизмы.
• Появилась экспериментальная сборка в WASM, что открывает онлайн-песочницы для разных архитектур.
• Поддерживается запуск Android-VM (Cuttlefish, официальный Android-emulator на базе QEMU).
• Утилиты вроде QuickEMU и UTM упрощают запуск ВМ, а пожертвования идут через Software Freedom Conservancy.

Поисковый индекс Marginalia переписан, чтобы лучше использовать NVMe-накопители.
Основные изменения:

• Объём: после ослабления фильтров и добавления рекламного детектора база выросла с 350 до 800 млн документов; ожидается дальнейший рост при добавлении новых языков.
• Структура: обратный индекс остался «картой терм → список (документ, позиции)», но B-дерево теперь читается в режиме O_DIRECT, минуя кэш страниц.
• Чтение:
  • Буферизованные чтения неэффективны при случайном доступе к файлам, превышающим RAM.
  • Прямые чтения требуют выравнивания по 512/4096 Б, но дают стабильную задержку и не копируют данные лишний раз.
  • В Linux появляется RWF_DONTCACHE, но поддержка пока неполная.

Первая оптимизация — переписать B-дерево под O_DIRECT; дальнейшие шаги ещё описываются.

• 128–256 КБ считаются «классическим» оптимальным размером блока, но в 2024 г. всё чаще замеряют индивидуально: всё зависит от архитектуры I/O.
• Для NVMe при высокой параллельности 4 КБ работает не хуже, если использовать AsyncIO/IO_uring или SPDK и выдавать много одновременных запросов.
• Меньшие блоки экономят чтение, но не избавляют от внутреннего read-amplification SSD; нужно знать минимальный физический размер чтения контроллера.
• Формат LBA (512 B vs 4 КБ+) и опции sysfs (optimal_io_size) влияют на производительность и стоит их проверять.
• В задачах индексного поиска параллельность ограничена, поэтому крупные блоки остаются практичным выбором при отсутствии точных данных о «железе».

PCI-SIG анонсировала PCIe 8.0

• Пропускная способность вдвое выше PCIe 7.0: до 256 ГТ/с на линию.
• Технология: PAM4, 32 ГТ/с, 0,5 В амплитуда, < 1 Вт/лейн энергопотребление.
• Обратная совместимость с предыдущими поколениями.
• Спецификация выйдет в 2027 г., первые продукты — 2028–2029 гг.
• Цели: ИИ-акселераторы, HPC, NVMe-накопители, 800 Гбит/с сети.

• Кто-то предлагает «перевернуть» архитектуру: пусть GPU-PCB станет материнской платой, а CPU с памятью встаёт в PCIe-слот.
• Обсуждают, что PCIe-спецификация всегда на три поколения впереди реальных продуктов: сейчас в работе уже Gen 8.
• Пользователи жалуются на нехватку линий PCIe в десктопах и мечтают о GPU-сокете с собственными слотами RAM.
• EE и другие специалисты считают это скорее проблемой экосистемы и совместимости, чем чисто инженерной.
• Упоминают, что в дата-центрах (DGX, DPU, NVMe-«без-сервера») похожая идея уже реализована.