Что общего у инженера по аэродинамике и инженера СУБД ? И при чем тут - производительность СУБД?

Исследования в аэродинамической трубе и исследования по нагрузочному тестированию СУБД - суть одно и тоже. Если , подойти к нагрузочному тестированию правильно , с научной точки зрения.
Исследования в аэродинамической трубе и исследования по нагрузочному тестированию СУБД - суть одно и тоже. Если , подойти к нагрузочному тестированию правильно , с научной точки зрения.

Задача

В продолжении тем

Необходимо разработать методику анализа производительности СУБД, позволяющую:

1) Получать статистически достоверные данные по результатам экспериментов по нагрузочному тестированию.

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

3) Выработать методику позволяющую сравнивать производительность СУБД разной конфигурации и в разной инфраструктуре.

Реализация

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

Ресурсы виртуальных машин, существенно отличаются:

ВМ1 : 1 CPU - очень простой тестовый запрос

current_delta = (ROUND( random ())::integer)*10 + 1 ; SELECT ROUND( random ()* 5)::integer INTO current_aid ; UPDATE pgbench_accounts SET abalance = abalance + current_delta WHERE aid = current_aid;

ВМ2: 24 CPU - стандартный запрос pgbench

current_delta = (ROUND( random ())::integer)*10 + 1 ; SELECT MIN(aid) INTO min_i FROM pgbench_accounts ; SELECT MAX(aid) INTO max_i FROM pgbench_accounts ; SELECT ROUND( random ()* max_i)::integer INTO current_aid ; UPDATE pgbench_accounts SET abalance = abalance + current_delta WHERE aid = current_aid; SELECT abalance INTO test_rec FROM pgbench_accounts WHERE aid = current_aid ; SELECT MIN(tid) INTO min_i FROM pgbench_tellers ; SELECT MAX(tid) INTO max_i FROM pgbench_tellers ; SELECT ROUND( random ()* max_i)::integer INTO current_tid ; UPDATE pgbench_tellers SET tbalance = tbalance + current_delta WHERE tid = current_tid ; SELECT MIN(bid) INTO min_i FROM pgbench_branches ; SELECT MAX(bid) INTO max_i FROM pgbench_branches ; SELECT ROUND( random ()* max_i)::integer INTO current_bid ; UPDATE pgbench_branches SET bbalance = bbalance + current_delta WHERE bid = current_bid ;

В качестве нагрузки используется стандартный инструмент pgbench. Количество одновременных подключений (параметр --connect ) растет экспоненциально .

Анализ результатов эксперимента

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

Подъёмная сила Y = операционная скорость СУБД.

Сила сопротивления X = ожидания СУБД.

Угол атаки alpha = нагрузка на СУБД.

Коэффициент Сy= отношение операционной скорости к нагрузке на СУБД.

Коэффициент Cx = отношение ожиданий к нагрузке на СУБД.

Эпюра Cy по Cx = отношение операционной скорости к ожиданиям СУБД.

Можно добавить и провести еще аналогии:

  • Ламинарное обтекание профиля - Зеленый режим работы СУБД
  • Турбулентный режим обтекания и начало срыва потока - Желтый режим работы
  • Срыв потока, переход в критичный режим - Красный режим работы

И особенно :

  • Качество профиля(Cy/Cx) - производительность(эффективность, кпд) СУБД

Нагрузка на СУБД (угол атаки alpha/характер обтекания профиля)

ВМ1 - нагрузка на СУБД
ВМ1 - нагрузка на СУБД
ВМ2 - нагрузка на СУБД
ВМ2 - нагрузка на СУБД

Средние значение нагрузки по режимом работы: ВМ1 / ВМ2

-Зеленый: 3,5556 / 42,9221

-Желтый: 5,3784 / 75,4127

-Красный: 13,0508 / 114,7273

Отношение операционной скорости к нагрузке (коэффициент Cy)

ВМ1 - коэффициент Cy
ВМ1 - коэффициент Cy
ВМ2 - коэффициент Cy
ВМ2 - коэффициент Cy

Средние значение Cy по режимам работы: ВМ1 / ВМ2

-Зеленый: 1 860,8859 / 3 088,9647

-Желтый: 658,8232 / 437,5932

-Красный: 102,2024 / 237,8892

Важное замечание - в данных условиях теста операционная скорость ВМ1 и ВМ2 одного порядка . Можно построить тестовый сценарий таким образом, что операционные скорости бы совпали. Т.е. в случае pgbench можно настроить тестовые запросы и значение параметра --connect таким образом, что TPS будет совпадать . Следует ли из факта совпадения TPS эквивалентность производительности ? Конечно же нет, с точки зрения здравого смысла. Что и доказано в результате текущих экспериментов. Т.е. еще раз - pgbench не бенчмарк. С бенчмарками СУБД , вернее с теми цифрами которые они показывают и с теми методиками как их проводят, вообще все грустно и печально(как можно ориентироваться на цифры бенчмарка в течении 10 минут !? ). Но, это уже другая история.

Отношение ожиданий СУБД к нагрузке( коэффициент Cx)

ВМ1 - коэффициент Cx
ВМ1 - коэффициент Cx
ВМ2 - коэффициент Cx
ВМ2 - коэффициент Cx

Средние значение Cx по режимам работы: ВМ1 / ВМ2

-Зеленый: 635,2222 / 131,2646

-Желтый: 1 110,8684 / 181,1227

-Красный: 2 207,7236 / 366,8534

А теперь самое интересное - качество профиля или собственно производительность СУБД = Cy / Cx

ВМ1 - отношение Cy к Cx
ВМ1 - отношение Cy к Cx
ВМ2 - отношение Cy к Cx
ВМ2 - отношение Cy к Cx

Средние значение Cy / Cx и кратная разница по режимам работы: ВМ1 / ВМ2

-Зеленый: 3,5530 / 32,1071 : 9,04

-Желтый: 0,6642 / 4,4994 : 6,77

-Красный: 0,0525 / 0,7758 : 14,77

Выводы и итоги по итогам тестирования

  • СУБД развернутая на инфраструктуре и конфигурации ВM2 в 9 раз более производительнее на штатном режиме работы СУБД
  • В самое ближайшее время буду проведены сравнительные тесты на виртуальных машинах сходной конфигурации и с использованием пользовательских тестовых БД и запросов .
Начать дискуссию