0 просмотренных постов скрыто
Корреляционный анализ ожиданий для сценариев нагрузочного тестирования СУБД PostgreSQL
Анализировать и сравнивать можно только вычисляемые сущности.
Постановка задачи
Установить характерные признаки ожиданий и результаты корреляционного анализа в зависимости от сценариев нагрузочного тестирования .
Database-1
База данных для сбора статистической информации производительности .
Database-2
Тестовая база данных для проведения нагрузочного тестирования .
Нагрузка создается пользовательским сценарием pgbench.
Рост количества подключений pgbench - экспоненциально от 6 до 111.
Сценарии нагрузочного тестирования и результаты экспериментов
Сценарий 1 - "Select Only"
Сценарий 2 - "Insert Only"
Сценарий 3 - "OLTP"
Характерные признаки сценариев нагрузочного тестирования
Сценарий 1 - "Select Only"
Сценарий характеризуется
1. Cильной корреляцией с событиями ожидания:
LWLock/LockManager: Ожидание при чтении или изменении информации о «тяжёлых» блокировках.
LWLock/ProcArray: Ожидание при обращении к общим структурам данных в рамках процесса (например, при получении снимка или чтении идентификатора транзакции в сеансе).
2. Очень низким относительной долей ожиданий: менее 1%
Сценарий 2 - "Insert Only"
Сценарий характеризуется
1. Очень сильной корреляцией с событиями ожидания:
MultiXactOffsetSLRU: Ожидание при обращении к SLRU-кешу данных о смещениях мультитранзакций.
2. Не высокой относительной долей ожиданий: 17-35%
Сценарий 3 - "OLTP"
Сценарий характеризуется
1. Очень сильной корреляцией с событиями ожидания:
Lock / transactionid: Ожидание завершения транзакции.
Lock / tuple: Ожидание при запросе блокировки для кортежа.
2. Высокой относительной долей ожиданий: 62-95%.
Показать полностью
Корреляционный анализ ожиданий СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL"
Классический анализ - разбить проблему на составные части и внимательно изучить.
Продолжение работ по теме
Постановка задачи
Анализ событий ожиданий СУБД и определение SQL запросов оказывающих наибольшее влияние на производительность БД.
Основное отличие от предыдущей методики анализа производительности.
Корреляционный анализ проводится не по СУБД в целом , а по отдельным базам данных - Database-1 , Database-2.
Статистические показатели производительности Баз Данных.
Ось X - точка наблюдения . Ось Y - операционная скорость.
Ось X - точка наблюдения . Ось Y - операционная скорость.
Анализ операционной скорости
Деградация производительности Database-2 существенно сильнее .
Ожидания
WAITING RATIO
Относительная доля(%), времени ожиданий от времени работы базы данных.
Ось X - точка наблюдения . Ось Y - относительная доля ожиданий.
Ось X - точка наблюдения . Ось Y - относительная доля ожиданий.
Анализ относительной доли ожиданий
Доля ожиданий , при работе Database-2 выше на порядки.
WAIT_EVENT_TYPE (Типы ожиданий)
Database-1
Наиболее значимый тип ожидания LWLock
Ось X - точка наблюдения . Ось Y - количество ожиданий LWLock
Database-2
Наиболее значимые типы ожиданий IO , Lock , LWLock.
Ось X - точка наблюдения . Ось Y - количество ожиданий IO
Ось X - точка наблюдения . Ось Y - количество ожиданий Lock
Ось X - точка наблюдения . Ось Y - количество ожиданий LWLock
Анализ типов ожиданий (WAIT_EVENT_TYPE)
Относительная доля ожиданий для Database-1 существенно ниже , чем по Database-2.
Типы ожиданий IO , Lock - отсутствуют при работе Database-1.
Общий корреляционный анализ ожиданий
Коэффициенты корреляции
SPEED CORR: коэффициент корреляции между количеством активных сессий к БД и операционной скоростью.BUFFERPIN CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа Bufferpin.
EXTENSION CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа Extension.
IO CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа IO.
IPC CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа IPC.
LOCK CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа Lock.
LWLOCK CORR: коэффициент корреляции между операционной скоростью и количеством ожиданий типа LWLock.
Итоги
Корреляция между активными сессиями и операционной скоростью для Database-1 очень слабая => Увеличение нагрузки на БД практически не ведет к снижению производительности БД.
Корреляция между активными сессиями и операционной скоростью для Database-2 очень сильная =>Увеличение нагрузки на БД ведет к заметному снижению производительности БД.
Для Database-1 отсутствует корреляция между операционной скоростью и ожиданиями => Снижение производительности БД не вызвано ожиданиями БД.
Для Database-2 наиболее сильная отрицательная корреляция между операционной скоростью и ожиданиями типа Lock =>Тяжелые блокировки оказывают наибольшее влияние на снижение производительности СУБД.
Корреляционный анализ ожиданий для Database-2
Для проведения корреляционного анализа используется
Корреляция между типом ожидания (wait_event_type) и событием ожидания(wait_event)
Наиболее коррелированные события ожидания(сильная корреляция):
Lock/extend: Ожидание при расширении отношения.
LWLock/BufferContent: Ожидание при обращении к странице данных в памяти.
Корреляция между событием ожидания(wait_event) и SQL запросами
SQL запросы , роли и корреляция с событиями ожиданияSQL запросы , роли и корреляция с событиями ожидания
Список SQL запросов
Результат корреляционного анализа для Database-2
Результат корреляционного анализа для Database-2
Пользовательский запрос и события ожидания оказывающий наибольшее влияние на снижение производительности БД.
select custom_test( $1 )
События ожидания, оказывающие наибольшее влияние на снижение производительности БД
Коэффициенты корреляции между событиями ожидания в БД и SQL запросе.
MultiXactOffsetSLRU: Ожидание при обращении к SLRU-кешу данных о смещениях мультитранзакций.
MultiXactGen: Ожидание при чтении или изменении общего состояния мультитранзакций.
extend: Ожидание при расширении отношения.
BufferContent: Ожидание при обращении к странице данных в памяти.
WALInsert: Ожидание при добавлении записей WAL в буфер в памяти.
ProcArray: Ожидание при обращении к общим структурам данных в рамках процесса (например, при получении снимка или чтении идентификатора транзакции в сеансе).
CheckpointerComm: Ожидание при управлении запросами fsync.
BufferMapping: Ожидание при связывании блока данных с буфером в пуле буферов.
DataFileExtend: Ожидание расширения файла данных отношения.
LockManager: Ожидание при чтении или изменении информации о «тяжёлых» блокировках.
Итог и практическое применение результатов корреляционного анализа
Для оптимизации и повышению производительности запроса "select custom_test( $1 )" необходимо выявить причины и оптимизировать работу с мультитранзакциями.
Планы на будущее и развитие
Корреляционный анализ событий ожидания СУБД в зависимости от сценариев нагрузочного тестирования.
Показать полностью
15
Мысли вслух - о раскрытии информации
Когда еще в прошлом году начал заниматься темой статистического анализа производительности СУБД , очень удивлялся - почему в интернете нет никакой информации . Куча статей , докладов о оптимизации производительности , но при этом простой вопрос "а что вы понимаете под производительностью и как считаете метрику?" - ставит докладчика в тупик(проверено практически).
Чуть поглубже погрузившись в тему , поначалу даже опасался - ах, конкуренты прочитают, реализуют, перехватят идею , реализуют и выдадут продукт на рынок .
Но, по прошествии времени , понял , что ситуация чуть другая.
1) PostgreSQL это все таки открытая система , знаниями надо делиться. Сегодня ты помог, завтра тебе помогут.
2) Тема статистического анализа производительности СУБД и вообще понятие "производительность СУБД" по большому счету никому и не интересна. На Хабре именно за эти статьи сливали карму , в комментах там в основном ламеры и тролли, за все время на Хабре было 1-2 собеседника , и полезное обсуждение. На дзене комментариев к статьям 0(ноль).
И самое главное , со стороны бизнеса тема "performance engineering" в общем , то не сильно востребована, они просто ресурсами заливают. Для коллег DBA - вся эта статистика, корреляция, дисперсия и разные медианы - тарабарщина какая то - 'а зачем это все надо ", лучше смотреть кучу графиков и лапшу клиенту вешать.
Так, что можно , не переживать - в ближайшее время конкурентов не предвидится. Хотя , с другой стороны скучно - "Ганди умер - поговорить не с кем".
Но, все таки , может по привычке , а может лень описывать долго и строго математически - не привожу детали и последовательность действий , только результаты . Т.е. в интернете описано "что" получилось в результате экспериментов , "как" этот получено , информации общем то нет. Поэтому спрашивать у языковых моделей вопросы по статистическому анализу производительности СУБД не имеет смысла - они начинают воду лить и пургу нести. Хотя прикольно , такие бюджеты и ресурсы , а на выходе пук. Кто хочет, пусть называет это "интеллектом".
Вот такие мысли , с утра , в субботу.
Показать полностью
1
Анализ результатов нагрузочного тестирования СУБД PostgreSQL с использованием разных сценариев оперативно-тактического комплекса "PG_HAZEL"
А теперь начинается самое интересно - анализ и поиск закономерностей
Выполненные сценарии нагрузочного тестирования
Результаты нагрузочного тестирования
График операционной скорости СУБД за период
Короткий период медианного сглаживания - синий график.
Долгий период медианного сглаживания - красный график.
Ось X - точка наблюдения. Ось Y - значение операционной скорости.
"OLTP"- нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL".
"SELECT ONLY" - нагрузочное тестирование СУБД PostgreSQL использованием оперативно-тактического комплекса "PG_HAZEL".
"INSERT ONLY" - нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL".
"HEAVYWEIGHT" - нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического9 комплекса "PG_HAZEL".
Ключевой момент
Значения операционной скорости после определенного роста нагрузки для сценариев "INSERT ONLY" / "HEAVYWEIGHT".
Корреляция между операционной скоростью и количество сессий в состоянии 'active'
Ось X - точка наблюдения. Ось Y - коэффициент корреляции .
"OLTP"- нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL".
"SELECT ONLY" - нагрузочное тестирование СУБД PostgreSQL использованием оперативно-тактического комплекса "PG_HAZEL".
"INSERT ONLY" - нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL".
"HEAVYWEIGHT" - нагрузочное тестирование СУБД PostgreSQL с использованием оперативно-тактического комплекса "PG_HAZEL".
Ключевой момент
График скользящей корреляции для сценариев "SELECT ONLY" / "INSERT ONLY" очень похожи.
График скользящей корреляции для сценария "HEAVYWEIGHT" в противо фазе с графиками "SELECT ONLY" / "INSERT ONLY" после определенной нагрузки.
Показать полностью
9
Сценарий "INSERT ONLY" - корреляционный анализ производительности СУБД с использованием оперативно-тактического комплекса "PG_HAZEL"
Постановка задачи
Анализ и определение причины деградации производительности СУБД за заданный период .
Сценарий нагрузки "INSERT ONLY".
Общее описание схемы и метрик производительности
Анализ метрик производительности СУБД.
График операционной скорости СУБД за период
Короткий период медианного сглаживания - синий график.
Долгий период медианного сглаживания - красный график.
Ось X - точка наблюдения. Ось Y - значение операционной скорости
Отличительная особенность сценария "INSERT ONLY" - резкий скачок операционной скорости. Скорее всего причина - изменение нагрузки на СХД виртуальной машины.
Сессии в состоянии 'active'
Ось X - точка наблюдения. Ось Y - количество активных сессий на точку времени.
Корреляция между операционной скоростью и количество сессий в состоянии 'active'
График скользящей корреляции.
Ось X - точка наблюдения. Ось Y - значение коэффициента корреляции.
Обращает на себя внимание факт непостоянного значения скользящей корреляции, близкой к косинусоиде.
График практически повторяет график скользящей корреляции для сценария "SELECT ONLY"
Сценарий "SELECT ONLY". Ось X - точка наблюдения. Ось Y - значение коэффициента корреляции.
Коэффициент корреляции между операционной скоростью и количеством активных сессий за период наблюдений = 0,868388508671336 .
Сильная положительная корреляция между операционной скоростью и нагрузкой на СУБД .
Корреляционный анализ ожиданий СУБД
Гипотеза
Для определения SQL запроса оказывающего наибольшее влияние необходимо определить запрос с наибольшим значением коэффициента корреляции между ожиданиями СУБД и ожиданиями по SQL запросу.
Результат корреляционного анализа
Нет деградации производительности СУБД за период проведения теста .
Итог
Количество ожиданий СУБД - не является признаком деградации производительности СУБД
Для сценарий "INSERT ONLY" текущая нагрузка далека от предельной.
Показать полностью
6
Корреляционный анализ производительности СУБД с использованием оперативно-тактического комплекса "PG_HAZEL" - сценарий "SELECT ONLY"
Постановка задачи
Анализ и определение причины деградации производительности СУБД за заданный период .
Сценарий нагрузки "SELECT ONLY".
Общее описание схемы и метрик производительности
Анализ метрик производительности СУБД.
График операционной скорости СУБД за период
Короткий период медианного сглаживания - синий график.
Долгий период медианного сглаживания - красный график.
Ось X - точка наблюдения. Ось Y - значение операционной скорости
Наблюдается резкое снижение с последующим переходом в горизонтальный тренд.
Сессии в состоянии 'active'
Ось X - точка наблюдения. Ось Y - количество активных сессий на точку времени.
Корреляция между операционной скоростью и количество сессий в состоянии 'active'
График скользящей корреляции.
Ось X - точка наблюдения. Ось Y - значение коэффициента корреляции.
Ключевые точки наблюдения.
1-40: положительная корреляция
41-142: отрицательная корреляция
143-179: положительная корреляция
180-197: отрицательная корреляция
Результат корреляционного анализа операционной скорости и активными сессиями :
Корреляция между операционной скоростью СУБД и нагрузкой на СУБД - непостоянна. Возможно причины снижения операционной скорости - вне СУБД.
Ожидания СУБД
Ожидания СУБД
Ось X - точка наблюдения. Ось Y - количество ожиданий
Отношение времени ожидания к общему времени работы СУБД
Ось X - точка наблюдения. Ось Y - % ожиданий
Результат анализа ожиданий СУБД:
Начиная с точки 56 - резкий рост метрик ожиданий СУБД
Количество ожиданий СУБД - очень не велико.
После точки 81 - относительная доля ожиданий снижается. Однако количество ожиданий не уменьшается , операционная скорость снижается.
Корреляционный анализ ожиданий СУБД
Гипотеза
Для определения SQL запроса оказывающего наибольшее влияние необходимо определить запрос с наибольшим значением коэффициента корреляции между ожиданиями СУБД и ожиданиями по SQL запросу.
Чуть подробнее
Результат корреляционного анализа
Результат работы сервисного скрипта
Результат корреляционного анализа
Снижение операционной скорости вызвано повышенной нагрузкой на СУБД и нехваткой CPU. Ожиданий СУБД влияющих на производительность - не выявлено.
Подтверждением нехватки ресурсов СУБД является рост значений benchmark.
Ось X - точка наблюдения. Ось Y - медианное значение тестового запроса BENCHMARK
Итог
Используя методику статистического анализа производительности СУБД можно установить предельное значение читающей нагрузки на СУБД не вызывающее деградацию производительности.
Показать полностью
8
Корреляционный анализ производительности СУБД с использованием оперативно-тактического комплекса "PG_HAZEL"
Постановка задачи
Анализ и определение причины деградации производительности СУБД за заданный период.
Общее описание схемы и метрик производительности
Анализ метрик производительности СУБД.
График операционной скорости СУБД за период
Короткий период медианного сглаживания - синий график.
Долгий период медианного сглаживания - красный график.
Ось X - точка наблюдения. Ось Y - значение операционной скорости
Как видно из графика - имеется краткосрочная и долгосрочная тенденция снижения производительности СУБД.
Сессии в состоянии 'active'
Ось X - точка наблюдения. Ось Y - количество активных сессий на точку времени.
Корреляция между операционной скоростью и количество сессий в состоянии 'active'
График скользящей корреляции.
Ось X - точка наблюдения. Ось Y - значение коэфициента корреляции.
Коэффициент корреляции между операционной скоростью и количеством активных сессий за период наблюдений = -0,993357128393598 .
Ключевые точки наблюдения.
1-19 : коэфaициент близок к 1
23 - отрицательное значение коэффициента корреляции
80 - значение коэффициента корреляции уменьшается(растет по модулю)
Общая интерпретация значений коэффициента корреляции :
Очень слабая корреляция: [0 до 0.2]
Слабая корреляция: (0.2 до 0.5].
️Средняя корреляция: (0.5 до 0.7] .
️Сильная корреляция: (0.7 до 0.9].
️Очень сильная корреляция: (0.9 до 1].
Результат корреляционного анализа операционной скорости и активными сессиями :
После точки наблюдения 23 - СУБД работает в нештатном режиме.
Очень сильная корреляция между нагрузкой на СУБД и операционной скоростью СУБД.
Ожидания СУБД
Отношение времени ожидания к общему времени работы СУБД
Ось X - точка наблюдения. Ось Y - % ожиданий
Начиная с точки 60 - относительная доля ожиданий резко увеличивается. СУБД работает в нештатном режиме.
Корреляционный анализ ожиданий СУБД
Гипотеза
Для определения SQL запроса оказывающего наибольшее влияние необходимо определить запрос с наибольшим значением коэффициента корреляции между ожиданиями СУБД и ожиданиями по SQL запросу.
Результат корреляционного анализа
Результат работы сервисного скрипта
Наибольшее влияние на снижение производительности СУБД оказывает SQL запрос: queryid = -3703375232510669542 .
Шаги корреляционного анализа
1. Корреляция между операционной скоростью и определенными типом ожиданиям
Lock = -0,991080979500333
LWLock = -0,952840750047627
IPC = -0,00747093318897355
BufferPin = 0
Extension = 0
IO = 0
Ожидания типа Lock имеет большую корреляцию по сравнению с ожиданиями типа LWLock.
Ожидания типа Lock
Ось X - точка наблюдения. Ось Y - количество ожиданий типа Lock
Ожидания типа LWLock
Ось X - точка наблюдения. Ось Y - количество ожиданий типа LWLock
2.Корреляция между типом ожидания Lock и событиями ожиданий
transactionid = 0,999996784494388
tuple = 0,989898319693633
relation = 0,884541891919045
Ожидания transactionid
Ось X - точка наблюдения. Ось Y - количество ожиданий transactionid
Ожидания tuple
Ось X - точка наблюдения. Ось Y - количество ожиданий tuple
3. Корреляция между ожиданиями transactionid и SQL запросами
queryid = -3703375232510669542
Ось Y - количество ожиданий Lock/tuple для queryid =-3703375232510669542
Итоги
Гипотеза подтверждена экспериментально для данного сценария нагрузки.
Необходимо продолжение проведение экспериментов по корреляционному анализу :
Дополнительные сценарии нагрузочного тестирования .
Анализ метрик производительности при продуктивной нагрузке на СУБД.
Показать полностью
10