вам самому норм будет, если вы знаете что у вас в таблице лежит например больше 50% "мертвых" таплов
Если таблица состоит из 2-х живых строк размером по десятку КБ и используется раз в полгода , лично мне будет абсолютно все равно.
Например
Какие у вас самого критерии "правильности" настройки autovacuum?
Здесь повторюсь , критерий только один - производительность СУБД.
Пока тема в исследовании, первые наработки и результаты опубликованы.
Закончу со статистическим анализом нагрузочного тестирования , займусь применением статистического анализа влияния настроек автовакуума на производительность СУБД .
А какие у вас критерии правильной настройки autovacuum
У меня один критерий - минимальная деградация производительности.
И тут выясняется интересный момент - по тестам, даже 11% мёртвых строк очень сильно снижают производительность. Опять таки , по результатам первых тестов -гипотеза - чем больше и чем чаще используется таблица - тем ниже допустимый процент мертвых строк без существенного влияния на производительность.
Если вам , действительно интересны детали, ок , принято добавлю чуть больше деталей, попозже. Эксперименты будут продолжены, очень интересно, как там с ожиданиями и корреляциями обстоит дело .Не знаю как вам , но мне, показалось очень интересным и не так уж и очевидным - несущественная разница между уровнем фрагментации 11% и 100%.Ожидал , что то типа логарифмической зависимости .
Теме "искусственный интеллект", почти столько же лет , сколько компьютерам .
На моей памяти с 80-х годов , лично уже читал статьи доступные.
Был даже(а может быть и сейчас есть) язык программирования LISP. Который позиционировался как язык разработки искусственного интеллекта.
И также было ожидание - ну вот еще чуть , чуть , еще немного и фундаментальная философская проблема человеческой цивилизации будет решена и человек окончательно сможеть считать себя Богом .
Но , пока , как видно - не сложилось.... Ну, по крайней мере умной колонке "Алисе", до прохождения теста Тьюринга , как до Китая .
может запросто показывать крайне печальное состояние внутри самой СУБД
Результаты экспериментов очень интересны и позволяют двигаться дальше . С более эффективными и математически обоснованными результатами экспериментов. Спасибо.
Именно , вот за такие комментарии я и публикую , и буду продолжать публиковать, статьи на Хабре. Мне нужна обратная связь и взгляд со стороны Это классика - "разработчик не тестирует".
Да , раньше с обратной связью и конструктивной дискуссией на Хабре было сильно по другому . Но и сейчас , иногда в потоке флеймофлуда попадаются проблески. А тема , что там в голове у минусаторов это к психологам . Не моя тема.
Так, что , как будет новая статья - не пропустите . Жду обратной связи.
Мониторить утилизацию CPU отдельно - не имеет смысла. Мониторить надо производительность СУБД.
Рост утилизации CPU - не инцидент. Снижение производительности СУБД и рост утилизации CPU - инцидент.
Высокая утилизация CPU и рост производительности СУБД - показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время - зря потраченные средства .
Вот так выглядит загрузка CPU на сервере базы до и после этой операции для примера выше:
Делать выводы - затруднительно. Потому, что нет информации - какая была производительность СУБД до и после. Рискну предположить, что после - производительность выросла. Просто потому, что запрос стал работать быстрее а значить отношение Объем / время - увеличилось.
Но спасибо за наводку для эксперимента - сравнить производительность и утилизацию CPU для очень больших таблиц до и после выполнения ANALYZE. Надо проверить.
Уже обсуждали. Замечаний по тому, как бывает в реальной жизни с реальными разрабами - масса. Ну например, для начала:
Много idle in transaction — скорее всего, у нас перегружена бизнес-логика или pgbouncer. То есть с точки зрения БД вы транзакцию открыли и ушли перекурить.
Объяснять им это бесполезно. "У нас так спроектировано". Для завенршения транзакции СУБД ждет подтверждения от внешней системы.
Нет смысла мониторить
Растут wait — приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.
Сама по себе цифра - количество блокировок - ни о чем.
Нет смысла мониторить.
Пики active (особенно max-значение) демонстрируют, насколько ваше приложение любит ходить в базу «синхронно». То есть вы кинули какой-то сигнал по всем пользователям (например, «опубликована новость») и несколько сотен клиентских приложений одновременно, без всяких задержек, рванули в базу читать…
Вообще то сессия в состоянии active либо выполняет запрос либо ожидает освобождения ресурса.
Нет смысла мониторить.
И т.д. и т.п.
В общем смысл в следующем - можно сделать дашбоард мониторинге с десятками и сотнями метрик, графиков и оповещений.
Реальному DBA , в реальной работе это не поможет, а только запутает и не поможет установить реальную причину проблемы.
Я лично не против, может кому то и нравится целый день сидеть и смотреть как меняются графики.
Описанная ситуация , ранее была совершенно стандартна и отнимала массу времени и иногда нервов
у нас БД ложится от высокой нагрузки
Сейчас , ситуация несколько иная, если метрика производительности СУБД не уменьшается разговор закончен - "С СУБД аномалий нет, помочь не можем, разбирайтесь с приложением".
там на сервере БД загрузка проца около 100%, их технари на стрессе убивают рандомные подключения, хотят ребутать Postgres.
...
Абсолютно аналогично знакомая ситуация. Совпадения с удивительной точностью .
Юзеры и манагеры - они объективно одинаковы , получается :-)
В самом начале ошибка . Из ошибочного утверждения , любой вывод должен.
И вообще , странно , зачем топтитб время и выдумывать велосипед, когда тема Incident management давным давно отработана и бесчисленное количество раз реализована ?
Если таблица состоит из 2-х живых строк размером по десятку КБ и используется раз в полгода , лично мне будет абсолютно все равно.
Например
Здесь повторюсь , критерий только один - производительность СУБД.
Пока тема в исследовании, первые наработки и результаты опубликованы.
Закончу со статистическим анализом нагрузочного тестирования , займусь применением статистического анализа влияния настроек автовакуума на производительность СУБД .
У меня один критерий - минимальная деградация производительности.
И тут выясняется интересный момент - по тестам, даже 11% мёртвых строк очень сильно снижают производительность. Опять таки , по результатам первых тестов -гипотеза - чем больше и чем чаще используется таблица - тем ниже допустимый процент мертвых строк без существенного влияния на производительность.
Детали в статье,
Влияние vacuum/analyze/bloat на производительность СУБД https://habr.com/p/845454/
если интересно . Будет время , продолжу исследования для более полной статистической картины . Хотя бы для чисто академического интереса.
Почему не 10%, 30%, 5% ?
На чем основана эта цифра ?
А можно уточнить - что является метрикой правильности настройки ?
Как определить, в цифровом выражении , что для данной СУБД автовакуум настроен правильно ?
А пробовали настраивать вакуум не для кластера в целом , для таблиц отдельно ?
Если вам , действительно интересны детали, ок , принято добавлю чуть больше деталей, попозже. Эксперименты будут продолжены, очень интересно, как там с ожиданиями и корреляциями обстоит дело .Не знаю как вам , но мне, показалось очень интересным и не так уж и очевидным - несущественная разница между уровнем фрагментации 11% и 100%.Ожидал , что то типа логарифмической зависимости .
Спасибо за уточнение . Намек понял . Надо капнуть поглубже.
Тема оказалась хитрее , чем кажется .
Виртуальный + за комментарий
Теме "искусственный интеллект", почти столько же лет , сколько компьютерам .
На моей памяти с 80-х годов , лично уже читал статьи доступные.
Был даже(а может быть и сейчас есть) язык программирования LISP. Который позиционировался как язык разработки искусственного интеллекта.
И также было ожидание - ну вот еще чуть , чуть , еще немного и фундаментальная философская проблема человеческой цивилизации будет решена и человек окончательно сможеть считать себя Богом .
Но , пока , как видно - не сложилось.... Ну, по крайней мере умной колонке "Алисе", до прохождения теста Тьюринга , как до Китая .
Пользуясь случаем , спасибо за наводку
Результаты экспериментов очень интересны и позволяют двигаться дальше . С более эффективными и математически обоснованными результатами экспериментов. Спасибо.
Именно , вот за такие комментарии я и публикую , и буду продолжать публиковать, статьи на Хабре. Мне нужна обратная связь и взгляд со стороны Это классика - "разработчик не тестирует".
Да , раньше с обратной связью и конструктивной дискуссией на Хабре было сильно по другому . Но и сейчас , иногда в потоке флеймофлуда попадаются проблески. А тема , что там в голове у минусаторов это к психологам . Не моя тема.
Так, что , как будет новая статья - не пропустите . Жду обратной связи.
Как выяснилось в ходе экспериментов - Оценивать производительность запроса по стоимости - некорректно.
Выводы из оценки могут быть неверные .
Там , много интересного получается . Если будет время , будет отдельная статья по данной теме.
Ок. Принято. Вопросов больше нет.
Спасибо за конструктивный , вежливый диалог.
А можно уточнить - между какими переменными и какое значение коэффициента корреляции в данном примере ?
А можно с этого места поподробнее - как вы устанавливаете наличие и значение корреляции по дискретным значениям метрик по графикам ?
А можно уточнить, что значить "корреляции прописанные заранее" ?
Какого запроса ? Их сотни и тысячи .
Или вы про метрику время отклика СУБД ?
Есть реальный случай из жизни :
Информационная система деградировала. Ничего не работает, всё висит.
Время отклика СУБД существенно уменьшилось.
Изменил/дополнил последний абзац:
Делать выводы - затруднительно. Потому, что нет информации - какая была производительность СУБД до и после. Рискну предположить, что после - производительность выросла. Просто потому, что запрос стал работать быстрее а значить отношение Объем / время - увеличилось.
Но спасибо за наводку для эксперимента - сравнить производительность и утилизацию CPU для очень больших таблиц до и после выполнения ANALYZE. Надо проверить.
Уже обсуждали. Замечаний по тому, как бывает в реальной жизни с реальными разрабами - масса. Ну например, для начала:
Объяснять им это бесполезно. "У нас так спроектировано". Для завенршения транзакции СУБД ждет подтверждения от внешней системы.
Нет смысла мониторить
Сама по себе цифра - количество блокировок - ни о чем.
Нет смысла мониторить.
Вообще то сессия в состоянии active либо выполняет запрос либо ожидает освобождения ресурса.
Нет смысла мониторить.
И т.д. и т.п.
В общем смысл в следующем - можно сделать дашбоард мониторинге с десятками и сотнями метрик, графиков и оповещений.
Реальному DBA , в реальной работе это не поможет, а только запутает и не поможет установить реальную причину проблемы.
Я лично не против, может кому то и нравится целый день сидеть и смотреть как меняются графики.
Описанная ситуация , ранее была совершенно стандартна и отнимала массу времени и иногда нервов
Сейчас , ситуация несколько иная, если метрика производительности СУБД не уменьшается разговор закончен - "С СУБД аномалий нет, помочь не можем, разбирайтесь с приложением".
Абсолютно аналогично знакомая ситуация. Совпадения с удивительной точностью .
Юзеры и манагеры - они объективно одинаковы , получается :-)
В самом начале ошибка . Из ошибочного утверждения , любой вывод должен.
И вообще , странно , зачем топтитб время и выдумывать велосипед, когда тема Incident management давным давно отработана и бесчисленное количество раз реализована ?
Дискуссии по поводу механизма кармы на Хабре периодически возникают регулярно. Итог всех дискуссий всегда один - меняется ничего.
Именно так оно и есть, кстати.
Как иначе объяснить например возможность поставить минус под статьей с по причине личной неприязни.
Или "Ничего не понял после прочтения " ;-) Ну не понял, спроси. За спрос денег не берут.
Вот ни разу не удивлюсь, если скоро еще значочки эмодзи сделают ;-)
Если руль сильно дернуть , то машинка разворачивалась и дальше задним ходом можно было пытаться ехать.
Типа как бы полицейский разворот ;-)