Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
0 просмотренных постов скрыто

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

Как известно, существует всего два метода для решения задач:

Метод анализа или метод дедукции, или от общего к частному.

Метод синтеза или метод индукции, или от частного к общему.

Применительно к оптимизации производительности СУБД .
Анализ - поиск причин , влияющих на снижение производительности СУБД.
Синтез - оптимизация SQL запросов с целью снижения стоимости плана выполнения . Изменение конфигурационных параметров СУБД.

Пример аналитического метода :
Корреляционный анализ для определения причин деградации производительности СУБД PostgreSQL

Пример синтетического метода :
Как поймать и обезвредить проблемные запросы в PostgreSQL

Проблема аналитического метода : сложность и недостаточная проработка методологий - отсутствие однозначного определения понятия "производительность" .

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

Общая проблема : отсутствие строгой методики оценки результатов проведённых изменений .

[моё] Субд Postgresql Производительность Текст
0

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий⁠⁠

Взято с основного технического канала Postgres DBA

Начало и общее описание

PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .

Задача

Определение ожидания СУБД, оказывающего наибольшее влияние на производительность СУБД .

Эксперимент

Нагрузочное тестирование с использованием инструментария pg_stat_tester (Сценарий 2 : OLTP).

Анализируемые данные - коэффициент корреляции между операционной скоростью и ожиданиями СУБД .

Результаты эксперимента

Коэффициент корреляции между операционной скоростью и количеством ожиданий(все ожидания) .

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий Субд, Postgresql, Мониторинг, Производительность, Статистика, Анализ данных, Длиннопост

Ось Y - коэффициент корреляции(все ожидания). Ось X - точка наблюдения.

Вполне ожидаемый результат - с ростом нагрузки коэффициент растет по модулю . Т.е. чем больше ожиданий, тем ниже операционная скорость.

Коэффициент корреляции между операционной скоростью и ожиданиями типа "Lock".

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий Субд, Postgresql, Мониторинг, Производительность, Статистика, Анализ данных, Длиннопост

Ось Y - коэффициент корреляции(ожидания "Lock") . Ось X - точка наблюдения.

Коэффициент корреляции между операционной скоростью и ожиданиями типа "LWLock".

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий Субд, Postgresql, Мониторинг, Производительность, Статистика, Анализ данных, Длиннопост

Ось Y - коэффициент корреляции (ожидания "LWLock"). Ось X - точка наблюдения.

Корреляционный анализ

Графический анализ.

График коэффициента корреляции по ожиданию "Lock" более ближе к графику по ожиданиям , чем график коэффициента корреляции по ожиданию "LWLock" .

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий Субд, Postgresql, Мониторинг, Производительность, Статистика, Анализ данных, Длиннопост

Ось Y - все ожидания(синий), ожидания "Lock"(красный). Ось X - точка наблюдения.

PG_HAZEL - статистический анализ производительности СУБД : корреляция ожиданий Субд, Postgresql, Мониторинг, Производительность, Статистика, Анализ данных, Длиннопост

Ось Y - все ожидания(синий), ожидания "LWLock"(красный). Ось X - точка наблюдения.

Статистический анализ

Значение стандартного отклонения разницы значений по всем ожиданиями и ожиданиям "Lock" = 0,08560839

Значение стандартного отклонения разницы значений по всем ожиданиями и ожиданиям "LWLock" = 0,339815

Значение стандартного отклонения для ожидания "Lock" ниже значения стандартного отклонения для ожидания "LWLock".

Итог

Для данного сценария нагрузки - ожидания типа "Lock" оказывают существенно большее влияние на снижение производительности, по сравнению с ожиданиями типа "LWLock".

Показать полностью 5
[моё] Субд Postgresql Мониторинг Производительность Статистика Анализ данных Длиннопост
0
0

Оперативно-тактический комплекс анализа производительности СУБД PostgreSQL "PG_HAZEL" - общая схема⁠⁠

Взято с основного технического канала Postgres DBA

Оперативно-тактический комплекс анализа производительности СУБД PostgreSQL "PG_HAZEL" - общая схема Субд, Postgresql, Мониторинг, Производительность

Общая структурная схема потоков данных

На текущий момент - 756КБ исходников на bash и PL/pgSQL .

Показать полностью 1
[моё] Субд Postgresql Мониторинг Производительность
0

Гипотеза о пользе benchmark⁠⁠

Имеется SQL запрос используемый , используемый в качестве бенчмарка.
Идея очень простая - среднее(медианное) время выполнения запроса является показателем пропускной способности СУБД в целом.

Гипотеза - увеличение benchmark кластера 📈при нулевом значении ожиданий - свидетельствует о нехватке вычислительной мощности для СУБД. Или другими словами - пропускная способность СУБД не соответствует характеру нагрузки.

При проведении нагрузочного тестирования хорошо видно, что после определённого значения нагрузки на СУБД (количество сессий pgbench), среднее время бенчмарк увеличивается . Т.е. если гипотеза подтвердится , то можно будет использовать бенчмарк для оценки пропускной способности СУБД.

[моё] Postgresql Субд Мониторинг Производительность Тестирование Текст
2

PG_HAZEL - тактический уровень анализа метрик производительности(пример)⁠⁠

Взято с основного технического канала Postgres DBA

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .

Продолжение : PG_HAZEL - оперативный уровень анализа метрик производительности.

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

Задачи по анализу производительности СУБД решаемые на тактическом уровне:

  1. Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?

  2. Какой/какие SQL запросы оказывают наибольшее влияние на снижение производительности ?

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

Поэтому будут рассмотрены лишь общие методики тактического анализа и связь между метриками производительности СУБД .

Производительность СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - комплексный индикатор производительности СУБД

Таким образом из графика можно сделать следующий вывод: наибольшее влияние на производительность кластера оказывает нагрузка в ходе нагрузочного тестирования при 33, 58 и 84 клиентских сессий pgbench.

Операционная скорость СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - операционная скорость СУБД

Benchmark СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - медианное время работы BENCHMARK СУБД

Вывод по анализу производительности СУБД

Нагрузка на тестовую СУБД оказывает влияние на производительность СУБД в целом при количестве клиентов pgbench = 33, 58, 84.

Ожидания СУБД

PG_HAZEL - тактический уровень анализа метрик производительности(пример) Postgresql, Субд, Производительность, Мониторинг, Анализ данных, Длиннопост

Ось X - точка времени . Ось Y - отношение времени ожиданий к общему времени работы СУБД

Вывод по анализу ожиданий СУБД

При количестве клиентов pgbench = 15 ожидания резко возрастают.

Выводы

По итогам анализа метрик производительности СУБД на тактическом уровне , можно сделать следующие выводы по производительности данной СУБД при данном характере нагрузки :

  1. Штатная нагрузка на СУБД составляет 15 клиентов.

  2. После 33 клиентов начинается влияние и деградация производительности СУБД в целом.

Ближайшие планы развития оперативно-тактического комплекса "pg_hazel"

  1. Сбор и статистический анализ информации по ожиданиям клиентских SQL запросов

  2. Обновление методики корреляционного анализа Корреляционный анализ для определения причин деградации производительности СУБД PostgreSQL с использованием нового инструментария

Показать полностью 5
[моё] Postgresql Субд Производительность Мониторинг Анализ данных Длиннопост
0

PG_HAZEL - оперативный уровень анализа метрик производительности⁠⁠

Взято с основного технического канала Postgres DBA

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Начало и описание метрик производительности : PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL .

Продолжение - анализ метрик производительности в ходе нагрузочного тестирования.

Сценарий нагрузочного тестирования

Стандартный сценарий аналогичный TPC-B.

Рост нагрузки , экспоненциально : --client=клиенты

Число имитируемых клиентов, то есть число одновременных сеансов базы данных.

Продолжительность тестового прохода = 10 минут.

Максимальная нагрузка = 100 клиентов.

Общее число проходов = 20

Результаты нагрузочного тестирования

Нагрузка на СУБД

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - номер прохода. Ось Y - количество клиентов.

Операционная скорость тестового SQL запроса

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - количество клиентов. Ось Y - операционная скорость.

Медианное время работы тестового SQL запроса

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - количество клиентов. Ось Y - медианное время работы SQL запроса

Решение задач оперативного уровня

Как было определено в статье PG_HAZEL : оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL - общее описание.

В процессе анализа производительности СУБД , во-первых необходимо решить задачи оперативного уровня :

  1. В каком состоянии находится производительность СУБД в данный момент времени?

  2. Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

  3. На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

В каком состоянии находится производительность СУБД в данный момент времени? Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

Для ответа на данные вопросы достаточно проанализировать график изменения комплексного индикатора производительности в ходе нагрузочного тестирования.

PG_HAZEL - оперативный уровень анализа метрик производительности Postgresql, Субд, Производительность, Мониторинг, Статистика, Анализ данных, Длиннопост

Ось X - точка времени снятия данных . Ось Y -комплексный индикатор производительности СУБД

Ответ - функция комплексного индикатора производительности носит кусочно-непрерывный характер и уменьшается в ходе тестирования.

На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

Снижение производительности в ходе нагрузочного тестирования составило -20,1969%

Итог

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

Показать полностью 4
[моё] Postgresql Субд Производительность Мониторинг Статистика Анализ данных Длиннопост
0
3

PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL ⁠⁠

Взято с основного технического канала Postgres DBA

PG_HAZEL - оперативно-тактический комплекс мониторинга производительности СУБД PostgreSQL Postgresql, Субд, Производительность, Мониторинг, Длиннопост, Статистика, Анализ данных

Предисловие и предыстория

Рgpro_pwr — инструмент стратегического мониторинга нагрузки на базу данных, который помогает DBA выявлять самые ресурсоёмкие операции.

pg_profile и pgpro_pwr: анализируем производительность БД

Однако, в ходе решения задач сопровождения СУБД PostgreSQL возникают не только стратегические , но и оперативные и тактические задачи для которых инструмент стратегического мониторинга довольно громоздкий , что не очень удобно для быстрого решения ряда задач.

Задачи решаемые на оперативном уровне:

  1. В каком состоянии находится производительность СУБД в данный момент времени?

  2. Какая тенденция развития производительности СУБД на текущий момент или в прошлом?

  3. На сколько снизилась производительность СУБД по сравнению с выбранным промежутком из прошлого?

Задачи тактического уровня:

  1. Какая База Данных оказывает наибольшее влияние на производительность кластера в целом?

  2. Какой/какие 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-х уровнях:

  1. Уровень Кластера

  2. Уровень Базы Данных

  3. Уровень SQL запроса

Дополнительные данные pg_hazel

Как было указано ранее данные о среднем времени выполнения запроса собираемые в расширениях pg_stat_statements или pgpro_stats имеют очень серьезную проблему - среднее арифметическое не устойчиво к выбросам.

Подробнее здесь О проблеме использования mean_exec_time при анализе производительности PostgreSQL

Поэтому для корректного расчета среднего времени выполнения запроса используется не среднее арифметическое , а медиана.

К сожалению, расчет проводимый на уровне БД требует специальной подготовки для тестового запроса и дополнительных ресурсов для хранения и статистического анализа данных. Поэтому применяется не для всех SQL запросов а только для конкретных тестовых запросов:

  1. Benchmark кластера - медианное время выполнения тестового запроса для оценки производительности кластера в целом.

  2. Тестовый запрос стресс-тестирования - медианное время выполнения запроса по выбранному сценарию в ходе проведения стресс-теста(нагрузочного тестирования)СУБД.

Данные собираемый pg_hazel

1. Уровень Кластера

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания СУБД за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий СУБД в общем времени работы СУБД за период.

  12. CORRELATION - коэффициент корреляции между количеством активных сессий и операционной скоростью.

  13. BENCHMARK - медианное время выполнения тестового запроса.

  14. CPI - комплексный индикатор производительности = Операционная скорость / BENCHMARK .

2.Уровень Базы данных

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за период.

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания БД за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий БД в общем времени работы БД .

3.Уровень SQL запроса

  1. Операционная скорость - количество завершенных операций и сформированных строк за период .

  2. Объемная скорость - объем обработанных блоков распределенной/локальной/временной области за за период .

  3. Активные сессии - количество активных сессий на точку времени.

  4. Ожидания - количество событий ожидания SQL запроса за период.

  5. BUFFERPIN - количество событий ожидания bufferpin за период.

  6. EXTENSION - количество событий ожидания extension за период.

  7. IO - количество событий ожидания io за период.

  8. IPC - количество событий ожидания ipc за период.

  9. LOCK - количество событий ожидания lock за период.

  10. LWLOCK - количество событий ожидания lwlock за период.

  11. WAITING_RATIO - относительная доля ожиданий SQL запроса в общем времени работы SQL запроса .

Важное уточнение

Для данных используется медианное сглаживание - короткий период 10 минут , долгий период 60 минут.

Примеры практического применения и анализа на основе собранных данных - в следующих статьях.

Показать полностью 1
[моё] Postgresql Субд Производительность Мониторинг Длиннопост Статистика Анализ данных
0
Посты не найдены