Скажите, а долгие это, примерно, какого размера?
если у вас тикает несколько десятков-сотен тысяч транзакций в час, то иметь что-то дольше 10 минут — к проблемам.
Больше 10 минут не было замечено, но я ещё внимательно посмотрю. Быть может что-то иногда прилетает. А к каким проблемам это может привести? Чёт с ходу и не соображу
Ошибки вида "не удалось получить блокировку за N секунд, запрос откачен".
к тем, которые вы и наблюдаете — распухание таблиц и индексов. как написал Ярослав — натсройки автовакуума должны быть агрессивными
А как аггресивность влияет на распухание индексов? Тоже в районе 9.4 встречался с такой проблемой, без reindex ничего не вышло.
Автовакуум агрессивный, очень часто срабатывает на таблице. Примерно раз в 3-4 часа
select name,setting from pg_settings where name ~ 'autovac' and source not in ('default','override');
Эээ... непосредственно? Т.е. если не считать крайних случаев (с "удачными" update/delete, которые оставляют листовые страницы почти пустыми), какая ещё может быть причина существенного (более, чем в три раза, примерно) "распухания"?
Когда-то очень давно, я просто делал рядом новый, чистенький и компактненький индекс, проверял, что постгрес успешно им пользуется вместо старого и затем удалял старый. Метод называется "Спасение утопающих — дело рук самих утопающих.".
Да так и делаю сейчас, ручками, смотрю на pg_repack, но чет ссусь. А то таскать бекап 1.5ТБ базы, больно и долго для прода. Сегодня - завтра потыкаю в pg_repack на тестовой среде
Мой - хоть и старый - опыт работы с pg_repack сугубо положительный.
у вас же 12-я версия, запускаете в psql \set relname table_name SELECT format(' REINDEX (verbose) INDEX CONCURRENTLY %s; /* %s/%s - %sMB */', indexrelid::regclass, row_number() OVER (ORDER BY pg_relation_size(indexrelid)), count(*) OVER (), (pg_relation_size(indexrelid)/1024.0/1024)::int8) FROM pg_index WHERE indrelid=:'relname'::regclass ORDER BY pg_relation_size(indexrelid)\gexec
Обсуждают сегодня