Comments 6
Идея провести тесты хорошая. Но выводы капитанские. Особенно когда в статье не приведены ни параметры базы, ни параметры сервера (может у вас там Windows-виртуалка в облаке с 1Гб памяти) , ни схема таблиц и данных, ни тесты....
Поставил плюс статье, но могло быть и лучше.
Если вам , действительно интересны детали, ок , принято добавлю чуть больше деталей, попозже. Эксперименты будут продолжены, очень интересно, как там с ожиданиями и корреляциями обстоит дело .Не знаю как вам , но мне, показалось очень интересным и не так уж и очевидным - несущественная разница между уровнем фрагментации 11% и 100%.Ожидал , что то типа логарифмической зависимости .
в статье не приведены ни параметры базы, ни параметры сервера (может у вас там Windows-виртуалка в облаке с 1Гб памяти) , ни схема таблиц и данных, ни тесты
Добавлено
Это все конечно здорово, но совершенно оторвано от реальности.
К сожалению Autocacuum постгреса, точнее алгоритм его запуска реализован слишком топорно.
Пример из жизни: кластер с одной синхронной репликой (которая используется для r/o аналитических запросов ). В какой-то момент складывается такая ситуация: в одной из крупных таблиц происходит много изменений, тригерится autocacuum и… он ничего не может собрать потому что, ну вот так совпало, что на реплике запустился какой-то тяжелый долгий запрос из-за чего на мастере xid остались заморожены до окончания запроса. Но условие срабатывания автовакума все еще валидно и вот он запускается снова и снова, сканирует это огромную таблицу, высаживая io и сжигая cpu.
Да и в принципе этот механизм так устроен, что он будет запускаться именно в часы наибольшей нагрузки (по очевидным причинам) - иногда добивая загрузку свободных ядер до 100%
Я знаю про все его настройки - баланс там найти сложно. Мечтаю, что когда-нибудь он научится адаптироваться к нагрузке и делать больше пауз, если бд и так перегружена
А пробовали настраивать вакуум не для кластера в целом , для таблиц отдельно ?
На большой бд только так и можно жить.
Дефолтные настройки для мелких таблиц
Все крупные таблицы имеют свои трешолды в зависимости от интенсивности их изменений
А на самых больших автовакуум вообще приходится выключать и запускать вакуум по старинке из планировщика (pg_cron) в часы наименьшей нагрузки
Влияние vacuum/analyze/bloat на производительность СУБД