Комментарии 29
1) Статистический анализ бенчмарков (постоянная нагрузка в условиях нестабильной инфраструктуры).
2) Корреляционный анализ ожиданий СУБД (случайная нагрузка в условиях нестабильной инфраструктуры).
Для начала скажу, что я тут не в теме совсем. У нас в геофизике выбросы - это либо явный брак, либо наоборот, что-то интересное (если они лежат в физически допустимых пределах, естественно).
Поэтому не принимайте нижесказанное чересчур близко к сердцу. Но вообще, в моем случае я бы поступил так:
1) отсеял мегавыбросы, которые на 99.99% являются браком мониторинга. Т.е. в данные как-то затесалось значение, не имеющее отношения к реальности. Если у Вас такое бывает, конечно
2) Далее про "реалистичные" выбросы. Т.е. когда нагрузка измерена правильно, но просто она резко отличается от обычной. Тут бы я сделал так:
3) Разделил сигнал на "норму" и "выбросы":
3а) "Анализ тенденции" я бы делал по ряду вообще без выбросов. Который показывает только "норму" и ее медленные изменения. Как его сглаживать при отсутствии выбросов - не важно, все методы дадут одно и то же примерно.
У нас это технически реализовано так: сперва мы идем одним фильтром и заменяем выбросы Nan-ами, а затем считаем среднее в окне по не-Nan-ам:
АverageValue= SUM(Data,NotNan(Data)) / COUNT(NotNan(Data))
Тут SUM и COUNT - это массивные операторы, вычисляющие 1) сумму маскированного массива (второй параметр = маска) и 2) количество не-Nan-ов в массиве Data. (Там, естественно, лежит попавший в текущее окно фрагмент сигнала). А NotNan() - это элементная функция, которая применяется к каждому элементу массива.
Массивные операторы сейчас работают практически мгновенно
В древности, когда у нас все было на DOS-фортране, а скользящие окна и ряды уже были длинные-длинные, я писал всякие трюки с поэлементным добавлением и выкидыванием элементов из массива Data по мере движения окна (мы обычно смещаем окно на одну точку, чтобы не ухудшать дискретизацию времени в обработанном сигнале). А не так давно обнаружил, что при размере окна порядка миллиона отсчетов теперь нет смысла с этим морочиться. А более широкие окна мы почти не используем. В общем, с эффективностью у Фортрана всегда все было неплохо, а теперь еще и читаемость кода подтягивается ;-)
В примере- фортран-95, но в других языках сейчас уже наверняка должно быть что-то подобное
3б) Также я бы сделал сигнал с выбросами, в который включаются все данные. То есть, в этом случае мы считаем аномалии частью "правильного" сигнала, просто не очень обычной.
Но тогда сглаживать медианой плохо - она просто уберет аномалии
А если мы хотим их убрать, то гораздо лучше взять ряд (3а),где выбросы вычищены совсем.
Поэтому тут я бы сглаживал
простым или ядерным скользящим средним
понятно, что если окно скачущее, т.е. смещается на свою ширину или полуширину каждый раз, то нужно брать обычное среднее. А вот для скользящего на одну точку окна я предпочитаю гауссово ядро (хотя гораздо более простое треугольное даст почти то же самое)
3в) Ну и третий ряд - это "чисто выбросы". Точнее, отдельно два ряда: "выбросы вверх" и "выбросы вниз" (если, конечно, они оба физически интересны). Это чтобы анализировать сами выбросы и пытаться понять их причины. В этом случае мы на первом шаге заменяем Nan-ами все не-выбросы, и т.д. Еще можно разделить ряды выбросов на ряд "средний уровень фона в текущем окне". Чтобы отнормировать амплитуду выбросов к текущей средней нагрузке.
Как видите, я бы попытался извлечь из сигнала максимум информации. У нас это оправданно, так как приборов в поле стоит очень мало, и однородные ряды данных - на вес золота. Когда (и если) они получены, то дальше совсем не грех заняться с ними чем-нибудь интересным. Насколько это может быть применимо в Вашем случае - это вопрос не ко мне. Я вообще-то сюда заглянул, чтобы дать ссылку на пару идей по работе с выбросами (их детектирование и коррекция/выбраковка). Но вот может ли какая-то из этих идей выстрелить в Вашем случае - это не мне судить.
Что является критерием выброса ? Z-оценка ? Превышение среднего ? Что то еще ?
К сожалению, у нас геофизические ряды, там совсем другая специфика. У нас в каждом конкретном сигнале причины выбросов (и оптимальные рецепты по работе с ними) различны. Если сигнал важный и интересный, то мы обычно пробуем с десяток разных критериев, и потом экспертно (=субъективно) смотрим и сравниваем: какой из них лучше нравится в плане результатов? В определенном смысле это подгонка, но другие варианты, говоря философски, тоже не идеальны.
Поэтому конкретно по Вашей ситуации я ничего не скажу: я просто не знаю. Я только хотел намекнуть, что вариантов решения - великое множество, и что выбор лучшего - это отдельный квест. Его можно искать априорно (если Вы точно знаете, чего хотите сделать и почему именно это), либо эмпирически (это когда Вы прищуренным глазом смотрите на сигналы, обработанные разными способами, в надежде в один прекрасный момент вспомнить греческий). Но вообще, если задача не совсем типовая, то ответ почти обычно приходится искать самому. Точнее, иногда можно подглядеть у соседа по парте, но для этого у Вас с ним должен быть одинаковый вариант. У нас - геофизиков - это очень редко бывает.
Но тут важна физика: в чем причина выбросов?
Эх.... Если бы это удалось установить . Период сбора данных = 1 минута. Период семплирования ожиданий СУБД =10ms. У меня пока нет инструментов для сбора статистики для периода менее 1 минуты.
Ну вот, Вы еще раз макнули мое самолюбие мордой в грязь ;-) Я почему-то до этого был уверен, что хорошие СУБД так не делают ;-) Что резкие выбросы на таких больших квантах времени - это плохо, и поэтому мудрые разработчики уже давно все подобные аномалии побороли. Точнее, я верю, что СУБД может ощутимо притормозить, если там подтянулись какие-то ресурсоемкие внутренние процессы. Но резко ускориться?! Ведь если запросов много, и они случайным образом поступают из многих разных источников, то согласно ЦПТ, выбросов там быть не должно? Да и резерв производительности СУБД не бесконечный... А не могли ли там еще какие-то аномалии и в инструментах сбора статистики наложиться?
В общем, на мой незамыленный взгляд профана, в такой ситуации можно попытаться проанализировать именно выбросы. Без фонового сигнала. Но мне легко говорить: я фактически всю жизнь такими трюками с нашими геофизическими сигналами занимаюсь (у себя мне для этого надо пару кнопок нажать). В Вашем случае это может быть и не нужно, и технологически неудобно....
Задача не очень понятна. Мы у себя (не СУБД!) просто исключаем выбросы, после чего уже разницы почти нет - что именно считать. Но тут важна физика: в чем причина выбросов? Как они входят в целевую статистику? От этого зависит, как с ними быть. Ну и цель надо поконкретнее ставить, т.к. первый (и главный) шаг при выборе наилучшего метода - это сформулировать цель обработки (= критерии оптимальности).
Еще есть идея взвешивания выбросов. Подробнее про обе идеи см. в справке к нашей программе ABD: файл WinABD_Help вот в этом каталоге, там раздел
3.4.1. Анализ и чистка выбросов. Выравнивание дисперсии сигнала, выбраковка аномалий (метод Level)
Программу можно взять там же, чтоб поиграться с рядами, прогнать через алгоритм Level с разными настройками и наглядно сравнить варианты. Задачи такого рода мы в ней щелкаем, как орешки - вот только сперва придется Ваши ряды туда загрузить, а с этим не каждый мидл справится ;-) Так как продукт узконишевый, и порог вхождения около потолка :-)
А вот справку гляньте, может что-то себе присмотрите. Если вопросы конкретизируете, может еще чего подскажу...
Спасибо за информацию. Принято, посмотрю внимательнее , наверняка будут вопросы для уточнения. А пока
Задача не очень понятна
...
Ну и цель надо поконкретнее ставить
Задача - имеется СУБД в облачной инфраструктуре , влияние внешних факторов и посторонней нагрузки на производительность существенно , постоянно и случайно. Необходим анализ тенденции , а не реагирование на постоянные аномалии, вызванные как внутренними так и внешними причинами.
Если же ставить вопрос более широко - есть 2 задачи:
1) Статистический анализ бенчмарков (постоянная нагрузка в условиях нестабильной инфраструктуры).
2) Корреляционный анализ ожиданий СУБД (случайная нагрузка в условиях нестабильной инфраструктуры).
И в первом и во втором случае анализируются сглаженные данные . Как выглядят неслаженные данные для второй задачи, наверное представляете .
Мы у себя (не СУБД!) просто исключаем выбросы
Что является критерием выброса ? Z-оценка ? Превышение среднего ? Что то еще ?
Но тут важна физика: в чем причина выбросов?
Эх.... Если бы это удалось установить . Период сбора данных = 1 минута. Период семплирования ожиданий СУБД =10ms. У меня пока нет инструментов для сбора статистики для периода менее 1 минуты.
Ещё рас спасибо за наводку . Буду смотреть .
1) Статистический анализ бенчмарков (постоянная нагрузка в условиях нестабильной инфраструктуры).
2) Корреляционный анализ ожиданий СУБД (случайная нагрузка в условиях нестабильной инфраструктуры).
Для начала скажу, что я тут не в теме совсем. У нас в геофизике выбросы - это либо явный брак, либо наоборот, что-то интересное (если они лежат в физически допустимых пределах, естественно).
Поэтому не принимайте нижесказанное чересчур близко к сердцу. Но вообще, в моем случае я бы поступил так:
1) отсеял мегавыбросы, которые на 99.99% являются браком мониторинга. Т.е. в данные как-то затесалось значение, не имеющее отношения к реальности. Если у Вас такое бывает, конечно
2) Далее про "реалистичные" выбросы. Т.е. когда нагрузка измерена правильно, но просто она резко отличается от обычной. Тут бы я сделал так:
3) Разделил сигнал на "норму" и "выбросы":
3а) "Анализ тенденции" я бы делал по ряду вообще без выбросов. Который показывает только "норму" и ее медленные изменения. Как его сглаживать при отсутствии выбросов - не важно, все методы дадут одно и то же примерно.
У нас это технически реализовано так: сперва мы идем одним фильтром и заменяем выбросы Nan-ами, а затем считаем среднее в окне по не-Nan-ам:
АverageValue= SUM(Data,NotNan(Data)) / COUNT(NotNan(Data))
Тут SUM и COUNT - это массивные операторы, вычисляющие 1) сумму маскированного массива (второй параметр = маска) и 2) количество не-Nan-ов в массиве Data. (Там, естественно, лежит попавший в текущее окно фрагмент сигнала). А NotNan() - это элементная функция, которая применяется к каждому элементу массива.
Массивные операторы сейчас работают практически мгновенно
В древности, когда у нас все было на DOS-фортране, а скользящие окна и ряды уже были длинные-длинные, я писал всякие трюки с поэлементным добавлением и выкидыванием элементов из массива Data по мере движения окна (мы обычно смещаем окно на одну точку, чтобы не ухудшать дискретизацию времени в обработанном сигнале). А не так давно обнаружил, что при размере окна порядка миллиона отсчетов теперь нет смысла с этим морочиться. А более широкие окна мы почти не используем. В общем, с эффективностью у Фортрана всегда все было неплохо, а теперь еще и читаемость кода подтягивается ;-)
В примере- фортран-95, но в других языках сейчас уже наверняка должно быть что-то подобное
3б) Также я бы сделал сигнал с выбросами, в который включаются все данные. То есть, в этом случае мы считаем аномалии частью "правильного" сигнала, просто не очень обычной.
Но тогда сглаживать медианой плохо - она просто уберет аномалии
А если мы хотим их убрать, то гораздо лучше взять ряд (3а),где выбросы вычищены совсем.
Поэтому тут я бы сглаживал
простым или ядерным скользящим средним
понятно, что если окно скачущее, т.е. смещается на свою ширину или полуширину каждый раз, то нужно брать обычное среднее. А вот для скользящего на одну точку окна я предпочитаю гауссово ядро (хотя гораздо более простое треугольное даст почти то же самое)
3в) Ну и третий ряд - это "чисто выбросы". Точнее, отдельно два ряда: "выбросы вверх" и "выбросы вниз" (если, конечно, они оба физически интересны). Это чтобы анализировать сами выбросы и пытаться понять их причины. В этом случае мы на первом шаге заменяем Nan-ами все не-выбросы, и т.д. Еще можно разделить ряды выбросов на ряд "средний уровень фона в текущем окне". Чтобы отнормировать амплитуду выбросов к текущей средней нагрузке.
Как видите, я бы попытался извлечь из сигнала максимум информации. У нас это оправданно, так как приборов в поле стоит очень мало, и однородные ряды данных - на вес золота. Когда (и если) они получены, то дальше совсем не грех заняться с ними чем-нибудь интересным. Насколько это может быть применимо в Вашем случае - это вопрос не ко мне. Я вообще-то сюда заглянул, чтобы дать ссылку на пару идей по работе с выбросами (их детектирование и коррекция/выбраковка). Но вот может ли какая-то из этих идей выстрелить в Вашем случае - это не мне судить.
Что является критерием выброса ? Z-оценка ? Превышение среднего ? Что то еще ?
К сожалению, у нас геофизические ряды, там совсем другая специфика. У нас в каждом конкретном сигнале причины выбросов (и оптимальные рецепты по работе с ними) различны. Если сигнал важный и интересный, то мы обычно пробуем с десяток разных критериев, и потом экспертно (=субъективно) смотрим и сравниваем: какой из них лучше нравится в плане результатов? В определенном смысле это подгонка, но другие варианты, говоря философски, тоже не идеальны.
Поэтому конкретно по Вашей ситуации я ничего не скажу: я просто не знаю. Я только хотел намекнуть, что вариантов решения - великое множество, и что выбор лучшего - это отдельный квест. Его можно искать априорно (если Вы точно знаете, чего хотите сделать и почему именно это), либо эмпирически (это когда Вы прищуренным глазом смотрите на сигналы, обработанные разными способами, в надежде в один прекрасный момент вспомнить греческий). Но вообще, если задача не совсем типовая, то ответ почти обычно приходится искать самому. Точнее, иногда можно подглядеть у соседа по парте, но для этого у Вас с ним должен быть одинаковый вариант. У нас - геофизиков - это очень редко бывает.
Но тут важна физика: в чем причина выбросов?
Эх.... Если бы это удалось установить . Период сбора данных = 1 минута. Период семплирования ожиданий СУБД =10ms. У меня пока нет инструментов для сбора статистики для периода менее 1 минуты.
Ну вот, Вы еще раз макнули мое самолюбие мордой в грязь ;-) Я почему-то до этого был уверен, что хорошие СУБД так не делают ;-) Что резкие выбросы на таких больших квантах времени - это плохо, и поэтому мудрые разработчики уже давно все подобные аномалии побороли. Точнее, я верю, что СУБД может ощутимо притормозить, если там подтянулись какие-то ресурсоемкие внутренние процессы. Но резко ускориться?! Ведь если запросов много, и они случайным образом поступают из многих разных источников, то согласно ЦПТ, выбросов там быть не должно? Да и резерв производительности СУБД не бесконечный... А не могли ли там еще какие-то аномалии и в инструментах сбора статистики наложиться?
В общем, на мой незамыленный взгляд профана, в такой ситуации можно попытаться проанализировать именно выбросы. Без фонового сигнала. Но мне легко говорить: я фактически всю жизнь такими трюками с нашими геофизическими сигналами занимаюсь (у себя мне для этого надо пару кнопок нажать). В Вашем случае это может быть и не нужно, и технологически неудобно....
Поэтому не принимайте нижесказанное чересчур близко к сердцу. Но вообще, в моем случае я бы поступил так:
Вы даже не представляете, как столько времени ждал хоть какой то нормальной обратной связи и нормальных комментариев. Поэтому , еще раз - спасибо за комментарии.
1) отсеял мегавыбросы, которые на 99.99% являются браком мониторинга. Т.е. в данные как-то затесалось значение, не имеющее отношения к реальности. Если у Вас такое бывает, конечно
Возникает самый главный вопрос - а что считать выбросом ? 3сигма - не подходит, распределение на равномерное. Проблема в том, что в случае выброса это не ошибка, это стечение обстоятельств. Ну например - просто вот именно в эту минуту паразитная нагрузка на виртуальную машину резко снизилась, было выполнено очень много простых запросов , обращение к диску не было (все нашлось в кэше) в результате производительность резко скакнула. Возможно и наоборот - гипервизор начал перестраиваться, пошла дополнительная нагрузка на СХД, антивирус проснулся и загрузил СПУ, большой запрос вынужден писать блоки с диска в кэш. Т.е. это не брак, не ошибка, это стечение обстоятельств. Наверняка даже можно построить статистические зависимости именно по выбросам. Но это другая тема.
3) Разделил сигнал на "норму" и "выбросы":
Согласен.
3а) "Анализ тенденции" я бы делал по ряду вообще без выбросов. Который показывает только "норму" и ее медленные изменения. Как его сглаживать при отсутствии выбросов - не важно, все методы дадут одно и то же примерно.
Согласен - интересует тенденция , не пики. На тестовых(там мало выбросов) данных хорошо видно, анализ скользящей средняя и медиана принципиально не отличаются. Средняя визуально даже более, понятна получается.
мы идем одним фильтром и заменяем выбросы
Сорри, за повторение вопроса - как решаете какое значение считается выбросом ?
В примере- фортран-95
За это упоминание - отдельное спасибо. Помню.
А вот для скользящего на одну точку окна я предпочитаю гауссово ядро
Спасибо взял в заметки. Надо эту мысль подумать. Если , что-то выгорит и в реальности реализовано будет - Хабр себя оправдал!
Насколько это может быть применимо в Вашем случае
Предположу очень даже применимо. Чудес не бывает, всему есть причина. Тем более в данном случае имеем дело не с показаниями приборов а с цифрами. Ошибок быть не должно. Скачки и падения - не просто так. Есть причина, даже если она сразу и не известна.
Я только хотел намекнуть, что вариантов решения - великое множество, и что выбор лучшего - это отдельный квест.
Это точно. Я уж столько всего перепробовал, а сколько еще предстоит.
Точнее, я верю, что СУБД может ощутимо притормозить, если там подтянулись какие-то ресурсоемкие внутренние процессы. Но резко ускориться?!
А если посмотреть на вопрос под другому - СУБД постоянно тормозит но иногда по стечению обстоятельств внешняя нагрузка на время пропадает. В данном случае, время не такое и маленькое - 1 минута.
Ведь если запросов много, и они случайным образом поступают из многих разных источников, то согласно ЦПТ, выбросов там быть не должно?
Но есть один очень важный момент. Кроме нагрузки создаваемой на СУБД запросами есть нагрузки создаваемые внутренними процессами СУБД + нагрузка инфраструктуры. Ну например - именно в это момент отключили несколько виртуалок и утилизация СХД резко упала, потом опять включили и утилизация возросла -а в результате - сначала резкое снижение ожиданий IO потом опять рост. Ну это так примерно на пальцах , очень приближенно. А если еще вспомнить , что CPU могут менять тактовую частоту или ОС имеет не один и не два кэша, а еще и кэши CPU... Т.е. производительность СУБД обусловлена не только запросами но и очень многими внешними(неуправляемыми и случайными) факторами.
А не могли ли там еще какие-то аномалии и в инструментах сбора статистики наложиться?
Это мое очень серьезное опасение и прям таки тревога. На одну аномалию я случайно уже наткнулся - разница в округлении для numeric и double precision. Долго ошибку искал пока понял , в чем дело . А сколько еще может быть скрыто ;-(
в такой ситуации можно попытаться проанализировать именно выбросы.
Повторюсь - это очень интересная мысль. Хотя , надо еще подумать над предметной областью.
Спасибо большое за комментарии. Есть над чем подумать.
У вас на графиках разные точки отсчета. Ну нельзя же так.
А так, медиана лучше исключает выбросы по очевидным причинам, ведь эти выбросы в окне оказываются самыми маленькими или большими и в медиану никак не попадут. Максимум, они сдвинут медиану на соседнее корректное значение. Медиана рабоатет даже для маленьких окон.
Среднее сглаживает выбросы только если окно сильно большое, а выбросы редкие. Ибо каждый выброс изменит ответ на |Error|/N, где Error - размер ошибки, а N - размер окна.
Еще медиану в окне немного сложнее считать.
У вас на графиках разные точки отсчета.
Прошу , прощения , просьба уточнить . Что значить "разные точки отчёта "?
Еще медиану в окне немного сложнее считать.
В чем сложность отсортировать набор данных ?
Медиана в статистике — это значение, которое делит упорядоченный набор данных на две равные части. Другими словами, половина значений в наборе данных меньше медианы, а другая половина — больше. 1
Чтобы вычислить медиану, сначала нужно упорядочить данные. Затем, если количество значений в наборе данных нечётное, медианой будет значение, которое находится ровно посередине. Если количество значений чётное, медианой будет среднее арифметическое двух центральных значений. 1
Пример вычисления медианы: предположим, есть следующий набор данных: {1, 2, -2, 4, -3}. Чтобы найти медиану, сначала упорядочивают данные: {-3, -2, 1, 2, 4}. Так как количество значений в наборе данных нечётное (5), медианой будет значение, которое находится ровно посередине, то есть 1.
Чтобы найти медиану в PostgreSQL, можно использовать функцию percentile_cont.
Пример запроса:
SELECT percentile_cont (0.5) WITHIN GROUP (ORDER BY sales) FROM table;
Что значить "разные точки отчёта "?
график с выбросом показывает отрезок от 2989 до 4989+ по оси OY. Сглаженные графики показывают отрезки 4727-4757 и 4877-4927. Их же невозможно так сравнивать. Стоило привести их к одному масштабу. Если на таких графиках полхо видно, то можно потом приблизить какую-то часть, но опять же, в одном масштабе.
В чем сложность отсортировать набор данных ?
Я с точки зрения вычислений. Сортировка - сильно медленнее и сложнее, чем поддерживать сумму чисел в окне.
график с выбросом показывает отрезок от 2989 до 4989+ по оси OY. Сглаженные графики показывают отрезки 4727-4757 и 4877-4927. Их же невозможно так сравнивать. Стоило привести их к одному масштабу.
Да мысль вполне понятна. Замечание принимается. Дополню графики, и добавлю еще показания и на рабочей нагрузке тоже. Там значения скачут очень существенно.
Стоило привести их к одному масштабу.
Добавил график реальных данных , с реальными выбросами.
У вас на графиках разные точки отсчета. Ну нельзя же так.
Спасибо за комментарий!
Если на одном графике смотреть - то картина получается сильно другая. Особей разницы на одном масштабе между скользящей средней и скользящей медианой - нет.
Но в данном случае дисперсия значений не сильно меняется по ходу наблюдений. А вот если данные сильно скачут, то картина в разнице будет сильнее заметна.
Дополню статью. Спасибо.
Если нужно определить наиболее вероятную величину то медиана, потому что она ближе к моде чем среднее при прочих равных для непрерывных распределений. Если нужно какую-то интегральную информацию, типа средней мощности, скорости и ТД, то очевидно среднее. Я в обработке цифровых сигналов от детекторов, чтобы вычесть подложку использую медиану, она в этом плане очень устойчива.
Я в обработке цифровых сигналов от детекторов, чтобы вычесть подложку использую медиану, она в этом плане очень устойчива.
Спасибо за комментарий. Я пока для статистического анализа производительности СУБД так же использую медиану.
А вот для статистического анализа результатов бенчмарков , подсказывают правильнее использовать среднее. Хотя, честно говоря, пока не могу уловить принципиальную разницу. Если между бенчмарками есть разница то она проявится и для среднего и для медианы.
Здравствуйте. Я пришел сюда по ссылке из вашего предыдущего поста. Вопрос по графикам из раздела "Пример из жизни". На графиках исходных данных Эксперимента 1 видно как будто 2 кривых. Это что, данные одного и того же временного ряда имеют тенденцию группироваться так, как будто на графике две кривых? Для Эксперимента 2 происходит то же самое.
Если это данные одного временного ряда группируются в 2 явно выраженных кластера - то наилучшим подходом, на мой взгляд, было бы их сначала разделить на принадлежность к первому или второму кластеру, а потом обрабатывать по отдельности. Визуально, разделение возможно безошибочное: можно провести одну прямую, разделяющую формирующиеся на графиках кластеры.
Возможно, по теме "Кластерный анализ" найдутся подходящие методы.
Может ли быть такое, что на вашу БД приходит 2 разных вида запросов, и обработка одного вида длится стабильно дольше (или вызывает бОльшую нагрузку), чем второго? В таком случае имеет смысл при сборе исходных данных собирать не только данные по нагрузке, но и данные по поступающим видам запросов и впоследствии группировать данные измерений в соответствии с этим. Тогда не понадобится кластерный анализ. Ведь помимо сложностей с тем, чтобы с ним разобраться и наладить, всегда существует риск, что на некоторых видах исходных данных он выдаст неверные результаты.
Вопрос по графикам из раздела "Пример из жизни". На графиках исходных данных Эксперимента 1 видно как будто 2 кривых.
Каждая точка это одно измерение производительности СУБД. Периодичность измерения 1 минута. Это пример из жизни с тестовой нагрузкой.
Реальная нагрузка выглядит чуть по другому
наилучшим подходом, на мой взгляд, было бы их сначала разделить на принадлежность к первому или второму кластеру, а потом обрабатывать по отдельности.
Как можно разделить показатели производительности СУБД ? По какому признаку ?
Может ли быть такое, что на вашу БД приходит 2 разных вида запросов
Это не может быть это именно так и есть. Кроме пользовательских операций с тестовыми таблицами SELECT , INSERT , UPDATE , на СУБД непосредственно влияют сервисные процессы autovacuum, checkpoint, etc. И это самый простой случай, пользовательская нагрузка ограничена и контролируема. Влияние процессов СУБД может быть значительным, но более менее предсказуемо . Вот с внешней нагрузкой сложнее - как и когда запустится антивирус и что там происходит на гипервизоре и СХД у DBA - информации нет .
имеет смысл при сборе исходных данных собирать не только данные по нагрузке, но и данные по поступающим видам запросов и впоследствии группировать данные измерений в соответствии с этим.
Мониторинг производительности отдельных запросов к СУБД это следующая очень большая тема будет. Пока только наброски Мониторинг производительности отдельного SQL запроса / Хабр (habr.com)
Тема еще на этапе эскизной проработки. После более менее завершения со статистическим анализом производительности СУБД и бенчмарков , займусь запросами.
Спасибо за разъяснение. В приведенных в вашем комментарии графиках слишком мало данных - трудно увидеть на глаз какие-либо определенные закономерности. На первом графике несколько выпадающих точек, но какой закономерности они подчиняются, непонятно. На втором графике выпадающие точки как будто образуют линию. На третьем - опять непонятно.
А как у вас вообще определяется понятие "Производительность" и как проводится ее измерение?
Просто на правах абстрактного размышления. Вот вы получили из измерений какие-то данные. Например, измерили температуру всех пациентов в больнице. Если просто усреднить (средним или медианой) эти данные - то получите среднюю температуру по больнице - величину весьма бесполезную. Но если видно, что данные измерений имеют тенденцию кучковаться около нескольких "центров притяжения" - иными словами, образовывать кластеры - то есть смысл эти кластеры разделить.
Как правило, образованию кластеров способствуют изменения параметров наблюдаемого процесса. В случае больницы - тип заболевания. Если этот тип заранее известен (диагноз поставлен) - то можно измеренные температуры группировать в соответствии с диагнозом. Скорее всего, в каждой из групп после такого разделения больше не будет наблюдаться кластеризация.
Если же диагноз заранее неизвестен (например, ставится задача поставить диагноз по измеренной температуре) - то можно применить методы кластерного анализа для автоматического выявления кластеров и их разделения.
После анализа разделенных данных результаты всегда можно, если требуется, снова объединить. Например, если начальство интересует только средний процент выздоровления пациентов независимо от того, чем они болели. Но анализ разделенных данных обычно дает больше информации.
Особенно, если причины образования кластеров заранее неизвестны - то в ходе дальнейшего анализа данных и их исследования может появиться возможность выяснить эти причины и изучить их более подробно.
В приведенных в вашем комментарии графиках слишком мало данных - трудно увидеть на глаз какие-либо определенные закономерности.
Приведенные в комментарии данные это показатели обычной производительности. Не постоянная нагрузка для benchmark. Закономерности там и не должно быть , есть корреляции с активными сессиями СУБД и ожиданиями СУБД .
А как у вас вообще определяется понятие "Производительность" и как проводится ее измерение?
За ответ на этот вопрос меня регулярно минусуют и сливают карму ;-) Но я уточню.
Ранее производительность считалась как модуль вектора ( N1 , N2 , N3 ) , где N1- количество блоков распределенной памяти записанных в секунду, где N2- количество блоков распределенной памяти прочитанных в секунду, где N3- количество блоков распределенной памяти записанных в секунду. Проще говоря это объемная скорость обработки информации СУБД . Данная метрика вполне себе работает и согласуется с реальной картиной наблюдений ( когда есть реальная авария , метрика падает , что кстати нельзя сказать о метрике "среднее время отклика") . Но , всегда есть но. Если считать метрику таким образом , можно наткнутся на аномалию - я создаю индексы, в результате запросы работают быстрее, но метрика покажет снижение . Эта аномалия решена, сейчас метрика считается по другому, пока работы в процессе анализа и экспериментов, чуть позже будет статья. Наверное когда будет готова статья о применении метода покоординатного спуска для оптимизации набора параметров СУБД. В общем сейчас метрика согласуется с реальными наблюдениями - чем эффективнее работают запросы в СУБД - тем выше метрика.
Но если видно, что данные измерений имеют тенденцию кучковаться около нескольких "центров притяжения" - иными словами, образовывать кластеры - то есть смысл эти кластеры разделить.
Да , именно так и есть. Но тут возникает очень серьезная проблема - запросов не просто много , а очень много .собирать историю и статистику по всем запросам , что бы разделять их затем по какой либо группировке - очень затратно. Я в свое время (первая статья на хабре) пытался строить историю выполнения запроса - получалось несколько мегабайт(или даже гигабайт) в минуту при средней (порядка 100 активных сессий) нагрузке. Тема еще ждет своего развития.
Чем еще мне не нравится средняя температура по больнице применимо к запросам . Допустим время отклика увеличилось , это инцидент ? Не обязательно - просто характер нагрузки изменился. Например, ввели все данные и запускают аналитику. Это вполне штатная ситуация , но она потребует время на анализ . С другой стороны, и это зафиксированный факт со скриншотами, возможна реальная авария и при этом время отклика уменьшается . Т.е. метрика "Время отклика СУБД" подвержено ошибкам первого и второго рода. Да , меня за это минусуют, но это факт. И ничего с этим не поделать. Мы давно не анализируем эту метрику.
Как правило, образованию кластеров способствуют изменения параметров наблюдаемого процесса.
Да именно. Запросы OLTP , OLAP , DWH они сильно разные. Но, пока эта тема в стадии предварительного планирования . Наверное займусь на следующий год. На текущий момент более актуально
1) Анализ бенчмарков: количественная и качественная оценка вносимых изменений в конфигурацию СУБД и инфраструктуры на производительность СУБД. Например - на сколько изменится производительность СУБД если изменить параметр на 10%, на 50% , на 150% ?
2) Оптимизация наборов конфигурационных параметров СУБД для получения максимальной производительности
Мысль про кластеры , очень интересная , большое спасибо , и наверняка будет использована , когда дойдут руки до анализа производительности отдельных SQL запросов . Спасибо.
Просто напомню как сейчас делают DBA - просто смотрят время выполнения запроса. В жизни ситуация чуть другая - в одной ситуации запрос выдал R1 строк и затратил T1 времени , в другой ситуации тот же самый запрос выдал R2 строк и затратил T2 времени. Имеется ли деградация производительности , если T2 > T1 и R2 > R1 ?
И это самый простой случай, не учитывающий влияние данного запроса на другие запросы и СУБД в целом.
Спасибо. Есть еще вопросы по вашей метрике производительности.
1) Чем отличаются друг от друга N1 и N3? В описании я разницы не заметил. Возможно, вы допустили опечатку.
2) Что это за "блоки распределенной памяти", это не тот ли объем информации, который СУБД за единицу времени считывает с диска / записывает на диск? Но тогда результат ваших измерений более правильно было бы назвать "Нагрузкой на подсистему ввода-вывода", а не "Производительностью". Действительно, оптимизация БД, снижающая нагрузку на подсистему ввода-вывода (в вашем примере - введение индексов) не ухудшает, а улучшает работу БД с точки зрения пользователя.
А не будет ли логично измерять объем информации, принятый или переданный клиентам в ответ на их запросы за единицу времени? Или количество запросов, обслуженных за единицу времени? Или некоторую взвешенную сумму приведенных выше величин?
3) Почему вы вычисляете именно модуль вектора (N1,N2,N3) и как определен у вас этот "модуль"? Это именно модуль в Евклидовом пространстве = sqrt(N1^2+N2^2+N3^2) или что-то иное?
Если вы решили использовать Евклидову метрику - то она только тогда дает хорошие результаты, когда компоненты вектора взаимно перпендикулярны, т.е. ортогональны, т.е. не влияют друг на друга. Но я боюсь, что в вашей СУБД, скорее всего, присутствует взаимное влияние чтения и записи. Если вы измерите максимально достижимые скорости чтения и записи по отдельности, а потом одновременно - то вряд ли окажется, что чтение и запись можно вести одновременно на максимальной скорости. Или в вашей системе можно?
Если предположить, что максимальная скорость одновременных чтения/записи равна половине максимальной скорости чтения или записи по отдельности - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
1) Чем отличаются друг от друга N1 и N3? В описании я разницы не заметил. Возможно, вы допустили опечатку.
Да конечно , это опечатка. Сорри. N1 - количество записанных блоков в секунду, N3 - количество измененных(загрязнённых) блоков в секунду.
2) Что это за "блоки распределенной памяти", это не тот ли объем информации, который СУБД за единицу времени считывает с диска / записывает на диск?
СУБД не читает данные с диска непосредственно . Блоки читаются из распределенно области памяти. Разумеется , если блок в общей памяти не найден , он будет читаться с диска( а это задержка на дисковую операцию). Если все данные находятся в памяти , то операции с диском минимальны. В этом то и есть момент оптимизации - количество прочитанных блоков одинаково, но время выполнения одного и того же запроса разное. Причин - мегатонны.
А не будет ли логично измерять объем информации, принятый или переданный клиентам в ответ на их запросы за единицу времени?
Есть очень большая проблема с получением этих данных. Статистика СУБД не содержит информации об объеме информации переданной клиенту, только количество строк. Метрики мониторинга во первых врут, во вторых доступ к API мониторинга из СУБД , я например не знаю как реализовать.
Это именно модуль в Евклидовом пространстве = sqrt(N1^2+N2^2+N3^2)
Да именно так. Почему? Стратегического фундаментального обоснования нет. Пока не вижу причин, почему бы и не так считать.
Но есть одно очень важное уточнение. В настоящее время метрика производительности считается по другому. Не вдаваясь в глубинные подробности , если считать производительность как модуль векторы (N1, N2, N3) то возникает аномалия - берем запрос считаем производительность, добавляем индексы, запрос работает на порядки быстрее и эффективнее , но метрика снизится. А в случае если используется Index Only Scan будет равна 0 .
Сейчас метрика считается по другому. Статья в процессе подготовки.
Если предположить, что максимальная скорость одновременных чтения/записи равна максимальной скорости чтения или записи - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
А вот за это очередное спасибо. Потому, что повторюсь, никакого фундаментального обоснования использования Евклидового пространства - нет. Нужно было быстро получить цифру и перейти уже не посредственно к статистическому анализу.
Теперь есть возможность - оптимизировать.
Спасибо .
Но я боюсь, что в вашей СУБД, скорее всего, присутствует взаимное влияние чтения и записи.
Однако , спасибо за вопрос.
Вот так сразу даже не могу придумать экспериментальную проверку . Надо поглубже документацию почитать . И пока меня терзают смутные сомнения , что влияние имеет место .
А у вас есть возможность симулировать нагрузку на СУБД? Генерировать с помощью скрипта запросы "от клиентов"?
Да конечно . нагрузка стимулируется с помощью штатной утилиты pgbench. Стандартные запросы к тестовым таблицам select, insert, update.
И поскольку нагрузка создается одновременно , не от одной сессии, точно есть одновременные операции чтения/записи. Наверное это уже больше вопрос по части Unix, не СУБД. Как друг на друга влияет чтение и запись в ram и io?
Что касается СУБД то наверняка кэш СУБД может стать узким местом при очень большом количестве операций чтения/записи. Но зто тема следующего исследования .
Меня давно интересовало - откуда взялась всем рекомендуемая цифра размера shared_buffer=25% от RAM size ?
Один раз встретил доклад на тему эксперимента по поводу размера shared_buffer, кстати в облаке помню. Но , результаты эксперимента статистически не обрабатывались , это я тоже помню.
Если предположить, что максимальная скорость одновременных чтения/записи равна половине максимальной скорости чтения или записи по отдельности - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
Пользуясь случаем - вопрос. А какое принципиальное преимущество использование Манхэтенской метрики ? Возможны ли аномалии производительности , если использовать Евклидову метрику ?
Это ведь просто цифра, первоначально я хотел просто сумму использовать.
В вашем случае сумма и манхэттенская метрика - это одно и то же. Разница только в том, что последняя - сумма модулей, но так как у вас нет векторов с отрицательными координатами - то сумма компонентов векторов совпадает с суммой модулей этих компонентов.
Принципиальное преимущество в том, что такая метрика, возможно, лучше отражает физическую реальность в вашей ситуации. Всегда следует использовать наиболее близкие к реальности модели.
Я просто из своих познаний о работе интерфейсов ввода-вывода (диск или ОЗУ) припоминаю, что эти интерфейсы (и сами носители информации) не являются полнодуплексными. Одновременное чтение и запись невозможны. В каждый момент времени происходит или только чтение, или только запись. Поэтому максимальная производительность устройства ввода-вывода достигается только при передаче информации в одном направлении. Попытка одновременных чтения и записи (реализованная путем быстрого чередования малых операций чтения и записи) приведет, как минимум, к уменьшению скорости обмена в каждом направлении в 2 раза.
Отсюда и идея использовать манхэттенскую метрику. Одновременное чтение 1 ед/с и запись 1 ед/с создают "расстояние от центра" (суммарную нагрузку) в 2 ед/с.
В случае RAID-5 дисков, а также SSD-накопителей также нужно учесть, что запись в них происходит намного медленнее считывания.
Большое спасибо за комментарий
Принципиальное преимущество в том, что такая метрика, возможно, лучше отражает физическую реальность в вашей ситуации. Всегда следует использовать наиболее близкие к реальности модели.
Согласен по каждому пункту.
Расчет будет изменен. Результаты будут опубликованы .
Отсюда и идея использовать манхэттенскую метрику. Одновременное чтение 1 ед/с и запись 1 ед/с создают "расстояние от центра" (суммарную нагрузку) в 2 ед/с.
В случае RAID-5 дисков, а также SSD-накопителей также нужно учесть, что запись в них происходит намного медленнее считывания.
Ещё раз спасибо .
Казалось , бы вполне очевидное замечание. Но с очень далеко идущими последствиями.
Например - если назначить вес для операции записи больше чем операции чтения , метрика производительности при большем количестве записи будет меньше .
Осталось экспериментально рассчитать коэффициент .
Если за основу брать снимки pg_stat_statements, то они ведь уже содержат усреднённые значения. Дополнительное применение медианы по большим временным интервалам кажется избыточным, так как скрывает детали происходящего: пики по calls/<единицу времени> всплески rows/calls, аномалии shared_blks_read или shared_blks_hit и т.п. Для грубой оценки динамики нагрузки по времени суток годится, а для расследования инцидентов - будто бы и не очень.
Всегда думал, что в pg_stat_statements не хватает процентилей времени и других показателей по запросам, но поменял мнение. Вижу, что для адекватной реализации процентилей за временное окно нужно либо постоянно сбрасываться через pg_stat_statements_reset(), или же хранить довольно много данных в виде распределения по бакетам, а сами бакеты надо заранее определить и при этом ещё и нельзя двигать на лету. Снимки pg_stat_statements придётся уже делать по сырым счётчикам в бакетах и на выходе пересчитывать довольно упрощённые процентили.
Если за основу брать снимки pg_stat_statements, то они ведь уже содержат усреднённые значения.
Значения среднего времени выполнения запроса . Не производительности СУБД.
На текущем этапе исследований анализируется производительность СУБД в целом , в не время выполнения запроса . И еще важное замечание - метрика время отклика. СУБД подвержено ошибкам первого и второго рода . например во время реальной аварии , время отклика может уменьшаться .
Дополнительное применение медианы по большим временным интервалам кажется избыточным, так как скрывает детали происходящего
Задача - анализировать тенденцию. Не причину отдельных всплесков , мне нужны тренды . Учитывая предметную область - нисходящий тренд. Понять причину резких выбросов вряд ли можно и нужно . Повторю/уточню - работы ведутся в областной среде - виртуализация шумит постоянно.
а для расследования инцидентов - будто бы и не очень.
Совсем наоборот - именно для расследования инцидентов производительности и используется. Примеры в статьях.
Корреляционный анализ для определения причин деградации производительности СУБД https://habr.com/p/849778/
pg_stat_statements не хватает процентилей времени
Пример решения есть в статье
Построение гистограммы максимального и среднего времени выполнения запросов для PostgreSQL https://habr.com/p/805813/
Спасибо за ответ. Статью по гистограммам максимального и среднего времени конечно читал. Правильно понял, чтобы получить их процентили, надо ведь делать снимки pg_stat_statements достаточно часто (чтобы было больше стат. данных), при этом ещё и обнулять статистику при каждом снимке, чтобы не терять максимальные значения?
Вопрос о скользящей средней и медиане