Автовакуум кладет прод на таблице в 700 гигов, я уже все перекрутил

[rawgoblin]

PostgreSQL 15.6, самописная аналитика, таблица events на 700 гигов, около 4 млрд строк. Пишем append-only, апдейтим только последние сутки (статусы обработки). Раз в несколько дней приходит автовакуум и начинается: iowait под 80, латенси API с 40мс прыгает до 600, алерты, паника.

Что уже крутил. autovacuum_vacuum_cost_limit поднимал до 2000, потом наоборот опускал до 400 с cost_delay 10ms. В первом случае вакуум быстрее, но кладет диск, во втором ползет двое суток и держит xmin, раздувается все остальное. autovacuum_vacuum_scale_factor для таблицы поставил 0.01, чтобы чаще и помельче. Стало чаще и все равно больно.

Диск network-ssd в Яндекс облаке, лимит 12к IOPS. Чувствую, проблема где-то тут, но переезд на local-ssd это отдельный квест с потерей живой миграции.

Куда копать? Партиционирование предлагали, но это переписывать половину запросов.

[causious]

партиционирование и есть ответ, остальное припарки. Режьте по месяцам через декларативные партиции, pg_partman автоматизирует создание. Вакуум будет ходить только по свежей партиции, где апдейты, старые он перестанет трогать вообще, там нет мертвых строк. И запросы переписывать почти не придется, если ключ партиционирования попадает в where, у вас же наверняка везде фильтр по дате.

700 гигов одним куском это не только вакуум. Это еще индексы, которые не лезут в память, и невозможность дешево дропнуть старье. Вы старые данные сейчас как удаляете? delete? вот вам и главный источник bloat.

[lentyaj]

12к iops на 4 млрд строк, серьезно? вы пытаетесь тюнингом конфига компенсировать диск уровня 2015 года. local-ssd или нормальное железо, потом уже про вакуум разговаривайте

[hogan20]

а fillfactor у таблицы какой? при апдейтах последних суток fillfactor 90 даст HOT апдейты, и вакууму будет сильно меньше работы. и покажите pg_stat_user_tables, интересен n_dead_tup перед запуском вакуума

[asyncmonk]

@hogan20, таблица events. каждый раз events. потом в ней 40 типов событий и json на 3кб в каждой строке, угадал?

[tomcruz]

fillfactor дефолтный 100, про HOT не подумал, спасибо, попробую. json есть, но маленький, не угадал) Старье удаляем deletом раз в квартал, и да, после этого как раз приходит самый адовый вакуум. Похоже, все-таки партиции. Буду продавать менеджменту неделю на переделку.

[simmeon1]

у нас был почти один в один кейс, 15.4, таблица на терабайт. сделали партиции по неделям, старье дропаем через drop table, вакуум из топа проблем ушел совсем. на переделку ушло 2 недели на двоих, окупилось за месяц. единственное, глобальных индексов в пг нет, уникальность только через ключ партиционирования, имейте в виду