Историческое предисловие
Как известно, основная задача DBA - обеспечить наиболее эффективную и производительную работу вверенной ему в сопровождение СУБД. Для выполнения задачи одно из основных требований - умение определить насколько производительно/эффективно СУБД справляется с получаемой нагрузкой и выдает требуемый результат. Для этого необходимо определить такое понятие как производительность СУБД. Потому, что очень важно, для начала, хотя бы обеспечить мониторинг и иметь возможность сразу сказать - в каком состоянии СУБД - минимальная загрузка, оптимальная, перегруз, авария. Однако, как выясняется общего понятия "производительность СУБД" до недавнего времени не существовало. Каждый DBA понимал под производительностью, то , что лично ему нравится - количество запросов в секунду, количество зафиксированных транзакций, среднее время отклика СУБД и даже процент утилизации CPU+RAM или вывести на экран десяток другой графиков мониторинга и каким то мистическим образом определить хорошо работает СУБД или плохо.
Ситуацию надо было менять , ибо , как говорится - для того, что бы чем то управлять и улучшать надо это уметь измерять.
Для начала надо определиться с определением и ответить на главный вопрос - что есть производительность СУБД ?
Вспоминая физику , можно использовать базовое понятие:
В физике производительность — это величина, которая обозначает объём работы, выполняемый за единицу времени (например, за час или за день). По-другому её можно назвать скоростью выполнения работы
Данное определение, было взято за основу. Осталось уточнить - что такое объем работы выполняемой СУБД ?
Методы расчета метрики производительности
Самый первый вариант расчета метрики
На этапе нагрузочного тестирования одного проекта, возникла необходимость - оценить степень влияния изменений вносимых разработчиками, на эффективность работы СУБД. Тогда впервые и возникла идея - надо считать метрику производительности .
А может быть производительность СУБД это вектор: (N1, N2, N3), где:
N1 - количество активных сессий
N2 - количество транзакций
N3 - количество запросов к СУБД в секунду.
https://habr.com/ru/posts/787966/
В принципе, метрика вполне себе работала и показывала ожидаемые результаты - основная часть изменений не оказывали вообще никакого влияния на работоспособность СУБД . В результате было сохранено очень много рабочего времени , потому , что не нужно стало объяснять и доказывать неэффективности предлагаемых изменений. Все видно на графиках и в таблицах.
Однако, как можно понять - метрика в общем то не совсем производительность считает. Очень важный момент - "количество активных сессий" , и тут возможна первая аномалия.
Аномалия учета ожиданий
Возможна ситуация - особенно при продуктивной нагрузке - работоспособность СУБД падает, а метрика растет.
Причина- количество активных сессий учитывает не только сессии выполняющие запросы , но и находящиеся в состоянии ожидания.
Порядок расчёта метрики производительности СУБД был изменен.
Второй вариант расчета метрики
Было принято решение изменить методику расчета, используя вектор:(N1, N2, N3, N4, N5), где:
N1 - количество страниц shared_buffer , прочитанных в секунду
N2 - количество страниц shared_buffer, записанных в секунду
N3 - количество страниц shared_buffer, измененных в секунду
N4 - количество завершенных запросов в секунду
N5 - количество зафиксированных транзакций в секунду
https://habr.com/ru/posts/804899/
Этот вариант проработал дольше . И обеспечил хорошую базу для работ по статистическому анализу производительности СУБД.
Корреляционный анализ для решения инцидентов производительности СУБД / Хабр (habr.com)
Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)
Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)
Статистический анализ результатов benchmark PostgreSQL / Хабр (habr.com)
Однако, благодаря обратной связи в комментариях к статьям(чуть позже найду этот комментарий, добавлю), была обнаружена еще одна аномалия .
Аномалия изменения плана выполнения запроса.
Для того, что бы обнаружить аномалию достаточно было провести очень простой эксперимент:
Создаем большие таблицы: родитель-потомок.
В таблицах не создаем индексы.
Подготавливаем запрос. Поскольку индексов нет , используется последовательное чтение.
Выполняем несколько итераций, фиксируем время выполнения запроса и показатель производительности СУБД.
Создаем индексы для таблиц.
Выполняем итерации того же самого запроса.
Фиксируем время выполнения запроса и показатель производительности СУБД.
Аномалия заключается в том, что запрос стал работать на порядки быстрее , стоимость запроса кардинально снизилась , следовательно эффективность резко возросла.
Причина: При выполнении индексного доступа к данным количество обработанных страниц shared_buffer существенно уменьшается. А при использовании метода доступа Index Only Scan вообще будет нулевым. В результате значение метрики производительности уменьшается.
Третий вариант расчета метрики
Для решения проблемы аномалии изменения плана выполнения запроса, расчет метрики был изменен. Для расчета метрики вводятся новые понятия .
Операционная(результативная) скорость
Полезными операциями(результатами) работы СУБД являются:
Количество строк выданных пользователю.
Количество запросов выполненных пользователем.
Количество зафиксированных пользователем транзакций.
Разделив количество на количество секунд (DB Time), которые потребовались на выполнения операций СУБД в изменяемый промежуток получаем операционную(результативную) скорость:
QPS: Количество запросов в секунду.
TPS: Количество транзакций в секунду.
RPS: Количество строк в секунду.
Для того, что бы иметь одну цифру используется модуль вектора ( QPS , TPS , RPS ).
Полученное значение и будет считаться операционной скоростью.
Объемная скорость
Работа СУБД заключается в обработке блоков информации:
Прочитанные разделяемые блоки
"Загрязнённые" разделяемые блоки
Записанные разделяемые блоки
Прочитанные локальные блоки
"Загрязнённые" локальные блоки
Записанные локальные блоки
Прочитанные временные блоки
Записанные временные блоки
Подробнее о разделяемых блоках: WAL в PostgreSQL: 1. Буферный кеш / Хабр (habr.com)
О локальных и временных блоках , пока не нашел. Найду , добавлю.
Таким образом, применив тот же подход , что и для расчета операционной скорости получим:
RSBS : Прочитанные разделяемые блоки в секунду.
DSBS : "Загрязнённые" разделяемые блоки в секунду.
WSBS : Записанные разделяемые блоки в секунду.
RLBS : Прочитанные локальные блоки в секунду.
DLBS : "Загрязнённые" локальные блоки в секунду.
WLBS : Записанные локальные блоки в секунду.
RTBS : Прочитанные временные блоки в секунду.
WSBS: Записанные временные блоки в секунду.
Аналогично, для получения значения используем модуль вектора ( RSBS , DSBS , WSBS , RLBS , DLBS , WLBS , RTBS , WSBS ).
Полученное значение и будет объемной скоростью.
Расчет метрики "производительность СУБД"
Отношение операционной скорости к объемной скорости и будет считаться производительностью СУБД(CPI).
Временной/исторический анализ производительности
Задача анализа производительности СУБД сводится к анализу ряда, сформированного как значения дискретной функции CPI(t) , для значений t от начала до окончания анализируемого периода .
Например: Корреляционный анализ для определения причин деградации производительности СУБД / Хабр (habr.com)
Для сглаживания графика и исключения выбросов используется медианное сглаживание. Чуть подробнее: Вопрос о скользящей средней и медиане / Хабр (habr.com)
Параметрическая оптимизация производительности
Задача по оптимизации производительности СУБД сводится к задаче оптимизации дискретной функции CPI(t) при изменении исследуемого набора конфигурационных параметров СУБД .
Задача - определить комбинацию параметров дающих наибольший прирост производительности .
На текущий момент, первое, что сразу приходит в голову - использовать метод покоординатного спуска (в данном случае - подъёма )
https://habr.com/ru/posts/848496/
Для анализа результатов каждой итерации применяется Статистический анализ результатов benchmark PostgreSQL / Хабр (habr.com) .
Примечание
В настоящее время в стадии сбора данных несколько экспериментов по параметрической оптимизации. Результаты будут опубликованы после окончания и анализа.
