Статистический анализ результатов нагрузочного тестирования СУБД в условиях облачной инфраструктуры

Предпосылки к проведению эксперимента

В ходе аудита СУБД, поступило предложение — изменить значение параметра bgwriter_lru_maxpages

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

1. Базовый сценарий: bgwriter_lru_maxpages = 100 (по умолчанию)

2. Сценарий 1 (bgwriter_lru_maxpages-50%): bgwriter_lru_maxpages = 50

3. Сценарий 2 (bgwriter_lru_maxpages+50%): bgwriter_lru_maxpages = 150

4. Сценарий 3 (bgwriter tuning): Настройка параметров по рекомендациям гуру Продолжаем выжимать максимум из PostgreSQL / Хабр (habr.com)

5. Сценарий 4(bgwriter_lru_maxpages = 1000 )

Порядок тестирования , простой и стандартный: 2 прохода каждого сценария длительностью 20 минут.

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

Самый главный вопрос — как все таки влияет , в итоге, изменение параметра bgwriter_lru_maxpages на производительность СУБД ?

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

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

Понятно, что причина столь сильного разброса значений — влияние инфраструктуры, и конкретно — размещение СУБД в облаке.

Первоначальная мысль была — в облаке в принципе невозможно провести тестирование производительности, результаты будут случайны. Облачные ресурсы очень неравномерно загружены во время работы .

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

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

В ходе проведения эксперимента был подготовлен цикл статей

Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)

В результате экспериментов была подготовлена методика проведения нагрузочного тестирования в облачной среде

Задача

Оценить производительность СУБД при постоянной нагрузке, в условиях нестабильной инфраструктуры .

Проблема

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

Гипотеза

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

Из гипотезы следует решение задачи:

1. Из серии наблюдений получить выборку, максимально удовлетворяющую критериям нормального распределения .

2. Статистические результаты найденной выборки — будут решением задачи.

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

Инструмент и сценарий тестирования

Для тестирования используется стандартный инструментарий — утилита pgbench

Параметры pgbench

• pgbench_init_param= —no-vacuum —quiet —foreign-keys —scale=100 -i test_pgbench

• pgbench_param= —progress=60 —protocol=extended —report-per-command —jobs=1 —client=100 —time=14400 test_pgbench

Сценарий тестирования: непрерывная постоянная нагрузка на СУБД, создаваемая pgbench.

Производительность СУБД: рассчитывается по методике описанной в статье Корреляционный анализ для решения инцидентов производительности СУБД / Хабр (habr.com)

Статистический анализ экспериментальных результатов

Формирование исходных выборок

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

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

медиана случайной величины: в этом случае оно определяется как число, которое делит пополам распределение. Иными словами, медианой случайной величины является такое число, что вероятность получить значение случайной величины справа от него равна вероятности получить значение слева от него (и они обе равны 1/2). Можно также сказать, что медиана является 50-м перцентилем, 0,5-квантилем или вторым квартилем выборки или распределения.

Медиана (статистика) — Википедия (wikipedia.org)

Мо́да — одно или несколько значений во множестве наблюдений, которое встречается наиболее часто

Мода (статистика) — Википедия (wikipedia.org)

Анализ выборок на нормальность распределения

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

• критерий Шапиро-Уилка,

• критерий асимметрии и эксцесса,

• критерий Дарбина,

• критерий Д’Агостино,

• критерий эксцесса,

• критерий Васичека,

• критерий Дэвида-Хартли-Пирсона,

• критерий хи-квадрат,

• критерий Андерсона-Дарлинга,

• критерий Филлибена.

Проблема в том, что пока не найдены реализации тестов на нормальность распределения в PostgreSQL. Со статистикой в PostgreSQL вообще не густо.

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

Для упрощения процесса проверки выборки на приближение к нормальному распределению была предложена следующая методика, с использованием функции PostgreSQL — normal_rand

normal_rand(int numvals, float8 mean, float8 stddev) returns setof float8

Функция normal_rand выдаёт набор случайных значений, имеющих нормальное распределение (распределение Гаусса).

Параметр numvals задаёт количество значений, которое выдаст эта функция. Параметр mean задаёт медиану нормального распределения, а stddev — стандартное отклонение.

1. По имеющимся значениям количества наблюдений, медианы и стандартного отклонения с помощью функции normal_rand формируется тестовая выборка

2. Оценка на приближение выборки к нормальной выполняется на основании полученного значения дисперсии разниц, между значениями исходной выборки и отсортированными значениями, полученными с использованием normal_rand

Можно использовать 2 подхода:

1. Сортируем выборку по значению медианы производительности. Т.к. ищем выборку в которой производительность максимальна.

2. Сортируем выборку по значению дисперсии. Т.е. ищем выборку с минимальным разбросом значений производительности.

Практическая реализация

Сценарий

Тестовое нагрузочное тестирования в течении 4-х дней.

1. 19.08.2024 14:00 — 16:00

2. 20.08.2024 11:00 — 17:00

3. 21.08.2024 10:00 — 17:00

4. 22.08.2024 10:00 — 17:00

В ходе проведения тестового нагрузочного тестирования и формирования исходного набора, было сформировано 235 выборок удовлетворяющих условию Медиана = Мода.

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

1. Максимальное значение производительности

2. Минимальная дисперсия

   

   

Проверка на соответствие нормальному распределению, формирование тестовой выборки с использованием normal_rand

1. Максимальное значение производительности

2. Минимальная дисперсия

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

Как видно из сравнения , вполне ожидаемо, исходная выборка минимальным значением дисперсии — наиболее приближена к нормальному распределению и следовательно является решением поставленной задачи.

Таким образом , по результату проведенного нагрузочного тестирования , проведенному в период:

1. 19.08.2024 14:00 — 16:00

2. 20.08.2024 11:00 — 17:00

3. 21.08.2024 10:00 — 17:00

4. 22.08.2024 10:00 — 17:00

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

1. Значение производительности: 2028

2. Нормальная нижняя граница снижения производительности: 2022

3. Нормальное снижение производительности: -1.28%

P.S. Что же касается собственно влияния на производительность изменения настроек bgwriter , это будет задачей нагрузочного тестирования проведённого с учетом новой методики.