Оперативно-тактический комплекс анализа производительности СУБД PostgreSQL "PG_HAZEL" - общая схема
Общая структурная схема потоков данных
На текущий момент - 756КБ исходников на bash и PL/pgSQL .
Показать полностью
1
0 просмотренных постов скрыто
Гипотеза о пользе benchmark
Имеется SQL запрос используемый , используемый в качестве бенчмарка.
Идея очень простая - среднее(медианное) время выполнения запроса является показателем пропускной способности СУБД в целом.
Гипотеза - увеличение benchmark кластера 📈при нулевом значении ожиданий - свидетельствует о нехватке вычислительной мощности для СУБД. Или другими словами - пропускная способность СУБД не соответствует характеру нагрузки.
При проведении нагрузочного тестирования хорошо видно, что после определённого значения нагрузки на СУБД (количество сессий pgbench), среднее время бенчмарк увеличивается . Т.е. если гипотеза подтвердится , то можно будет использовать бенчмарк для оценки пропускной способности СУБД.
PG_HAZEL - тактический уровень анализа метрик производительности(пример)
Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .
Пример тактического уровня анализа метрик производительности СУБД в ходе нагрузочного тестирования.
Задачи по анализу производительности СУБД решаемые на тактическом уровне:
Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?
Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?
Данные вопросы имеют смысл для анализа производительности СУБД в ходе эксплуатации. При проведении нагрузочного тестирования заранее известно - какая База Данных оказывает влияние на производительность СУБД в целом и какой SQL запрос оказывает наибольшее влияние на производительность кластера.
Поэтому будут рассмотрены лишь общие методики тактического анализа и связь между метриками производительности СУБД .
Производительность СУБД
Ось X - точка времени . Ось Y - комплексный индикатор производительности СУБД
Таким образом из графика можно сделать следующий вывод: наибольшее влияние на производительность кластера оказывает нагрузка в ходе нагрузочного тестирования при 33, 58 и 84 клиентских сессий pgbench.
Операционная скорость СУБД
Ось X - точка времени . Ось Y - операционная скорость СУБД
Benchmark СУБД
Ось X - точка времени . Ось Y - медианное время работы BENCHMARK СУБД
Вывод по анализу производительности СУБД
Нагрузка на тестовую СУБД оказывает влияние на производительность СУБД в целом при количестве клиентов pgbench = 33, 58, 84.
Ожидания СУБД
Ось X - точка времени . Ось Y - отношение времени ожиданий к общему времени работы СУБД
Вывод по анализу ожиданий СУБД
При количестве клиентов pgbench = 15 ожидания резко возрастают.
Выводы
По итогам анализа метрик производительности СУБД на тактическом уровне , можно сделать следующие выводы по производительности данной СУБД при данном характере нагрузки :
Штатная нагрузка на СУБД составляет 15 клиентов.
После 33 клиентов начинается влияние и деградация производительности СУБД в целом.
Ближайшие планы развития оперативно-тактического комплекса "pg_hazel"
Сбор и статистический анализ информации по ожиданиям клиентских SQL запросов
Обновление методики корреляционного анализа Корреляционный анализ для определения причин деградации производительности СУБД PostgreSQL с использованием нового инструментария
Показать полностью
5
Монитор качества воздуха
Вот на Яндекс Маркете, на Алике
Взято с телеги Интересный Маркетплейс
Подписывайтесь на наше сообщество на Пикабу
Реклама: АЛИБАБА КОМ (РУ) ИНН 7703380158
PG_HAZEL - оперативный уровень анализа метрик производительности
Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .
Продолжение - анализ метрик производительности в ходе нагрузочного тестирования.
Сценарий нагрузочного тестирования
Стандартный сценарий аналогичный TPC-B.
Рост нагрузки , экспоненциально : --client=клиенты
Число имитируемых клиентов, то есть число одновременных сеансов базы данных.
Продолжительность тестового прохода = 10 минут.
Максимальная нагрузка = 100 клиентов.
Общее число проходов = 20
Результаты нагрузочного тестирования
Нагрузка на СУБД
Ось X - номер прохода. Ось Y - количество клиентов.
Операционная скорость тестового SQL запроса
Ось X - количество клиентов. Ось Y - операционная скорость.
Медианное время работы тестового SQL запроса
Ось X - количество клиентов. Ось Y - медианное время работы SQL запроса
Решение задач оперативного уровня
Как было определено в статье PG_HAZEL : оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL - общее описание.
В процессе анализа производительности СУБД , во-первых необходимо решить задачи оперативного уровня :
В каком состоянии находится производительность СУБД в данный момент времени?
Какая тенденция развития производительности СУБД на текущий момент или в прошлом?
На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?
В каком состоянии находится производительность СУБД в данный момент времени? Какая тенденция развития производительности СУБД на текущий момент или в прошлом?
Для ответа на данные вопросы достаточно проанализировать график изменения комплексного индикатора производительности в ходе нагрузочного тестирования.
Ось X - точка времени снятия данных . Ось Y -комплексный индикатор производительности СУБД
Ответ - функция комплексного индикатора производительности носит кусочно-непрерывный характер и уменьшается в ходе тестирования.
На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?
Снижение производительности в ходе нагрузочного тестирования составило -20,1969%
Итог
Использование оперативно-тактического комплекса pg_hazel позволяет решать задачи анализа производительности СУБД на оперативном уровне.
Показать полностью
4
В России впервые сообщили о штрафе за мем о чайлдфри
Полиция Севастополя впервые в России сообщила о штрафе за мем о чайлдфри. Об этом сообщается в Telegram-канале регионального УМВД
Как рассказали в полиции, силовики мониторили «виртуальное пространство» и наткнулись на публикации жительницы города. В некоторых полицейские усмотрели проявление мизантропических взглядов, а в одной из картинок — высказывание о привлекательности отказа от деторождения в пользу беспечного образа жизни.
Судя по скриншотам, предоставленным полицией, мизантропию силовики увидели в фотографиях среднего пальца, который показывают зарубежные актеры, а пропаганду чайлдфри — в картинке с режиссером Квентином Тарантино и его «цитатой» в которой являющийся отцом двоих детей и приостановивший ради них карьеру режиссер «заявляет», будто предпочитает снимать фильмы, а не «делать детей». Также из публикации севастопольской полиции следует, что жительница города публиковала мемы еще до принятия закона о запрете пропаганды чайлдфри и не удалила их после вступления закона в силу. Суд постановил оштрафовать россиянку на 50 тысяч рублей.
Показать полностью
1
Солнце «скривилось» — человечество перекрестилось
Корональные дыры в форме глаз, носа и рта. Сравнение с мистером Бином / Оформление: PogodaSolnce
Смотря на корональные дыры, часто приходится сталкиваться с парейдолией — иллюзией, будто там, где человеческого лица нет, оно на самом деле есть. Типичнее всего земляне встречаются с явлением парейдолии, глядя на Луну. Однако и у Солнца тоже есть «выражение лица», если постараться его найти.
И сейчас оно… вроде бы, немного связано с отвращением?
А что бы на это сказал доктор Лайтман (сериал «Обмани меня»)?
Из Интернета
— Доктор, а не ***нет солнечным ветром?
— Да не должно.
Показать полностью
2
PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL
Предисловие и предыстория
Рgpro_pwr — инструмент стратегического мониторинга нагрузки на базу данных, который помогает DBA выявлять самые ресурсоёмкие операции.
Однако, в ходе решения задач сопровождения СУБД PostgreSQL возникают не только стратегические , но и оперативные и тактические задачи для которых инструмент стратегического мониторинга довольно громоздкий , что не очень удобно для быстрого решения ряда задач.
Задачи решаемые на оперативном уровне:
В каком состоянии находится производительность СУБД в данный момент времени?
Какая тенденция развития производительности СУБД на текущий момент или в прошлом?
На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?
Задачи тактического уровня:
Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?
Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?
Предпосылки создания инструмента pg_hazel.
Производительность СУБД - как рассчитать ?
В ходе предварительных исследований были проверены разные способы расчета метрики производительности СУБД .
Подробнее здесь: Производительность СУБД PostgreSQL — расчет метрики, временной анализ, параметрическая оптимизация
Однако , методы описанные в статье , к сожалению имеют свои аномалии.
Теоретически, наиболее близким к физическому определению производительность системы будет объемная скорость информации переданной клиенту , или другими словами - объем строк переданных запросом. Но к сожалению, на текущий момент , получить такую информацию - нет технической возможности. Важно - количество строк в запросе это не объем. Длина строки внутри выборки может меняться в очень широких диапазонах.
Поэтому было принято решения - непосредственный расчет производительности СУБД как физической величины - отложить на будущее, до реализации механизма получения объема данных переданных запросом.
Для решения задач анализа производительности СУБД используются индикаторы производительности СУБД и комплексный анализ изменения значений метрик производительности СУБД.
Структура pg_hazel
Источником данных являются представления расширения pgpro_stats
G.3.4.1. Представление pgpro_stats_statements
Статистика, собираемая модулем, выдаётся через представление с именем pgpro_stats_statements. Это представление содержит отдельные строки для каждой комбинации идентификатора базы данных, идентификатора пользователя и идентификатора запроса
G.3.4.2. Представление pgpro_stats_totals
Агрегированная статистика, собранная модулем, выдаётся через представление pgpro_stats_totals. Это представление содержит отдельные строки для каждого отдельного объекта БД
Данные собираются ежеминутно и агрегируются на 3-х уровнях:
Уровень Кластера
Уровень Базы Данных
Уровень SQL запроса
Дополнительные данные pg_hazel
Как было указано ранее данные о среднем времени выполнения запроса собираемые в расширениях pg_stat_statements или pgpro_stats имеют очень серьезную проблему - среднее арифметическое не устойчиво к выбросам.
Поэтому для корректного расчета среднего времени выполнения запроса используется не среднее арифметическое , а медиана.
К сожалению, расчет проводимый на уровне БД требует специальной подготовки для тестового запроса и дополнительных ресурсов для хранения и статистического анализа данных. Поэтому применяется не для всех SQL запросов а только для конкретных тестовых запросов:
Benchmark кластера - медианное время выполнения тестового запроса для оценки производительности кластера в целом.
Тестовый запрос стресс-тестирования - медианное время выполнения запроса по выбранному сценарию в ходе проведения стресс-теста(нагрузочного тестирования)СУБД.
Данные собираемый pg_hazel
1. Уровень Кластера
Операционная скорость - количество завершенных операций и сформированных строк за период .
Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.
Активные сессии - количество активных сессий на точку времени.
Ожидания - количество событий ожидания СУБД за период.
BUFFERPIN - количество событий ожидания bufferpin за период.
EXTENSION - количество событий ожидания extension за период.
IO - количество событий ожидания io за период.
IPC - количество событий ожидания ipc за период.
LOCK - количество событий ожидания lock за период.
LWLOCK - количество событий ожидания lwlock за период.
WAITING_RATIO - относительная доля ожиданий СУБД в общем времени работы СУБД за период.
CORRELATION - коэффициент корреляции между количеством активных сессий и операционной скоростью.
BENCHMARK - медианное время выполнения тестового запроса.
CPI - комплексный индикатор производительности = Операционная скорость / BENCHMARK .
2.Уровень Базы данных
Операционная скорость - количество завершенных операций и сформированных строк за период .
Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.
Активные сессии - количество активных сессий на точку времени.
Ожидания - количество событий ожидания БД за период.
BUFFERPIN - количество событий ожидания bufferpin за период.
EXTENSION - количество событий ожидания extension за период.
IO - количество событий ожидания io за период.
IPC - количество событий ожидания ipc за период.
LOCK - количество событий ожидания lock за период.
LWLOCK - количество событий ожидания lwlock за период.
WAITING_RATIO - относительная доля ожиданий БД в общем времени работы БД .
3.Уровень SQL запроса
Операционная скорость - количество завершенных операций и сформированных строк за период .
Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за за период .
Активные сессии - количество активных сессий на точку времени.
Ожидания - количество событий ожидания SQL запроса за период.
BUFFERPIN - количество событий ожидания bufferpin за период.
EXTENSION - количество событий ожидания extension за период.
IO - количество событий ожидания io за период.
IPC - количество событий ожидания ipc за период.
LOCK - количество событий ожидания lock за период.
LWLOCK - количество событий ожидания lwlock за период.
WAITING_RATIO - относительная доля ожиданий SQL запроса в общем времени работы SQL запроса .
Важное уточнение
Для данных используется медианное сглаживание - короткий период 10 минут , долгий период 60 минут.
Примеры практического применения и анализа на основе собранных данных - в следующих статьях.
Показать полностью
1