Корреляционный анализ для решения инцидентов производительности СУБД

Данная статья должна была появится раньше , чем опубликованная вчера 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 час.

В результате получается графическая картина состояния производительности СУБД:

Пример решения инцидента деградации производительности СУБД

Аномалия «сдвиг» на графике мониторинга производительности СУБД

Задача — установить причину падения производительности СУБД .

Шаг 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 .

Итог

Использование метрики производительности СУБД позволяет корректно оценивать состояние СУБД .

Использование корреляционного анализа позволяет резко сузить круг гипотез при поиске причин снижения производительности СУБД.