Исходя из содержания статьи, её практическая ценность очень высока, особенно для команд, которые эксплуатируют PostgreSQL в условиях нестабильной или смешанной нагрузки.
Вот ключевые аспекты, которые можно применить на практике прямо сейчас:
Чёткий метод диагностики «настроение БД»
Автор предлагает простой, но мощный приём: смотреть не на каждый график по отдельности, а на комбинацию state + wait_event + wait_event_type из pg_stat_activity.
· Что даёт на практике: Быстро отличать нормальную работу CPU (active/NULL) от проблем ввода-вывода (active/DataFileRead/IO), блокировок (active/relation/Lock) или «зависших» транзакций приложения (idle in transaction/ClientRead/Client). · Как применить: Вы можете прямо сейчас написать скрипт мониторинга (Zabbix, Prometheus), который строит график с этими комбинациями — это заменит десятки других графиков для быстрой оценки ситуации.
Объективная формула профиля нагрузки (OLTP ↔ OLAP)
Главное новшество — метрика Profile ratio на основе сравнения DB Time (ASH) и DB Time (committed).
· В чём суть: Она показывает, каких запросов больше в интервале — коротких транзакционных (OLTP) или длинных аналитических (OLAP). · Практические действия: Если для системы, задуманной как OLTP, коэффициент вдруг стал выше 500-700 (особенно при интервале сбора 1-5 минут), вы получаете ранний триггер. Это повод проверить: · Не появились ли неоптимальные отчёты на продуктивной БД. · Хватает ли shared_buffers (иначе много DataFileRead). · Не пора ли менять архитектуру (индексы, секционирование).
Отдельный алгоритм для Archive Database (критично для больших инфраструктур)
Автор детально разбирает риски, когда архивную БД («только чтение, редкие запросы») начинают использовать как обычную продуктивную.
· Главная опасность: У архивных БД обычно минимум индексов, слабые ресурсы (CPU/RAM) и очень редкие бекапы (раз в квартал/год). Внезапная OLTP-нагрузка разрушит производительность, а случайное удаление данных будет невосстановимо. · Практический вывод: Внедрите мониторинг этой самой метрики Profile ratio специально для архивных систем. Как только она отклоняется от «около 0» (долгие запросы) или «около 1000» (пакетная загрузка) — срочно проверять, не начали ли её использовать как «скрытый продуктив».
Готовые рекомендации по интервалу сбора
Автор приводит эмпирические данные, что оптимальный интервал сбора метрик ∆t для Profile ratio — от 2 до 7 минут (удобнее 5 минут). Это избавит вас от ошибок (слишком малый интервал сольёт все профили в OLAP, слишком большой — сделает их неразличимыми).
Главное ограничение для практики
Метод требует накопления истории снимков pg_stat_activity и pg_stat_statements в вашей системе мониторинга. Если у вас их нет, то «с нуля» вы получите только текущий срез. Но настроить сбор этих данных — задача на несколько часов, а выгода от предложенного подхода будет постоянной.
Краткий вердикт: Это не просто теоретическая статья, а готовый инструментарий для инженеров. Вы можете взять предложенные SQL-запросы, формулы и пороговые значения и внедрить их в свою систему мониторинга PostgreSQL уже на следующей неделе.
«Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.» теоретически в пределе это возможно только в одном случае — единичный запрос в идеально сконфигурированной СУБД в условиях отсутствия других запросов ;-)«И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда мы упирается.» — и вот тут то и начинается самое интересное — как вы определяете root cause снижения производительности СУБД. И самый главный вопрос всех вопросов, я очень люблю задавать его всем докладчикам — «а производительность СУБД это что? Как измерить и сравнить? » Вы можете ответить на этот главный вопрос ?
Ответ:
Производительность БД - это скорее соответствие нашим ожиданиям (проектным, архитектурным) - тому что выделенные нами ресурсы с задачей вообще справляются. Для тяжелых профилей вроде OLAP длительное выполнение запросов это нормально. Но оно должно находиться в разумных проектных пределах, соответствующим нашим ожиданиям. (В некоторых случаях время выполнения запросов может превышать время существования Вселенной :) Если мы говорим о профиле OLTP, где важны даже микросекунды, то общий поток запросов должен также успевать обрабатываться выделенными ресурсами за приемлемое время. Основной источник изменения производительности БД - ВРЕМЯ. В нашем случае это метрики DB Time - все что находится в каком то активном статусе или ожиданиях или блокировках как раз и является тем что нас интересует. DB Time смещается в сторону OLAP - значит мы наблюдаем падение производительности. И наоборот.
С вашего позволения, здесь буду также транслировать вопросы от читателей.
Вопрос.
Замечание по статье «Если этого не происходит, то БД столкнулась с какими-то трудностями на пути выполнения запроса. Что это может быть?» — не рассмотрена ситуация — «процесс выполняющий запрос находится в состоянии ожидания»
Ответ:
По поводу ожиданий. С точки зрения DB Time ожидания (причем любые) его как раз и увеличивают. Мы смотрим все состояния, которые no idle. Это ключевой параметр производительности. Это могут быть ожидания на IO, ЦПУ, ожидания репликации если реплика синхронна (SyncRepl) в целом на чем угодно. Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.) И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда, в какие ресурсы или процессы мы упираемся.
Добрый день. Большое спасибо за внимание к статье. По вашим вопросам:
т.к. профили нагрузок крайне редко бывают точно 100% OLAP или OLTP, то "близко" означает что находится в интервале от 700 до 1000. Например на фоне точного OLAP профиля могут присутствовать короткие запросы мониторинга, а на фоне точного OLTP могут быть достаточно длинные операции обслуживания. Тот же автовакуум. Именно поэтому речь скорее об интервалах.
Интервал сбора метрик - это интервал между SN02 и SN01 на рис. 6. То есть то, как часто мы снимаем метрики DBTime для определения профиля нагрузки.
Критерий оптимальности в том, чтобы обе границы для HTAP и OLAP находились равноудаленно от границ 0 и 1000 в критериях определения профиля. Если обе находятся близко к 0 или к 1000 - при некоторых временах они становятся слабоотличимыми. И это приводит к падению точности определения профиля. Например на графиках хорошо видно, что интервал сбора несколько секунд - это слишком мало, а 15-20 уже слишком много.
Большое спасибо за материал. Добавлю с чем мы столкнулись ещё.
Мало того, что в text и bytea нельзя положить больше 1Гб, но если вы положите строку меньше 1Гб но больше 0.5 Гб, например 600 Мб, то извлечь ее через SELECT нельзя. Только через copy. Как объяснили в поддержке, это особенность libpq. Было ли у вас такое?
Оценка со стороны ИИ. О чем статья.
Исходя из содержания статьи, её практическая ценность очень высока, особенно для команд, которые эксплуатируют PostgreSQL в условиях нестабильной или смешанной нагрузки.
Вот ключевые аспекты, которые можно применить на практике прямо сейчас:
Чёткий метод диагностики «настроение БД»
Автор предлагает простой, но мощный приём: смотреть не на каждый график по отдельности, а на комбинацию state + wait_event + wait_event_type из pg_stat_activity.
· Что даёт на практике: Быстро отличать нормальную работу CPU (active/NULL) от проблем ввода-вывода (active/DataFileRead/IO), блокировок (active/relation/Lock) или «зависших» транзакций приложения (idle in transaction/ClientRead/Client). · Как применить: Вы можете прямо сейчас написать скрипт мониторинга (Zabbix, Prometheus), который строит график с этими комбинациями — это заменит десятки других графиков для быстрой оценки ситуации.
Объективная формула профиля нагрузки (OLTP ↔ OLAP)
Главное новшество — метрика Profile ratio на основе сравнения DB Time (ASH) и DB Time (committed).
· В чём суть: Она показывает, каких запросов больше в интервале — коротких транзакционных (OLTP) или длинных аналитических (OLAP). · Практические действия: Если для системы, задуманной как OLTP, коэффициент вдруг стал выше 500-700 (особенно при интервале сбора 1-5 минут), вы получаете ранний триггер. Это повод проверить: · Не появились ли неоптимальные отчёты на продуктивной БД. · Хватает ли shared_buffers (иначе много DataFileRead). · Не пора ли менять архитектуру (индексы, секционирование).
Отдельный алгоритм для Archive Database (критично для больших инфраструктур)
Автор детально разбирает риски, когда архивную БД («только чтение, редкие запросы») начинают использовать как обычную продуктивную.
· Главная опасность: У архивных БД обычно минимум индексов, слабые ресурсы (CPU/RAM) и очень редкие бекапы (раз в квартал/год). Внезапная OLTP-нагрузка разрушит производительность, а случайное удаление данных будет невосстановимо. · Практический вывод: Внедрите мониторинг этой самой метрики Profile ratio специально для архивных систем. Как только она отклоняется от «около 0» (долгие запросы) или «около 1000» (пакетная загрузка) — срочно проверять, не начали ли её использовать как «скрытый продуктив».
Готовые рекомендации по интервалу сбора
Автор приводит эмпирические данные, что оптимальный интервал сбора метрик ∆t для Profile ratio — от 2 до 7 минут (удобнее 5 минут). Это избавит вас от ошибок (слишком малый интервал сольёт все профили в OLAP, слишком большой — сделает их неразличимыми).
Главное ограничение для практики
Метод требует накопления истории снимков pg_stat_activity и pg_stat_statements в вашей системе мониторинга. Если у вас их нет, то «с нуля» вы получите только текущий срез. Но настроить сбор этих данных — задача на несколько часов, а выгода от предложенного подхода будет постоянной.
Краткий вердикт: Это не просто теоретическая статья, а готовый инструментарий для инженеров. Вы можете взять предложенные SQL-запросы, формулы и пороговые значения и внедрить их в свою систему мониторинга PostgreSQL уже на следующей неделе.
Вопрос:
«Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.» теоретически в пределе это возможно только в одном случае — единичный запрос в идеально сконфигурированной СУБД в условиях отсутствия других запросов ;-)«И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда мы упирается.» — и вот тут то и начинается самое интересное — как вы определяете root cause снижения производительности СУБД. И самый главный вопрос всех вопросов, я очень люблю задавать его всем докладчикам — «а производительность СУБД это что? Как измерить и сравнить? » Вы можете ответить на этот главный вопрос ?
Ответ:
Производительность БД - это скорее соответствие нашим ожиданиям (проектным, архитектурным) - тому что выделенные нами ресурсы с задачей вообще справляются. Для тяжелых профилей вроде OLAP длительное выполнение запросов это нормально. Но оно должно находиться в разумных проектных пределах, соответствующим нашим ожиданиям. (В некоторых случаях время выполнения запросов может превышать время существования Вселенной :) Если мы говорим о профиле OLTP, где важны даже микросекунды, то общий поток запросов должен также успевать обрабатываться выделенными ресурсами за приемлемое время. Основной источник изменения производительности БД - ВРЕМЯ. В нашем случае это метрики DB Time - все что находится в каком то активном статусе или ожиданиях или блокировках как раз и является тем что нас интересует. DB Time смещается в сторону OLAP - значит мы наблюдаем падение производительности. И наоборот.
С вашего позволения, здесь буду также транслировать вопросы от читателей.
Вопрос.
Замечание по статье «Если этого не происходит, то БД столкнулась с какими-то трудностями на пути выполнения запроса. Что это может быть?» — не рассмотрена ситуация — «процесс выполняющий запрос находится в состоянии ожидания»
Ответ:
По поводу ожиданий. С точки зрения DB Time ожидания (причем любые) его как раз и увеличивают. Мы смотрим все состояния, которые no idle. Это ключевой параметр производительности. Это могут быть ожидания на IO, ЦПУ, ожидания репликации если реплика синхронна (SyncRepl) в целом на чем угодно. Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.) И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда, в какие ресурсы или процессы мы упираемся.
Добрый день. Большое спасибо за внимание к статье. По вашим вопросам:
т.к. профили нагрузок крайне редко бывают точно 100% OLAP или OLTP, то "близко" означает что находится в интервале от 700 до 1000. Например на фоне точного OLAP профиля могут присутствовать короткие запросы мониторинга, а на фоне точного OLTP могут быть достаточно длинные операции обслуживания. Тот же автовакуум. Именно поэтому речь скорее об интервалах.
Интервал сбора метрик - это интервал между SN02 и SN01 на рис. 6. То есть то, как часто мы снимаем метрики DBTime для определения профиля нагрузки.
Критерий оптимальности в том, чтобы обе границы для HTAP и OLAP находились равноудаленно от границ 0 и 1000 в критериях определения профиля. Если обе находятся близко к 0 или к 1000 - при некоторых временах они становятся слабоотличимыми. И это приводит к падению точности определения профиля. Например на графиках хорошо видно, что интервал сбора несколько секунд - это слишком мало, а 15-20 уже слишком много.
Невероятно. Я даже не знал такие игры. Спасибо за статью.
Большое спасибо за материал. Добавлю с чем мы столкнулись ещё.
Мало того, что в text и bytea нельзя положить больше 1Гб, но если вы положите строку меньше 1Гб но больше 0.5 Гб, например 600 Мб, то извлечь ее через SELECT нельзя. Только через copy. Как объяснили в поддержке, это особенность libpq. Было ли у вас такое?