Задача

Проанализировать результаты бенчмарка СУБД с использованием скользящей дисперсии.

Расчет скользящей дисперсии

По каждой точке t вычисляется дисперсия по выборке для входных значений (квадрат отклонения по выборке) за период [ t; t-60 минут].

Продолжение экспериментов и исследований

Начало Использование дисперсии при анализе производительности СУБД. Точка излома графика дисперсии / Хабр

Задача эксперимента

Анализ статистических показателей производительности СУБД при проведении стресс тестирования для разнородных СУБД, отличающихся по производителтности .

Продолжение анализа результатов стресс тестирования СУБД с использованием дополнительных статистических показателей.

Задача эксперимента

По результатам стресс тестирования СУБД определить статистические показатели производительности , для использования в качестве стартового события мониторинга при создания инцидента.

Определить предельное количество работающих соединений к СУБД , при заданном сценарии нагрузки .

Для расчета производительности СУБД используется метрика Производительность СУБД — расчет метрики, временной анализ, параметрическая оптимизация / Хабр (habr.com)

Создание нагрузки на СУБД - используется инструмент  pgbench

Или путевые заметки по ходу решения задачи разработки методики подбора комбинации значений конфигурационных параметров СУБД для оптимизации производительности СУБД .

В качестве начального примера, для отработки методики, выбраны настройки для процессов контрольной точки(checkpoint) и фоновой записи (bgwriter)

В качестве метода оптимизации использован метод покоординатного спуска.

Для получения значения производительности СУБД используется метрика Производительность СУБД — расчет метрики, временной анализ, параметрическая оптимизация / Хабр (habr.com)

Историческое предисловие

Как известно, основная задача DBA — обеспечить наиболее эффективную и производительную работу вверенной ему в сопровождение СУБД. Для выполнения задачи одно из основных требований — умение определить насколько производительно/эффективно СУБД справляется с получаемой нагрузкой и выдает требуемый результат. Для этого необходимо определить такое понятие как производительность СУБД. Потому, что очень важно, для начала, хотя бы обеспечить мониторинг и иметь возможность сразу сказать — в каком состоянии СУБД — минимальная загрузка, оптимальная, перегруз, авария. Однако, как выясняется общего понятия «производительность СУБД» до недавнего времени не существовало. Каждый DBA понимал под производительностью, то, что лично ему нравится — количество запросов в секунду, количество зафиксированных транзакций, среднее время отклика СУБД и даже процент утилизации CPU+RAM или вывести на экран десяток другой графиков мониторинга и каким то мистическим образом определить хорошо работает СУБД или плохо.

Ситуацию надо было менять, ибо, как говорится — для того, что бы чем то управлять и улучшать надо это для начала измерить.

В статье рассматривается практическое использование методов статистического анализа для определения причин деградации производительности СУБД Postgres Pro.

Используются разработанные сервисные скрипты для сбора статистической информации о производительности и состоянии СУБД и модуль pgpro_pwr для определения текста проблемных SQL запросов.

В качестве ответа на комментарий https://habr.com/ru/posts/848370/#comment_27385020

В рамках комментария картинки будут совсем не видны. А при создании поста- только одно изображение .

Поэтому пришлось выделить в виде статьи.

Собственно тема скользящей средней и медианы описана давно и не является чем-то новым и данная статья - не исключение. Просто , скорее заметка на память .

Задача

Подготовить методику статистического анализа результата бенчмарка производительности СУБД при заданном характере нагрузки , для данной инфраструктуры СУБД.

Задачи эксперимента

1) Оценить степень влияния регулярного выполнения vacuum/analyze на производительность СУБД.

2) Оценить степень влияния распухания таблицы на производительность СУБД.

Обычные последствия после получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.

Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.

Всегда ли снижение производительности является инцидентом и требует решения и поиска причин?

Для исключения ложного срабатывания и непродуктивной траты времени, можно использовать методы корреляционного анализа ожиданий СУБД.

В статье, в самом общем виде, рассмотрены некоторые методы использования математической статистики и примерный порядок действий для определения факта наличия инцидента снижения производительности и установления одной из причин деградации производительности, на реальном примере.

Ради интереса посмотрел статистику по последним статьям .

Результат интересен и наводит на определённые выводы .

Чем проще и менее техническая статья - тем больше ее читают , дочитывают и реагируют читатели Хабра.

Завершение цикла

Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)

Задача

Оценить производительность СУБД при постоянной нагрузке, в условиях нестабильной инфраструктуры .

Проблема

На производительность СУБД влияет множество случайных факторов. Производительность инфраструктуры не постоянна и меняется в очень широком диапазоне.

Гипотеза

В идеальных условиях, при постоянной нагрузке, значения производительности СУБД должно иметь нормальное распределение.

Начало Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)

Следующая серия экспериментов выполняется с использованием периода сглаживания = 1 час.

Предпосылка к исследованию

Исследование гипотезы СУБД по природе своей является стохастической, а не детерминированной системой.

С целью проверки утверждения и в связи с началом работ по подготовке методики статистического анализа СУБД в условиях облачной среды, была начата серия экспериментов для определения влияния внешних/случайных факторов инфраструктуры на производительность СУБД .

В статье, в общих словах рассматриваются 2 вопроса:

1) Как рассчитать метрику производительности СУБД

2) Как использовать корреляционный анализ для поиска причин снижения производительности СУБД

Иногда в докладах/статьях о оптимизации производительности СУБД описание предлагаемой методики/средства начинается с события -"мы заметили резкое увеличение времени выполнения запроса/запросов и резкое увеличение количества прочитанных блоков разделяемой области". Далее следует описание процесса выявления ресурсоёмкого запроса, с целью его оптимизации.

На этапе разработки данных сценарий вполне себя оправдывает . Нагрузка на СУБД - детерминирована, характер нагрузки определён и описан, данные постоянны. При условии адекватности команды разработки, даже удастся действительно оптимизировать запрос.

Но.

В процессе промышленной эксплуатации ситуация меняется принципиально .