Размышления о мониторинге производительности отдельного SQL запроса

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

Но.

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

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

  2. Характер, объем и статистическая картина данных очень изменчива .

  3. Влияние инфраструктуры в общем случае - непредсказуемо.

  4. Входные данные запросов меняются в самых широких пределах.

  5. Изменить код запроса нет никакой возможности, как минимум - очень затруднено .

  6. Сопровождение системы со стороны разработчиков как правило уже отсутствует.

И это порождает существенные проблемы:

1) А как определить , что производительность конкретного запроса деградировала ?

2) Что является метрикой производительности запроса ? Максимальное время , среднее время , минимальное , стандартная ошибка ?

3) Как оценить производительность запроса на разных входных данных ? В одном случае запрос обрабатывает X строк и выполняется за время x, в другом случае запрос отрабатывает Y строк и выполняется за время y. Можно ли сказать о деградации производительности выполнения (y > x) , если Y существенно больше X ?

4) Как оценить производительность запроса при разной нагрузке на инфраструктуру и информационную систему.

Таким образом , проблему можно сформулировать примерно так :

  1. Можно собрать историю показателей выполнения запроса(группы запросов) за сколь угодно необходимый период времени. Инструментов более чем достаточно.

  2. Как проанализировать собранные данные ?

  3. Какие ожидания от результата анализа?

Источник: https://habr.com/ru/articles/827156/


Интересные статьи

Интересные статьи

Всем привет! Меня зовут Максим Еремин, я занимаюсь развитием платформенных продуктов в beeline cloud. В этой статье поговорим про контейнерную разработку в облаках, рассмотрим, в каких реалиях живут о...
Привет! Я работаю в компании Bercut, мы более 20 лет занимается разработкой и поддержкой ПО для операторов сотовой и фиксированной связи. Прошел путь от инженера в отделе сопровождения до менеджера пр...
Собрались как-то на QA-митапе эксперты СберМаркета и Skyeng, где говорили о мобильном тестировании, а поделиться материалами в блоге забыли. Исправляемся! Для всех причастных к мобильным приложениям с...
Продолжаем открывать для публичного доступа новый функционал нашего сервиса анализа планов выполнения запросов в PostgreSQL explain.tensor.ru. Сегодня мы научимся определять больные м...
Привет, дорогой хабрянин и другой читающий сей рецепт вкусного и здорового мониторинга! Мое имя — Михаил Андрианов и работаю я Тех.Директором в компании Emarsys уже целых 7 лет. Мы часто ...