Postgres не повільний. Повільне ваше сховище: резюме доповіді POSETTE 2026

Підготовка бенчмарку

На POSETTE 2026 Sai Srirampur представив доповідь „Postgres Isn't Slow. Your Storage Is“, у якій розглянуто, як продуктивність сховища впливає на PostgreSQL під час масштабування. У презентації було виділено п'ять частих симптомів: повільний інгест, непослідовна латентність читання, відставання автовакууму, повільні checkpoint та відставання логічної реплікації. Ці проблеми часто мають один і той самий корінь у продуктивності сховища, коли робочі набори перевищують доступну пам'ять.

Щоб виділити сховище як змінну, у бенчмарку використовувалося вісім ідентичних кластерів PostgreSQL: чотири на instance-store NVMe та чотири на базовому gp3 EBS з 3000 IOPS. Кожен кластер працював на інстансі m6id.4xlarge з 16 vCPU, 64 GiB RAM та 16 GiB shared_buffers. Робоче навантаження використовувало 482 GiB pgbench_accounts heap, який містив 3,3 мільярди рядків, і протягом п'яти хвилин виконувало висококонкурентне навантаження random-UPDATE з 64 клієнтами та 16 worker thread.

Що показали результати

Бенчмарк показав медіанні 16 030 TPS для кластерів NVMe, тоді як на EBS — 1 734 TPS, тобто різниця 9,24 рази. Медіанна латентність транзакцій впала з 36,9 ms до 4,0 ms. Для технічних операцій NVMe виконав VACUUM на 10 GB bloat за 366 секунд, на EBS — за 964 секунди, а 10 GB логічного беклогу реплікації завершив за 139 секунд замість 238.

Розбивка латентності показала, що читання сторінок на EBS займало приблизно 19 ms, на NVMe — 0,3 ms, WAL fsync додавав 11 ms замість 1,5 ms, а overhead блокувань і планувальника становив 5 ms замість 0,2 ms. Використання CPU в обох випадках було приблизно однаковим, близько 2 ms. Знімок pg_stat_activity показав, що з 64 backend на EBS 29 очікували IO:DataFileRead, на NVMe — лише дев'ять. У 240-секундному вікні профілювання NVMe хост накопичив 2 253 CPU-секунд, EBS хост — лише 251, що вказує на те, що процеси EBS значно більше часу проводили поза CPU, в очікуванні сховища.

Postgres на базі NVMe у продакшені

Архітектура продакшену, представлена в доповіді, відповідає обмеженням стійкості instance-store NVMe трьома вимогами: реплікуйте базу даних, щоб сервіс пережив втрату node, зберігайте бекапи та дані відновлення на окремих машинах і планується ємність з урахуванням доступного NVMe для кожного instance type.

Перший патерн — синхронна реплікація на базі quorum з двома кандидатами standby, з конфігурацією, наприклад, ANY 1 (standby1, standby2), що дозволяє транзакції отримати commit після підтвердження WAL будь-яким standby. Для стійкості поза вузлами бази даних інструменти з відкритим кодом, такі як WAL-G, можуть виконувати фізичні base backup та неперервне архівування WAL з цільовим RPO у секундах. У доповіді наводяться публічні приклади Instacart та Datadog, які описали запуск PostgreSQL на локальному NVMe для навантажень, чутливих до латентності.

Джерела: clickhouse.com