«Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.» теоретически в пределе это возможно только в одном случае — единичный запрос в идеально сконфигурированной СУБД в условиях отсутствия других запросов ;-)«И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда мы упирается.» — и вот тут то и начинается самое интересное — как вы определяете 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. Было ли у вас такое?
Вопрос:
«Идеальный запрос в идеальной БД вообще должен выполняться мгновенно.» теоретически в пределе это возможно только в одном случае — единичный запрос в идеально сконфигурированной СУБД в условиях отсутствия других запросов ;-)«И если это не так, и это время выполнения для нас критично — нужно понять почему это происходит. Куда мы упирается.» — и вот тут то и начинается самое интересное — как вы определяете 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. Было ли у вас такое?