Корреляционный анализ для решения инцидентов производительности СУБД
Данная статья должна была появится раньше, чем опубликованная вчера https://habr.com/p/827156/ , поскольку планируемые методы анализа производительности отдельного запроса являются частным случаем решения общей задачи — анализ производительности СУБД.
Вводная часть.
Известное базовое физическое понятие:
Производительностью называется количество работы, которое выполнено за какую-либо единицу времени.
Перефразируя данное определение для СУБД, введем понятие производительность для СУБД:
Производительностью СУБД называется количество объемов информации, обработанных за единицу времени.
Единицей информации СУБД будем считать страницу буферного кэша СУБД. СУБД в процессе работы читает, записывает и изменяет страницы в буферном кэше. Таким образом производительностью СУБД будем считать модуль вектора N размерности (n1, n2, n3) , где:
n1 — количество прочитанных блоков в секунду;
n2 — количество записанных блоков в секунду;
n3 — количество измененных блоков в секунду;
Также добавим в вектор еще 2 размерности: QPS (количество завершенных запросов в секунду) , TPS (количество зафиксированных транзакций в секунду).
По отдельности QPS и TPS не могут являться метриками производительность , потому, что не отображают объем обработанной информации , а служат лишь индикаторами работоспособности СУБД. Самая простая аналогия — тахометр в автомобиле. Результирующая мощность используемая автомобилем зависит, но не определяется только оборотами двигателя.
Как было показано ранее https://habr.com/ru/posts/827260/ , метрика «Время отклика СУБД» — не является индикатором производительности СУБД и не используется при анализе инцидентов.
Итак — метрика производительности СУБД (далее — CPI) рассчитывается как модуль вектора (n1, n2, n3, n4, n5) и будет использована для мониторинга и определения инцидентов производительности СУБД .
Использование метрики для мониторинга производительности СУБД
Простейшим скриптом с помощью cron, на сервере СУБД регулярно , рассчитывается метрика CPI, сохраняется в сервисной таблице и передается для мониторинга. Для сглаживания шума и выбросов данные для мониторинга сглаживаются.
Для отрисовки графиков используются медианное сглаживание по промежуткам 10 минут и 1 час.
В результате получается графическая картина состояния производительности СУБД:
Нормальная работа СУБД : cиний график — короткая скользящая, красный — долгая скользящая.
Пример решения инцидента деградации производительности СУБД
Аномалия «сдвиг» на графике мониторинга производительности СУБД
Реальная деградация производительности СУБД
Задача — установить причину падения производительности СУБД.
Шаг 1 - Уточнить временные точки инцидента
На графике мониторинга практически невозможно определить точное время начала инцидента. Для этого используются данные по скользящим загруженным в Excel, для наглядности .
Короткая — длинная скользящая
11:10 — 12:58 — Нормальная производительности
12:58 — 13:08 — Инцидент деградации производительности
13:08 — 14:20 — Производительности деградировала — есть проблема .
Шаг 2 - Подтверждение наличия деградации производительности
Необходимо исключить причину снижения производительности СУБД в силу снижения нагрузки на СУБД. Или другими словами — проверить , что снижение количества активных сессий не привело к снижению производительности (это не инцидент). А вот увеличение количества активных (а значить и сессий не только выполняющих запрос, но и ожидающих освобождение какого либо ресурса) сессий и снижение объемов обработанной информации за единицу времени это явный признак наличия проблемы.
Рассчитав коэффициент корреляции между значениями метрики CPI и сглаженными значениями количеств активных сессий (Active connections) обнаруживается:
11:10 — 12:58 — Нормальная производительности : Слабая прямая корреляция между значениями CPI и Active connections
12:58 — 13:08 — Инцидент деградации производительности: Сильная обратная корреляция между значениями CPI и Active connections
13:08 — 14:20 — Производительности деградировала: Очень слабая обратная корреляция между значениями CPI и Active connections
Гипотеза — увеличение количеств ожиданий СУБД в период 12:58 — 13:08, привело к инциденту производительности СУБД .
Шаг 3 - Установление корреляции между событиями ожидания и падением производительности СУБД
Рассчитываем коэффициенты корреляции между событиями ожидания и метрикой CPI.
Статистика по количеству событий ожидания, отсортированная по коэффициенту корреляции между количество событий ожидания и производительностью
Очень важный результат расчета коэффициента корреляции — количество событий ожидания не коррелирует с производительностью СУБД.
Гипотеза — наибольшее влияние на производительность СУБД оказывают события ожидания с наибольшим отрицательным значением коэффициента корреляции.
Другими словами , если анализировать графики мониторинга ожиданий или отчеты по времени ожидания то в топе будут события ожидания некоррелированные с падением производительности.
Шаг 4 - определение активных сессий оказывающих наибольшее отрицательное влияние на производительность СУБД.
Далее уже вопрос , чисто технический — любым доступным способом получаем выборку из истории значений системного представления pg_stat_activity и обращаем особое внимание на сессии с wait_event_type = 'Lock' и wait_event = 'transactionid'.
Данные сессии скорее всего и будут причиной деградации производительности .
В данном случае — причина была в использовании запросов select 1 * from *** limit * for update .
Итог
Использование метрики производительности СУБД позволяет корректно оценивать состояние СУБД .
Использование корреляционного анализа позволяет резко сузить круг гипотез при поиске причин снижения производительности СУБД.
