Начало Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)
Следующая серия экспериментов выполняется с использованием периода сглаживания = 1 час.
Инструмент и сценарий тестирования
Для тестирования используется стандартный инструментарий - утилита 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
Сценарий: серия также состоит из 4-х замеров статистических показателей производительности СУБД в течении 1 часа.
Производительность СУБД: рассчитывается по методике описанной в статье Корреляционный анализ для решения инцидентов производительности СУБД / Хабр (habr.com)
Для снижения влияния выбросов показателей производительности, используется медианное сглаживание с периодом 1 час.
1-й час
Статистические показатели производительности СУБД
Распределение вероятности
Корреляция между ожиданиями и производительностью СУБД
Для простоты показаны только события с коэффициентом корреляции > 0.5 и процентом наблюдений > 50%
2-й час
Статистические показатели производительности СУБД
Распределение вероятности
Корреляция между ожиданиями и производительностью СУБД
Для простоты показаны только события с коэффициентом корреляции > 0.5 и процентом наблюдений > 50%
3-й час
Статистические показатели производительности СУБД
Распределение вероятности
Корреляция между ожиданиями и производительностью СУБД
Для простоты показаны только события с коэффициентом корреляции > 0.5 и процентом наблюдений > 50%
4-й час
Статистические показатели производительности СУБД
Распределение вероятности
Корреляция между ожиданиями и производительностью СУБД
Для простоты показаны только события с коэффициентом корреляции > 0.5 и процентом наблюдений > 50%
Предварительные итоги по 2-й части
События ожидания с наибольшим по модулю коэффициентом корреляции
С большой долей уверенности можно утверждать, что дисковая подсистема оказывает существенное влияние на производительность СУБД
В целом, увеличение периода сглаживание позволяет снизить разброс итоговых значений производительности.
Выводы.
Достоверный анализ результатов нагрузочного тестирования возможен только с использование статистических методов
Увеличение периода сглаживания показаний позволяет снизить влияние внешних факторов на итоговые значения производительности.
Для получения итоговых значение производительности СУБД необходима серия тестов.
Использование коротких периодов для выполнения тестов - не позволяет получить достоверные итоговые результаты.
Дополнительные результаты статистического анализа
Статистический анализ ожиданий типа IO
|
Серверный процесс ожидает завершения операции ввода/вывода. |
Для анализа состояния подсистемы IO , было принято решение оценить дисперсию ожиданий
Дисперсия показывает разброс данных: чем меньше дисперсия, тем меньше разброс значений. В то же время чем больше дисперсия, тем больше разброс значений.
Сравнительные результаты по значениям дисперсии для событий ожидания типа IO:
Вывод
Дисковая система ведет себя крайне нестабильно .
Общий итог по проведению нагрузочного тестирования
Период сглаживания - 1 час.
Продолжительность одного прохода однотипной нагрузки - минимум 2 часа (анализ данных со 2-го часа).
Серия тестов для сбора статистических данных .
В качестве результата используется диапазон значений полученный в результате прохода при котором распределение максимально близко к симметричному и дисперсия минимальна.
Результат
Таким образом, статистические результаты 2-го часа можно принять в качестве итога данной серии тестов и считать значение метрики производительности равным 1736 , с диапазоном изменения от -7% до +2%.
При проведении повторных тестов , результат может быть уточнён.
Гипотеза.
Значения полученные при распределении близком к симметричному, существенно не отличаются .
Для подтверждения или опровержения гипотезы , тестовые испытания и статистический анализ результатов будут продолжены.
ildarz
Чегой-то не позволяет? Приложение не с медианными сглаженными откликами работает, а с теми, которые есть в реальном времени. И вот эти все сглаживания с большими периодами - классическая средняя температура по больнице, которая вообще бесполезна в ответе на вопрос "жив ли конкретный пациент".
rinace Автор
Вот результаты производительности без сглаживания.
Проход 1:
min = 184
max = 17846
Среднее = 1721
Проход 2:
min = 155
max = 3139
Среднее = 1656
Вопрос - какое значение будете использовать для оценки производительности СУБД ?
ildarz
Без ответа на вопрос "какая метрика важна для приложения" - никакую, разумеется. Если вас интересует исключительно план по валу типа "сколько транзакций БД способна переварить за сутки" - это одно, но в реальной жизни это куда более редкий сценарий, чем необходимость стабильно низкого времени отклика, а в таких случаях надо смотреть не на средний TPS, а на распределение и процент выпадения латентности из целевого диапазона. И, надеюсь, понятно, что усреднение тут никакой реальной картины не покажет.
rinace Автор
Метрика ради которой собственно все и происходит "Производительность СУБД".
Но если такой метрики нет, то "TPS"
Нет не понятно. На чем основано данное утверждение?
Я опираюсь на цифры , полученные в результате использования методов статистического анализа , доказавших свою эффективность, не одну сотню лет.
Чем вы докажете свои утверждения?
ildarz
Нет такой метрики, потому что нет никакого общепринятого единого определения, что же такое "производительность СУБД". Вот TPS - есть, время отклика - есть, время исполнения типового сложного запроса - тоже вполне может быть. А абстрактная "производительность" без указания измеримых величин - нет.
На опыте работы с ситуациями, когда "в среднем по больнице" все прекрасно, все усредненные метрики "зеленые", а бизнес-пользователи приходят с жалобами на низкую производительность.
И там у вас написано что-то совершенно оторванное от реальной практики применения СУБД. Цитирую:
Конечно же, ДА, и это знает примерно любой человек, который на практике обслуживал более-менее крупные системы со "смешанным" типом нагрузок, например, бухгалтерию. Там вот кто-то запускает большой аналитический отчет, и в техподдержку прибегает толпа взъерошенных тетенек со словами "работать невозможно, а у нас закрытие периода". И если админ будет тыкать им "средней производительностью", его быстро вразумят либо сами тетеньки, либо собственное руководство. После чего его таки обычно (хотя и не всегда) настигает понимание, что если бизнес-задача требует хорошего времени отклика, то падение оного при запуске каких-то других задач - это именно что деградация производительности, в самом прямом смысле, даже несмотря на то, что чисто технически СУБД работает "нормально" и ни в ней, ни в железе ничего не сломалось. И это повод не отказываться от ключевой метрики, а пересматривать параметры решения таким образом, чтобы вернуть ее обратно в норму - например, использовать для аналитики отдельные копии БД, увеличивать выделенные серверу СУБД ресурсы, и т.п.
Ваш же подход имеет какой-то практический смысл либо тогда, когда именно с точки зрения логики конечной задачи интересна только валовая производительность на больших периодах времени, либо когда собственно бизнес-задачи, которые обслуживает эта СУБД, вас вообще не интересуют, а вы хотите следить именно за ее чисто техническим состоянием (грубо говоря, не сломалось ли что-то в самой СУБД или нижележащем слое ОС/железа). Но и в последнем случае использовать сглаживание с периодом в час - это стрелять себе в ногу, потому что в реальной жизни деградацию обычно крайне желательно видеть за минуты, а не за часы.
rinace Автор
Есть и метрика и определение.
Производительность — это объём работы, выполняемый за единицу времени (например, за час или за день). По-другому, это скорость выполнения работы.
Работа СУБД это чтение/запись/изменение информации.
Если вы чего не не знаете, не используете из этого никак не следует, что этого нет.
Спасибо за обратную связь. Дальше, нет смысла тратить время .
ildarz
Измеряемая в каких единицах? Вы в измерениях используете примитивный тест, меряющий TPS, но при этом спорите со мной, что у вас какое-то иное определение производительности? :) Ну так примерно все вокруг делают то же самое, только паттерны нагрузки часто используют более продвинутые и в обязательном порядке к результатам TPS добавляют response time с перцентилями.
А вы поясните, в чем практический смысл вашей методики измерения и для каких реальных сценариев она применима. Пока что по откликам к вашим статьям все выглядит так, что нет смысла тратить время на вас, ибо вся суть вашего подхода выглядит как "мне не нравятся эти пиковые выбросы, это не производительность". Из двух общепринятых критических показателей производительности OLTP баз (TPS и response time) вы предлагаете использовать только один, причем еще и усреднять по большим периодам. Зачем? Какой конечной цели вы хотите добиться, ответ на какие практические вопросы получить? Мне действительно интересно.
rinace Автор
Время отклика СУБД не является индикатором состояния СУБД. Мы не используем эту метрику уже давно.
Причина - подтвержденность ошибкам 1-го и 2-го рода.
Подробнее, если интересно https://habr.com/ru/posts/827260/