Предпосылки к проведению эксперимента
В ходе аудита СУБД, поступило предложение - изменить значение параметра bgwriter_lru_maxpages
Для оценки характера влияния различных значений параметра на производительность СУБД, было проведено нагрузочное тестирование, с использованием стандартного средства pgbench:
Базовый сценарий: bgwriter_lru_maxpages = 100 (по умолчанию)
Сценарий 1 (bgwriter_lru_maxpages-50%): bgwriter_lru_maxpages = 50
Сценарий 2 (bgwriter_lru_maxpages+50%): bgwriter_lru_maxpages = 150
Сценарий 3 (bgwriter tuning): Настройка параметров по рекомендациям гуру Продолжаем выжимать максимум из PostgreSQL / Хабр (habr.com)
Сценарий 4(bgwriter_lru_maxpages = 1000 )
Порядок тестирования , простой и стандартный: 2 прохода каждого сценария длительностью 20 минут.
Результат вызвал некоторое недоумение и массу вопросов
Самый главный вопрос - как все таки влияет , в итоге, изменение параметра bgwriter_lru_maxpages на производительность СУБД ?
Получается , что по полученным результатам - установить характер и степень влияния, на производительность СУБД нет никакой возможности ?
Более того, самое неприятное, что если бы был сделан только один из проходов, то было бы принято ошибочное решение о необходимости изменения в продуктивной СУБД, потенциально способное оказать непредсказуемое и негативное влияние на производительность.
Понятно, что причина столь сильного разброса значений - влияние инфраструктуры, и конкретно - размещение СУБД в облаке.
Первоначальная мысль была - в облаке в принципе невозможно провести тестирование производительности, результаты будут случайны. Облачные ресурсы очень неравномерно загружены во время работы .
Но потом , чуть подумав и вспомнив о таком мощном средстве анализа данных как математическая статистика , было принято решение - заняться исследованием. Благо инструменты для сбора статистических данных по производительности СУБД разработаны и успешно применяются.
Для сбора исходных данных была проведена серия экспериментов . По результатам , после проведения статистического анализа был сделан вывод - проведение нагрузочного тестирования и получение достоверных оценочных результатов производительности СУБД, в условиях нестабильной инфраструктуры - возможно. Хотя и требует большего времени и затрат на сбор и анализ экспериментальных данных .
В ходе проведения эксперимента был подготовлен цикл статей
Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)
Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)
В результате экспериментов была подготовлена методика проведения нагрузочного тестирования в облачной среде
Задача
Оценить производительность СУБД при постоянной нагрузке, в условиях нестабильной инфраструктуры .
Проблема
На производительность СУБД влияет множество факторов со стороны инфраструктуры , которое в общем случае носит случайный характер и меняется в очень широком диапазоне.
Гипотеза
В идеальных условиях, при постоянной нагрузке, производительность СУБД должна иметь нормальное распределение.
Из гипотезы следует решение задачи:
Из серии наблюдений получить выборку, максимально удовлетворяющую критериям нормального распределения .
Статистические результаты найденной выборки - будут решением задачи.
С целью проверки гипотезы и для формирования методики проведения нагрузочного тестирования , проведена серия экспериментов
Инструмент и сценарий тестирования
Для тестирования используется стандартный инструментарий - утилита 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 — стандартное отклонение.
По имеющимся значениям количества наблюдений, медианы и стандартного отклонения с помощью функции normal_rand формируется тестовая выборка
Оценка на приближение выборки к нормальной выполняется на основании полученного значения дисперсии разниц, между значениями исходной выборки и отсортированными значениями, полученными с использованием normal_rand
Можно использовать 2 подхода:
Сортируем выборку по значению медианы производительности. Т.к. ищем выборку в которой производительность максимальна.
Сортируем выборку по значению дисперсии. Т.е. ищем выборку с минимальным разбросом значений производительности.
Практическая реализация
Сценарий
Тестовое нагрузочное тестирования в течении 4-х дней.
19.08.2024 14:00 - 16:00
20.08.2024 11:00 - 17:00
21.08.2024 10:00 - 17:00
22.08.2024 10:00 - 17:00
В ходе проведения тестового нагрузочного тестирования и формирования исходного набора, было сформировано 235 выборок удовлетворяющих условию Медиана = Мода.
Подготовка выборок для анализа соответствия нормальному распределению
Максимальное значение производительности
-
Минимальная дисперсия
Рис.5. Минимальная дисперсия производительности 
Рис.6. Распределение вероятности за период 10:32 - 11:32 21.08.2024
Проверка на соответствие нормальному распределению, формирование тестовой выборки с использованием normal_rand
Максимальное значение производительности
Минимальная дисперсия
Результат эксперимента
Как видно из сравнения , вполне ожидаемо, исходная выборка минимальным значением дисперсии - наиболее приближена к нормальному распределению и следовательно является решением поставленной задачи.
Таким образом , по результату проведенного нагрузочного тестирования , проведенному в период:
19.08.2024 14:00 - 16:00
20.08.2024 11:00 - 17:00
21.08.2024 10:00 - 17:00
22.08.2024 10:00 - 17:00
Можно считать следующие результаты производительности СУБД при данной нагрузке , в данной инфраструктуре - нормальными :
Значение производительности: 2028
Нормальная нижняя граница снижения производительности: 2022
Нормальное снижение производительности: -1.28%
P.S. Что же касается собственно влияния на производительность изменения настроек bgwriter , это будет задачей нагрузочного тестирования проведённого с учетом новой методики.
uuger
rinace Автор
Есть 2 варианта ответа
1) Просто опечатка
2) Закладка на проверку вдумчивого чтения
Спасибо. В любом случае. Хоть, кто-то читает .
uuger
На самом деле, очень интересно, спасибо за весь цикл статей
rinace Автор
Спасибо за поддержку. На самом деле, мне очень нужна обратная связь, статистику конечно изучал , когда был студентом , но это было очень давно. И к тому, же в то время сильно увлекался ассемблером и C потому и не уделял должного внимания фундаментальным знаниям которые давали бесплатно на тарелочке с голубой каемочкой. Теперь приходится вспоминать и наверстывать. С конструктивной обратной связью на Хабре конечно не очень(просмотры есть, откликов нет, минусов с формулировкой "не согласен" постоянно. Ну если не согласен , то хоть контр довод бы какой), но других технических ресурсов нет. Не в каналы телеграмма же идти ;-) Раньше был еще SQL.RU но он всё.
Может кто обладающий большими знаниями по математике и прочитает и даст реально полезный отклик.
А тема статистического анализа в DBA и вообще анализа производительности СУБД, как выяснилось очень новая. Материалов до обидного мало.
Но , как говорится - дорогу осилит идущий. Так , что тема только в начале исследования. Будет еще много чего интересного.
ildarz
Ну я вам привел контрдоводы, вы в ответ сказали, что вам недосуг какие-то там приземленные практические примеры рассматривать. И даже отказались объяснять, какую ценность сглаживание результатов измерения TPS с помощью pgbench имеет применительно к каким-либо реальным задачам. Как результат, конечной цели не видно, практической применимости тоже - так откуда бы взяться обратной связи?
rinace Автор
Вы ошиблись статьей .
Статья о статистическом анализе производительности - Корреляционный анализ для решения инцидентов производительности СУБД https://habr.com/p/827504/
Эта статья о статистическом анализе нагрузочного тестирования .
В принципе можно было бы собирать и значения TPS формируемые pgbench, но есть пара важных препятствий 1) нужно формировать таблицы вручную 2) и это более важно - TPS считается как среднее а значить сильно подвержено влиянию выбросов. Для анализа результатов использовать цифры выдаваемые pgbench очень рискованно . Особенно на больших промежутках , особенно в облаке .
ildarz
И я вам в третий раз объясняю - тот факт, что метрика производительности подвержена выбросам, совершенно не делает ее непригодной. Напротив - наличие/отсутствие выбросов является критическим фактором при оценке производительности БД, который надо не сглаживать, а, наоборот, включать в анализ.
А другая проблема вашего подхода заключается в самом вашем определении производительности, которое к реальному использованию БД отношение имеет крайне косвенное. Это ваше определение:
попросту неверно, совсем никак. Потому что производительностью называется не просто количество работы, а количество полезной работы в единицу времени (про КПД слышали ведь?). А полезной работой СУБД являются вовсе не объемы обработанной информации, а возвращение результата посланного к СУБД запроса. И если СУБД А для обработки одного и того же запроса делает втрое больше расчетов и читает/пишет втрое больше, чем СУБД Б, это совершенно не значит, что ее производительность в три раза лучше.
Соответственно, производительностью БД является скорость обработки запросов, для измерения которой и придуман параметр TPS. И вы совершенно верно заметили, что TPS - параметр сам по себе усредненный, и поэтому в единственном числе для измерения производительности не годится. Но вовсе не потому, что он "подвержен выбросам", а ровно по обратной причине - потому что он выбросы сглаживает!
И тут появляется второй параметр - время отклика, который уже оценивается по перцентилям - проценту запросов, попадающий в целевые диапазоны. А эти самые целевые диапазоны берутся из практически приемлемого для клиента БД времени отклика (будь то приложение или непосредственно человек). Вот сидит у вас на БД мобильное приложение, и для него необходимо, чтобы response time на определенные запросы был, условно, в пределах 200мс. Как ваша методика оценки "производительности" поможет понять, норм будет после миграции в облако или в первый же день процентов 5 из 100К клиентов получит вылеты и ошибки и зафлудит техподдержку, а та - вас, если вы целенаправленно (!) пытаетесь выкинуть из оценки пики? "DBA заряжает ружье для выстрела в ногу", холст, масло, Третьяковская галерея.
И вот эта комбинация TPS и Response Time и является показателем производительности БД. Не потому, что в комитете TPC заседают дураки, не знающие, как определяется и меряется производительность и не знающие про матстатистику, а потому, что именно эти показатели ближе всего к мерилу полезной работы OLTP СУБД.
Да, есть еще OLAP, где основанные на TPS методики не подходят напрямую. Там разрабатывают свои, которые, представьте себе, тоже не на pgbench и измерении объемов чтения/записи основаны. А в реальности и нагрузка зачастую вообще смешанная, и паттерны отличаются от тестовых, и в результате любые синтетические измерения могут служить только для первичной прикидки, а дальше надо мониторить целевые показатели, спроектированные под конкретную систему с конкретным окружением.
А вы вместо того, чтобы имеющиеся методики поанализировать и адаптировать под свои нужды, велосипед с квадратными колесами изобретаете.
rinace Автор
Ну вот и какой мне смысл с вами вести какое то обсуждение?
У вас кроме imho , эмоций и домыслов - ничего. У вас ни одной статьи по данной предметной области . Что вы вообще обсуждаете ? Если вы не в курсе как выбросы влияют на результаты наблюдений это ваша личная проблема.
Мне интересно обсуждение по теме статьи - статистика, распределение, статистический анализ, критерии нормального распределения , дисперсия, медиана, сглаживание и т.п.
А просто так тереть, мне не интересно. Вам интересно, есть куча других площадок - например телеграм-каналы по PostgreSQL , там примерно ваш стиль общения.
Будет ,что предметно обсудить - пожалуйста , всегда рад интересному и полезному общению, новая информация мне очень интересна.
В общем, как итог - флуд мне не интересен. Прощайте.
VVitaly
:-) Тема то актуальная, но....
"Анализ производительности СУБД" (даже без статистики) интересен "для конкретных условий работы". Условий этих десятки тысяч (начиная от характеристик "железа" х "параметры БД" х "различные профили нагрузки от приложения" х "параметры прикладного софта"). Производительность БД в отрыве от прикладного приложения может учесть только первые два фактора и не факт что максимальная производительность полученная при их оптимизации будет соответствовать максимальной прикладной производительности системы "в целом" (а именно это в большинстве случаев и интересно) + на это накладывается что бизнесу то интересно "минимизация TCO" при допустимо низком % отказа в обслуживании - а это еще более сложно рассчитать...
rinace Автор
Именно.
Теперь можно получить базовую производительность СУБД для данной инфраструктуры даже в условиях облачной инфраструктуры - если провести достаточное количество испытаний.
А если по правильному подготовить программу нагрузочного тестирования то можно получить оценки производительности СУБД во составе информационной системы. И в дальнейшем использовать эти оценки для оповещений типа "Alarm performance degradation".
Вообще тема анализа производительности СУБД была начата после постоянно повторяющихся инцидентов "у нас все висит, ничего не работает, все стало медленно". И ВСЕГДА , вот практически 100% со стороны СУБД не проводилось никаких изменений, проблема в инфраструктуре(диски, сеть, антивирусы) и приложении(непрофессиональные разработчики) .
Вот поэтому, что бы иметь четкие математически обоснованные оценки - "С СУБД аномалий нет"
Также, если использовать описываемый подход, то можно сравнить производительность СУБД в разных ИС.
В реальности у DBA нет никакой возможности влиять , анализировать и контролировать , что там разработчики на придумывают в этот раз.
Историй - полно. Моя любимая .
ИС тормозит и не показывает показателей заложенный в Техническое решение.
Выясняется - эксклюзивные блокировки pg_adviser_lock
Вопрос разработчикам - вы зачем так делаете ?
Ответ - это не мы, это фреймворк такой.
Так и мучались, через день авария , конфколы, очередное озвучивание причин.
Потом сделали рефакторинг , все работает.
Моя зона ответственности СУБД. К сожалению никакого влияния, контроля на администрирование информационной системы у DBA - нет. Как правило воопросами мониторинга информационной системы никто не занимается . В лучшем случае смотря на утилизацию CPU/RAM , начинают беспокоится когда идут сообщения от пользователей.
VVitaly
"Моя зона ответственности СУБД" - звучит примерно как "с моей стороны пули вылетели, ищите проблемы на своей стороне!" :-)
Если понятие "зона ответственности СУБД" у вас заканчивается на "установке параметров БД" - то да, "ничего не менял" = "пули вылетели, ищите не своей стороне".... :-)