В процессе проведены пусконаладочные работы:
- роутер Mikrotik RB3011UiAS;
- коммутаторы SNR-S2982G-24T-POE, SNR-S298289G-24TX-POE, SNR-S2200G-8T-POE, Planet WGS-4215-16P2S;
- бесшовный wi-fi на базе контроллера Ubiquiti CLOUD KEY GEN2 UNIFI UCK-G2-PLUS, точек доступа UAP-AC-Pro и U6-Pro;
- sip-телефония на базе АТС Grandstream UCM6000A;
- видеонаблюдение на базе севера Trassir;
- контроль доступа Sigur;
- iptv Hoteza.
Может быть когда ни будь в будущем, нейросети и смогут реально помогать в экспериментах , пока лучше не доверять их ответам.
К вопросу о том, что нейросеть в обозримом будущем не может заменить инженера , обладающего данными экспериментов .
У нейросети просто нет экспериментальных данных, но проблема не в этом. Глобальная проблема нейросетей — выдача ответа в условиях недостатка данных.
Сказано уже 100500 раз — ВСЕ ОТВЕТЫ НЕЙРОСЕТИ НУЖНО ПРОВЕРЯТЬ ЭКСПЕРЕМЕНТАЛЬНО, НИКАКОЙ ИНФОРМИИ НЕЙРОСЕТЕЙ ДОВЕРЯТЬ НЕЛЬЗЯ .
Статистически обработать огромные массивы информации — да, тут нейросеть поможет. Но, сделать исследования нового — тут нейросеть принципиально бессильна, у нее просто нет данных. А результат она выдает.
Оценить влияние кардинального снижения параметра хранения таблиц fillfactor c базового значения 100 до 50, при агрессивной настройке autovacuum.
Допустим какой-то продвинутый DBA ,
следующий в русле новых тенденций решил не тратить время и задал вопрос нейросети DeepSeek:
Как повлияет уменьшение параметра fillfactor c 100 до 50 для таблицы с количеством строк примерно 60000000 на количество и время работы autovacuum для СУБД PostgreSQL c ресурсами CPU=2 , RAM=2GB при интенсивных операциях SELECT + UPDATE примерно в среднем 1000 транзакций в секунду, при нагрузке от 5 до 48 одновременных сессиях, при агрессивных настройках autovacuum для тестовой таблицы : autovacuum_vacuum_scale_factor=0 и autovacuum_vacuum_threshold=1000 ?
Уменьшение параметра fillfactor с 100 до 50 для таблицы с 60 млн строк в PostgreSQL при указанных условиях существенно повлияет на работу autovacuum, преимущественно негативно. Вот анализ последствий:
1. Увеличение размера таблицы и фрагментации
Физический рост таблицы:
При fillfactor=50 каждая страница таблицы заполняется только на 50%, что удваивает её физический размер (с ~60 млн строк до эффективных ~120 млн страниц). Это увеличит I/O-нагрузку и объём данных для обработки autovacuum.
Рост индексов:
Индексы также увеличатся, так как новые версии строк (от UPDATE) будут чаще размещаться в новых страницах (из-за нехватки места в исходных), что дополнительно нагрузит autovacuum.
2. Частота запуска autovacuum
Агрессивные настройки:
autovacuum_vacuum_threshold=1000 и autovacuum_vacuum_scale_factor=0 означают, что autovacuum запускается после каждых 1000 изменений (UPDATE/DELETE).
Интенсивность UPDATE:
При 1000 транзакций/сек (часть из которых — UPDATE) порог в 1000 изменений будет достигаться каждую секунду. Это приведёт к почти непрерывной работе autovacuum.
3. Время работы autovacuum
Увеличение длительности циклов:
Autovacuum должен сканировать вдвое больше страниц (из-за fillfactor=50), что резко увеличит время каждого запуска. Например:
При fillfactor=100: сканирование 1 млн страниц.
При fillfactor=50: сканирование ~2 млн страниц.
Ресурсные ограничения:
Слабые ресурсы (2 CPU, 2 GB RAM) не позволят autovacuum справляться с возросшим объёмом. Нехватка памяти вызовет активное использование диска (I/O), замедляя процесс.
4. Проблемы из-за нехватки ресурсов
Конкуренция за I/O:
Autovacuum будет постоянно читать/писать данные на диск, конкурируя с пользовательскими запросами (SELECT/UPDATE). Это увеличит задержку транзакций.
Нехватка памяти:
Буферный кэш (shared_buffers) ограничен ~512 MB (25% от 2 GB RAM). Таблица размером > 2x не поместится в кэш, что вызовет чтение с диска и замедлит все операции.
Риск блокировок:
Длительные циклы autovacuum могут конфликтовать с пользовательскими транзакциями, особенно при 48 одновременных сессиях.
5. HOT-обновления: частичное смягчение
Преимущество fillfactor=50:
Свободное место в страницах может повысить долю HOT-обновлений (когда новые версии строк помещаются в ту же страницу). Это уменьшит фрагментацию и нагрузку на индексы.
Ограниченная польза:
На фоне удвоенного объёма таблицы и слабых ресурсов этот эффект не компенсирует общее снижение производительности.
6. Риск накопления dead tuples
Autovacuum может не успевать:
При такой частоте UPDATE и нехватке ресурсов autovacuum будет отставать от нагрузки. Это вызовет:
Рост dead tuples.
Увеличение I/O (из-за чтения "мертвых" строк).
Замедление SELECT (из-за необходимости фильтрации мёртвых версий).
Блот (bloat) таблицы и индексов.
Рекомендации
Не снижать fillfactor до 50 на такой конфигурации. Оптимально: fillfactor=80–90 (если требуются HOT-обновления).
Увеличить порог autovacuum:
Например, autovacuum_vacuum_threshold = 10000 (вместо 1000), чтобы сократить частоту запусков.
Вывод: Уменьшение fillfactor до 50 на маломощном сервере с агрессивным autovacuum вызовет хроническую нехватку ресурсов, рост времени вакуумирования и общее снижение производительности. Без увеличения RAM/CPU это изменение не рекомендуется.
«Вот оно как» — подумает продвинутый DBA , следующий в русле новых тенденций и не будет менять параметр fillfactor.
Другой инженер, якудза старой школы
не верит бездушным алгоритмам и решает проверить всё лично.
И приходит к очень интересным, и прямо противоположным результатам.
Для данной СУБД и данного сценария нагрузки , уменьшение параметра хранения таблиц на 50% c 100 до 50 , повысило эффективность работы autovacuum:
Количество запусков autovacuum увеличилось на 261% c 193 до 697
Максимальное время работы autovacuum уменьшилось на 29% с 936 сек. до 663 сек.
Среднее время работы autovacuum уменьшилось на 73% с 46 сек. до 12 сек.
Предельная нагрузка на autovacuum увеличивалась на 50% с 8 до 12 соединений.
Молодой DBA, следующий в русле новых тенденций и доверяющий математическим алгоритмам статистической обработки текстов — потерял шанс сильно улучшить работу одного из ключевых механизмов СУБД PostgreSQL — autovacuum.
Старый, тертый жизнью и не доверяющий новым веяниям DBA — получил конкретный полезный результат и запланировал новые эксперименты по оптимизации и настройке СУБД.
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
Регулярная уборка это правильно .
Оценить влияние кардинального снижения параметра хранения таблиц fillfactor c базового значения 100 до 50, при агрессивной настройке autovacuum.
CPU = 2
RAM = 2GB
Версия СУБД:
Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (AstraLinuxSE 8.3.0-6) 8.3.0, 64-bit
Размер тестовой БД = 10GB
Тестовая таблица ~60 000 000 строк
autovacuum_analyze_scale_factor 0.1
autovacuum_analyze_threshold 50
autovacuum_vacuum_cost_delay 2 ms
autovacuum_vacuum_cost_limit -1
autovacuum_vacuum_insert_scale_factor 0.2
autovacuum_vacuum_insert_threshold 1000
autovacuum_vacuum_scale_factor 0.2
autovacuum_vacuum_threshold 50
vacuum_cost_limit 2000
autovacuum_vacuum_scale_factor 0
autovacuum_vacuum_threshold 1000
autovacuum_analyze_scale_factor 0
autovacuum_analyze_threshold 1000
autovacuum_vacuum_insert_scale_factor 0
autovacuum_vacuum_insert_threshold 1000
autovacuum_vacuum_cost_delay 1
autovacuum_vacuum_cost_limit 2000
Ось X - итерация теста. Ось Y - количество одновременных сессий pgbench
Ось X - точка завершения autovacuum. Ось Y - время выполнения autovacuum.
Нагрузка начала роста времени работы autovacuum = 8
Ось X - точка завершения autovacuum. Ось Y - время выполнения autovacuum.
Нагрузка начала роста времени работы autovacuum = 12
Для данной СУБД и данного сценария нагрузки , уменьшение параметра хранения таблиц на 50% c 100 до 50 , повысило эффективность работы autovacuum:
Количество запусков autovacuum увеличилось на 261% c 193 до 697
Максимальное время работы autovacuum уменьшилось на 29% с 936 сек. до 663 сек.
Среднее время работы autovacuum уменьшилось на 73% с 46 сек. до 12 сек.
Предельная нагрузка на autovacuum увеличивалась на 50% с 8 до 12 соединений.
Лет 5-7 назад была взял фетбайк с рук у знакомого, всё работала хорошо. Года 3-4 не обслуживался. Потом велосипед забрал себе и нашлась большая проблема. На велосипеде установлен какой-то гибрид тормозов. Сами тормоза гидравлические, а в действие приводится тросиком. Помогите найти название или видео как их заправлять и обслуживать. На последнем фото на велосипеде
Взято с основного технического канала Postgres DBA (возможны правки).
Тюнинг - дело тонкое. Нужно аккуратно.
Проанализировать влияние на производительность СУБД агрессивной настройки autovacuum для очень большой таблицы .
CPU = 200RAM = 1TBDB Size = 10TBКоличество строк тестовой таблицы ~70 00 000Сценарий нагрузки - смешанный ("Select only" + "Select + Update" + "Insert only")Минимальная нагрузка = 5 сессийМаксимальная нагрузка = 92 сессии
autovacuum_analyze_scale_factor = 0.005autovacuum_analyze_threshold = 50autovacuum_vacuum_cost_delay = 2msautovacuum_vacuum_cost_limit = 5600autovacuum_vacuum_insert_scale_factor = 0.01autovacuum_vacuum_scale_factor = 0.001autovacuum_vacuum_threshold = 50autovacuum_vacuum_insert_threshold = 1000autovacuum_work_mem = 1GB
ALTER TABLE pgbench_accounts SET (autovacuum_vacuum_scale_factor = 0);ALTER TABLE pgbench_accounts SET (autovacuum_vacuum_threshold = 10000);ALTER TABLE pgbench_accounts SET (autovacuum_analyze_scale_factor = 0);ALTER TABLE pgbench_accounts SET (autovacuum_analyze_threshold = 10000);ALTER TABLE pgbench_accounts SET (autovacuum_vacuum_insert_scale_factor = 0);ALTER TABLE pgbench_accounts SET (autovacuum_vacuum_threshold = 10000);ALTER TABLE pgbench_accounts SET (autovacuum_vacuum_cost_delay = 0);
Эксперимент-1:BASELINE
Среднее количество воркеров для эксперимента-1 = 0.5
Эксперимент-2:autovacuum
Среднее количество воркеров для эксперимента-1 = 1.5
Эксперимент-1:BASELINE
Среднее значение = 7.6%
Эксперимент-2:autovacuum
Среднее значение = 8.4%
Эксперимент-1:BASELINE
Среднее значение: 77-81%
Эксперимент-2:autovacuum
Среднее значение: 85-89%
Эксперимент-1:BASELINE
Среднее значение = 14.1%
Эксперимент-2:autovacuum
Среднее значение = 16%
Утилизация ресурсов увеличилась на 1-2%
Ось X - нагрузка на СУБД . Ось Y - Операционная скорость
Максимальное увеличение операционной скорости при использовании агрессивных настроек autovacuum составило 9%
Среднее увеличение операционной скорости при использовании агрессивных настроек autovacuum составило 4.5%
Минимальные и максимальные значение ожиданий СУБД
Ожидания IO - возросли
Ожидания IPC, Lock, LWLock - снизились
Среднее уменьшение количества ожиданий типа IO, в эксперименте-2 составило менее 1%
Среднее увеличение количества ожиданий типа IPC, в эксперименте-2 составило 52%
Среднее уменьшение количества ожиданий типа Lock, в эксперименте-2 составило менее -19%
Среднее увеличение количества ожиданий типа LWLock, в эксперименте-2 составило 19%
Для данной СУБД и данного сценария нагрузки, применение агрессивных настроек autovacuum дало среднее увеличение производительности СУБД на 4.5%
Увеличение утилизации ресурсов ОС - незначительно ~1-2%.
Корреляционный анализ событий ожиданий тестовых сценариев, будет выполнен позднее.
По агрессивному автовакууму , предварительно , чудес не бывает - за повышение производительности при средней нагрузке придётся платить снижением производительности при нагрузке близкой к максимальной.
Если autovacuum worker работает постоянно(а при высокой нагрузке иначе нет смысла), ресурсы CPU кончаются раньше .
Обслуживание СУБД требует ресурсов .
Но , конечно можно и не обслуживать , работает же. А +/- 5-10% изменения производительности СУБД современные приложения и не заметят.
После анализа результатов экспериментов , будут данные по ожиданиям . И в общем-то, тему можно закрывать , хотя с академической точки - интересно будет протестировать параметр autovacuum_cost_delay.
P.S. Так выглядит агрессивный автовакуум PostgreSQL - по мнению нейросети 🤪
Итак вы уже купили или только планируете приобретение этого шедевра китайского моторостроения. Какой бы не была причина сего опрометчивого поступка, долговечности и стабильной работы хочется практически всем и сегодня мы попытаемся этого добиться, но ничего не обещаю, ведь пути рисового двухткатника действительно непостижимы.
Этот материал универсален и подходит для большинства двухтактных вело двигателей и призван избавиться от львиной доли проблем и болячек, что встанут в будущем.
Начнём с самого начала, а именно с комплекта поставки, а точнее того, что должно быть в нём, но по велению экономии, отсутствует или ужасного качества и что требуется докупить самостоятельно.
1) Свеча зажигания. В комплекте с двигателем уже идёт свеча зажигания с маркировкой z8c и с ней даже возможно завести мотор, но добиться стабильной работы крайне сложно из-за чего в будущем ее все равно, практически все меняют. В замен можно взять NGK B6HS или NGK P7HS, они отлично подойдут, но потребуется ключ 20.8мм или клещи. Перед установкой бронепровода с верхушки свечи стоит открутить насадку.
2) Высокотемпературный герметик. Разбор любой части двигателя так или иначе будет связан с частичным повреждением прокладок, а разбирать предстоит много что. Так что герметик в этом деле - ваш лучший друг.
3) Колесо. Да, целое заднее колесо. Но не простое, а с утолщёнными 3мм спицами и стальным ободом. На какой бы велосипед вы не ставили свой веломотор, не стоит забывать, что фиксация ведомой звёзды осуществляется весьма варварским и примитивным методом, а именно простым притягиванием ее к спицам через прокладки и в 80 процентах случаев стандартное колесо просто не выдерживает таких нагрузок и спицы вырывает. Усиленные колеса продаются на маркетплейсах в разных диаметрах от 20 до 28 (28 колеса равны 29 по размеру, но не по ширине к сведению владельцев последних), стоит только упомянуть в поиске 3мм спицы. Обод также должен быть строго стальным. Лучше брать с втулкой Coster, ее длина оси делает ее наиболее универсальной. Да это всё односкоростные решения под ножной + ободной тормоз, по этому если вы надеялись сохранить свой перелюк и задний диск, то это вряд-ли получится без серьезного колхозинга с токарным станком или сваркой.
4) Выжимка цепи. Просто мотоциклетная выжимка цепи. В комплекте идёт довольно длинная цепь, которая без выжимания звеньев подойдёт к единицам велосипедов. К тому же она понадобится, когда цепь порвёт.
5) Бензошланг. В комплекте идёт нечто, созданное никак иначе, чем из дуба и травящее уже спустя пару часов после контакта с бензином, а при изгибе рассыпается, словно хрусталь.
6) Торцевой ключ для болтов головки цилиндра (обычным гаечным тут не отделаешься), если у вас есть трещотка с торцевой головкой на 14 (в случае с f80), пропускай пункт.
7) Лист бензостойкого паронита 1-2мм. Как я уже упоминал выше, при разборе двигателя часто повреждаются прокладки и некоторые из них (например для патрубка или карбюратора) по любому нужно восстанавливать.
8) Шуруповёрт или дрель и небольшие сверла по металлу. Необходимо для фиксации ручки газа на руле, путем просверливания отверстия шириной, что-то около 4мм.
9) Газовая горелка по желанию. Иногда шатуны, после установки, задевают двигатель или глушитель и что-то из этого приходиться гнуть и лучше это делать с горелкой, также полностью разобрать мотор, без нее не выйдет (хотя это и не нужно).
Упущу очевидные вещи по типу масла, канистры или смазки.
Теперь, когда всё необходимое при себе, перейдем к следующему шагу - непосредственно обслуживанию движка и того, что идёт в комплекте.
1) Обратите внимание на карбюратор, а если точнее на воздушный фильтр, что к нему прикручен. Этот "фильтр" даже не пытается имитировать свою работоспособность, т.к. в качестве фильтрующего элемента там установлена губочка 5мм толщиной с плотностью, как у крупнопористых аквариумных фильтров.
Естественно это убьет ЦПГ быстрее самого паршивого в мире нулевика, так как отфильтрует, разве что воробья. Исправить положение не сложно. Достаточно просто под эту комплектную губку положить нормальный фильтрующий элемент, вырезав его по форме. В идеале найти губку средней пористости с отверстиями чуть больше, чем у той, которой вы моете посуду или купить ту же аквариумную губку, но в 3-4 раза большой толщины, чтобы сжав, увеличить плотность. Можно использовать и обычную моющую губку, оторвав жёсткую зелёную часть, но не стоит забывать, что двухтактные двигатели в виду своей специфики работы плюются бензино масляной семью, в обе стороны, как в выпуск, так и в пуск, из-за чего после масляного душа мелкопористая губка может душить мотор, по этой же причине бумажный фильтрующий элемент, расположенный непосредственно возле карба перестанет пропускать воздух уже спустя пару десятков тактов. (Если все же решите использовать кухонную губку, вам пригодится и комплектная. Ее нужно положить поверх кухонной, так чтобы она была ближе к карбюратору и основная часть масла оседала именно на ней).
2) Следующее больное место это ЦПГ, а именно камера сгорания. В виду отсутствия денег на ОТК, там не редко можно обнаружить разного рода металлические осколки, стружку и прочие отходы моторопроизводства.
Но не стоит хаять китайцев, ведь подобное, иногда встречается даже на крупных серьезных предприятиях. Всё что нужно сделать это открутить головку (если она у вас не одно целое с остальным цилиндром) или снять цилиндр полностью. Проверить камеру сгорания, смазать цилиндр и поршень маслом, смазать прокладку герметиком и установить всё на прежнее место (предвидя вопрос, люфт шатуна в горизонтальной плоскости это норма для этих моторов).
Если боитесь повредить прокладку, то можно опустить поршень с помощью звёздочки на уровень впускного или выпускного окна и попытаться продуть всё изнутри сжатым воздухом, а масло капнуть через свечное отверстие, но это может лишь загнать стружку к краю поршня.
3) Следующее, что нужно сделать это смазать вал выжима сцепления (тот рычажок, что над ведущей звёздочкой). Для этого нужно открутить часть левой крышки, вытащить вал выжима и окунуть его скрытую часть в водостойкую консистентную смазку. Без этого вал быстро выработается (пикча 4) и сцепление перестанет работать, а валы в продаже все из сыромятины, что стачиваются, даже со смазкой.
4) Потом нужно смазать шестерни коленвала и сцепления.
Для этого необходимо открутить правую крышку на двигателе. С завода они практически сухие и быстро стачиваются друг об друга, превращаясь в слегка ребристые круги. Смазывать также густой консистентной смазкой, набивая ее между зубьями. Главное не переусердствовать и не использовать через чур жидкие смазки, так как там же находится сцепление, которому смазка противопоказана. Не забывать закручивать всё это с использованием герметика.
5) Далее не лишним будет смазать тросы газа и сцепления, просто пшикнув туда жидкой смазкой из баллончика, т.к. иначе они будут периодически залипать. Вместе с ними можно смазать ручку газа, изнутри, но уже консистентной смазкой, т.к. там же находится глушилка двигателя. Цепь китайцы также не удосужились смазать, так что и про нее не забываем.
6) Естественно после подключения всей не хитрой электроники ее необходимо дополнительно заизолировать, обмотав вулканизирующейся изолентой.
7) В комплекте с веломотором идёт дополнительное крепление выхлопа к раме, им пренебрегать не стоит, т.к. шпильки на которых в основном держится выхлоп, могут обломаться.
Немного о эксплуатации -
Масло и его концентрация. Споров на эту тему много, так что ниже сказанное чисто мое имхо. Лукойл 2т - редкостная проблемная бурда, брать не стоит, как и супер дешёвую полусинтетику.
Следовать тем соотношениям, что указаны на упаковке нельзя. При 1:50 мотор стуканет не пройдя и 100км.
Оптимальная концентрация при обкатке двигателя 50мл на 1л в случае с минералкой и 45мл на 1л в случае с синтетикой (и да, пара капель из выхлопа после поездки это норма для подобной техники).
После обкатки норма это 35мл на 1л. При дешёвой минералке 40мл.
Как и в случае с триммерами и косами, нужно использовать только 92 бензин, более того степень сжатия этого двигателя рассчитана вообще на АИ80 (аналог советского А-76).
При хранении или зимовке бак должен быть полон до краёв, т.к. он имеет свойство очень быстро и хорошо ржаветь при выпадении конденсата.
Двигатель даёт большие вибрации на весь велосипед, по этому стоит сразу посадить все жизненно необходимые соединения на стопорные шайбы и затянуть с приличным усилием. К слову, передние крылья на дешёвых стелс навигаторах довольно опасны, они имеют свойство перетирать свои крепления и блокировать колесо.
На этом в общем то всё. Выполнив эти рекомендации вы избавитесь от многих проблем в будущем и настоящем, при эксплуатации китайских веломоторов.
Немного тонкой настройки и СУБД будет работать как часы.
Какой параметр для настройки автовакуума для СУБД PostgreSQL эффективнее использовать для очень больших таблиц : autovacuum_vacuum_scale_factor или autovacuum_vacuum_threshold ?
Для очень больших таблиц в PostgreSQL эффективнее использовать параметр autovacuum_vacuum_threshold, а не autovacuum_vacuum_scale_factor. Вот обоснование:
Масштабируемость:
Формула запуска автовакуума:
autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * table_size.
По умолчанию: threshold = 50, scale_factor = 0.2 (20%).
Для таблицы на 1 млрд строк порог срабатывания:
50 + 0.2 * 1 000 000 000 = 200 000 050 мертвых кортежей.
Это приводит к редким запускам и накоплению огромного числа мертвых кортежей.
Риски:
Замедление запросов: Длинные таблицы (из-за мертвых кортежей) снижают производительность.
Блокировки: Очистка большого объема данных блокирует операции.
Срыв транзакций: Если autovacuum не успевает очищать данные до заполнения autovacuum_freeze_max_age.
Фиксированный порог:
Позволяет задать абсолютное число мертвых кортежей для запуска (независимо от размера таблицы).
Пример: ALTER TABLE big_table SET (autovacuum_vacuum_threshold = 1000000);
Автовакуум запустится при достижении 1 млн мертвых кортежей, даже если таблица содержит 1 млрд строк.
Гранулярность:
Настройка применяется индивидуально к большим таблицам без влияния на маленькие.
Оптимальные значения: от 100 000 до 10 000 000 (зависит от нагрузки и размера).
1. Уменьшить scale_factor:
ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor = 0.01); -- 1%
Для таблицы на 1 млрд строк порог: 50 + 0.01 * 1e9 = 10 000 050.
2. Увеличить threshold:
ALTER TABLE big_table SET (autovacuum_vacuum_threshold = 1000000);
Порог: 1 000 000 (фиксированный, без умножения на размер).
3.Комбинировать параметры:
ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor = 0.005, -- 0.5%autovacuum_vacuum_threshold = 500000);
Формула: 500 000 + 0.005 * N.
autovacuum_vacuum_cost_limit (увеличить для ускорения):
ALTER TABLE big_table SET (autovacuum_vacuum_cost_limit = 2000); -- вместо 200 по умолчанию
autovacuum_naptime (уменьшить интервал проверок).
Для очень больших таблиц:
Основной параметр: autovacuum_vacuum_threshold (фиксированный порог).
Вспомогательный: autovacuum_vacuum_scale_factor (уменьшать до 0.1–0.5%).
Настраивать индивидуально для таблицы через ALTER TABLE.
Мониторить эффективность через представление pg_stat_user_tables (столбцы n_dead_tup и last_autovacuum).
