При нагрузочном тестировании PostgreSQL бенчмарки замеряют время исполнения запроса (latency). Для более объективного результата запрос выполняется большое количество раз — из этого получается некоторый набор latency. Для оценки производительности PostgreSQL на данном запросе можно использовать стандартные методы, такие как медиана или среднее, но мы предлагаем использовать более комплексный подход. Как показала практика, такие выборки часто бывают мультимодальными и состоят из различных распределений с некоторыми параметрами.
В таких случаях стандартных методов становится недостаточно, необходимо анализировать составляющие по отдельности. Результатом работы является инструмент, позволяющий автоматически проводить статистический анализ результата бенчмарка с учетом особенностей каждого набора данных, в том числе выявлять мультимодальность, количество и границы преобладания каждой моды, а также параметры распределений.
На моей памяти - первый доклад о применении математических методов в DBA PostgreSQL.
Доклад то я с интересом заслушал. Но поскольку онлайн режим - не удалось пообщаться с авторами.
Но на следующей конференции , может повезёт. Обсудим общие разработки.
Старая версия стало быть была. А так то да, весело и забавно слушать как они бубнить и мямлить начинали.
А вообще , если серьезнее - я на звонки с незнакомых номеров вообще не отвечаю . Очень редко , под настроение, когда скучно и делать нечего.
А штатно - общаюсь, только с теми кого знаю по предварительной договоренности по альтернативным каналам связи. Т.е. я отвечаю только тем кого я знаю заранее.
Иногда , подобный подход дает , неожиданные профиты , например когда странный манагер вечером в субботу до меня дозвонится не может. А штатные каналы коммуникации не знает или не хочет использовать. В результате у меня спокойный вечер субботы ;-)
По опыту участия в программе импортозамещения с 2020 года , от себя лично я давно ответил на этот вопрос - потому, что на наше время пришла мода на современные тенденции разработки и управления.
"Современный стиль разработки это " ..... А дальше можно вспомнить кучу кейсов , приколов и разочарований.
Наши деды и отцы человека первые в космос запустили , а мы имеем "у нас проблемы с импортозамещением".
Конечно у вас будут проблемы , если "&уяк, &уяк и в продакшн ".
План запроса на 2 триллиона и вопрос руководителя группы разработки - 'а почему так медленно? "
Нагрузочное тестирование чтобы закрыть этап договора и утром все висит , с приходом пользователей.
Ну и мое любимое "Вы зачем эксклюзивную блокировку используете ? Это не мы это Фреймворк такой ".
Ну, что ж времена не выбирают. Нам довелось в это время жить и работать . Будет, что вспомнить.
Искусственный интеллект так и называют, потому что он представляет собой модель реального интеллекта. Конечно, в нашей голове не происходит сложных математических вычислений так, как это происходит в ИИ, но концепция нейросетей схожа с работой наших нейронов и связей между ними.
Очень странный абзац.
1) искусственный интеллект это модель реального
2) реальный интеллект работает по другому
"концепция схожа" хм, концепция птицы и самолета схожа-в основе полета уравнение Бернулли и работы Жуковского . Однако , термина "искусственная птица" - не существует.
Сначала малыш вообще не понимает, что происходит
...
Машины обучаются практически так же. Только вместо родителей — разработчики и учёные.
Т.е. математические алгоритмы , названные "искусственным интеллектом" обладают способностью понять ?
А на чем основано это очень сильное и философское утверждение о том, что искусственный интеллект понимает результаты своей работы ?
Что значить "понимать" ? С математической точки зрения . Ведь в нейросетях кроме математики ничего нет.
Хорошо , с этим соглашусь. Пока оставим в стороне самый главный вопрос - а зачем вообще нужен тест ?
надо переделывать скрипт теста или искать причину.
Что можно переделать ? Один запрос вызывается много раз . Что тут переделывать ? И главное как ?
А причина очень простая и давно известна - влияние инфраструктуры . Я к этому очень быстро пришел просто сравнив результаты тестов в рабочее время и ночью. Ночью в облаке нагрузка принципиально другая. А на физических серверах я не тестировал. Даже если бы и были результаты , в продуктивном облаке оно не имеют смысла .
Параметром pgbench -P можно визуально смотреть
Вы действительно собрались 4-5 часов теста смотреть визуально?
Про tps уже было указано - среднее арифметическое не устойчиво к выбросам. А выбросы в облаках это обычное дело . Можно запустить один тест на одинаковых виртуалках и получить разные данные .
Я , повторюсь, давно уже не использую tps и mean_exec_time по причине неробастности.
Но самый главный вопрос , на который я жду ответа - вот нашли параметры распределения при выполнении одного запроса с одной нагрузкой - какой практический смысл этих цифр ? Что дальше ?
Как вы думаете, почму не сделали доверительные интервалы для tps, их сложно считать?
Их не сложно считать, просто они не имеют особого смысла - какая польза от доверительных интервалов , если распределение не нормальное , да еще и мультимодальное ?
Я кстати поэтому , еще и жду публикации доклада - очень интересует вопрос - а почему решили , что при постоянной нагрузке при многократном выполнении одного запроса распределение результатов может быть не нормальное и даже мультимодальное (у меня была принципиально другая начальная гипотеза) ? На конференции , вопрос из онлайна не дошёл до докладчиков .
А к pgbench с tps вообще , лично у меня, большие претензии по причине использования среднего арифметического . По крайней мере , при анализе результатов нагрузочного тестирования , уже давно ( с прошлого года) результаты pgbench не смотрю вывод pgbench. Только в качестве нагрузки.
Как и значения mean_exec_time - не использую, потому, что были аномалии влияющие на результат анализа. Среднее арифметическое :-(
Нет. Просто удивительно - как такая простая идея - использовать математическую статистику для анализа производительности СУБД PostgreSQL так долго была абсолютно без внимания сообщества.
Просто любопытно посмотреть - как изменится реакция читателей Хабра, за прошедший год.
Всех комментаторов , я помню, все комментарии остались .
Реально интересно будет - какие комментарии получит новая работа по той же теме.
На конференции с вопросами было не очень, да вообще скучно, считай никак. Похоже никто из зрителей так и не понял о чем вообще речь какие картинки эти дети тут показывают.
Ну значит ничего особенно не изменится, просто так же создаст индексы
Ну тут уж как повезет. Либо ничего не измениться, либо просадит производительности СУБД в целом .
управления производительности.
Уже в который раз встречаю это словосочетание "отдел производительности" , "управление производительности". что действительно такие бывают ? Кто и за что им интересно деньги платит? как они анализируют производительность СУБД не имея инструментов и методологии.
в пайплайн будет включено нагрузочное тестирование
Это не реально.
1) Это долго
2) требует анализа и расчетов и интерпретации результатов
Кто как. Как правило никто не делает, не анализирует и не проверяет. Просто создают индексы.
Потому, что как правило - нет инструментов для статистического анализа производительности СУБД да и вообще с PosgreSQL performance engineering пока не густо.
Да, нужен пайплайн в который это будет включено.
"Это" - что ? Что вы под этим подразумеваете ?
Я думаю статистических данных и решённых кейсов у Оракла
@santjagocorkez если это вопрос по моему комментарию , я бы и сам хотел бы узнать подробности .
Поэтому и ожидаю публикации от авторов .
А вообще , если тема математического подхода к анализу производительности интересна , лучше обсуждать не здесь, а в комментариях на дзен канале
https://dzen.ru/kznalp
Или в телеграме
https://t.me/pg_hazel
Продолжаю с нетерпением ждать публикации доклада
На моей памяти - первый доклад о применении математических методов в DBA PostgreSQL.
Доклад то я с интересом заслушал. Но поскольку онлайн режим - не удалось пообщаться с авторами.
Но на следующей конференции , может повезёт. Обсудим общие разработки.
Старая версия стало быть была. А так то да, весело и забавно слушать как они бубнить и мямлить начинали.
А вообще , если серьезнее - я на звонки с незнакомых номеров вообще не отвечаю . Очень редко , под настроение, когда скучно и делать нечего.
А штатно - общаюсь, только с теми кого знаю по предварительной договоренности по альтернативным каналам связи. Т.е. я отвечаю только тем кого я знаю заранее.
Иногда , подобный подход дает , неожиданные профиты , например когда странный манагер вечером в субботу до меня дозвонится не может. А штатные каналы коммуникации не знает или не хочет использовать. В результате у меня спокойный вечер субботы ;-)
Мне так звонили , вечером после работы, когда я на улице с собакой гулял. Видимо рассчитывали, что уставший после рабочего дня.
Этой разводке, скоро год.
Смешнее только когда по WahtsApp звонит "главный следователь МВД . Петровка 38".
Капчу "Чей Крым?" они уже научились проходить. В перезагрузку не выпадают ;-)
Только "Negro" переводится не как афроамериканец.
По опыту участия в программе импортозамещения с 2020 года , от себя лично я давно ответил на этот вопрос - потому, что на наше время пришла мода на современные тенденции разработки и управления.
"Современный стиль разработки это " ..... А дальше можно вспомнить кучу кейсов , приколов и разочарований.
Наши деды и отцы человека первые в космос запустили , а мы имеем "у нас проблемы с импортозамещением".
Конечно у вас будут проблемы , если "&уяк, &уяк и в продакшн ".
План запроса на 2 триллиона и вопрос руководителя группы разработки - 'а почему так медленно? "
Нагрузочное тестирование чтобы закрыть этап договора и утром все висит , с приходом пользователей.
Ну и мое любимое "Вы зачем эксклюзивную блокировку используете ? Это не мы это Фреймворк такой ".
Ну, что ж времена не выбирают. Нам довелось в это время жить и работать . Будет, что вспомнить.
Дальше не читал . Ибо бред.
На самом деле , я ту же уйду и никогда не вернусь в этот магазин .
Никто не любит когда за ним следят . Ничто так не раздражает как навязывание и исключение личного выбора.
Вопрос вопросов - как определяется, что ии ошибся ?
Ну и не менее сложный и нехороший вопрос - а откуда берутся большие данные ?
Очень странный абзац.
1) искусственный интеллект это модель реального
2) реальный интеллект работает по другому
"концепция схожа" хм, концепция птицы и самолета схожа-в основе полета уравнение Бернулли и работы Жуковского . Однако , термина "искусственная птица" - не существует.
Т.е. математические алгоритмы , названные "искусственным интеллектом" обладают способностью понять ?
А на чем основано это очень сильное и философское утверждение о том, что искусственный интеллект понимает результаты своей работы ?
Что значить "понимать" ? С математической точки зрения . Ведь в нейросетях кроме математики ничего нет.
Это шутка или вы всерьез ?
В общем то , ничего сложного , после года работ и исследований , конечно
https://dzen.ru/a/Z7gmHgBGAHo5m2SS
Ясно что ? Какой вывод из данного 100% искусственного теста в тепличных условиях ?
Это причина соглашусь.
Поскольку , я уже шел этим путем , я то знаю ответ .
Просто хотелось бы услышать от специалистов идущих тем же путем. Сверить направление так сказать.
Хорошо , с этим соглашусь. Пока оставим в стороне самый главный вопрос - а зачем вообще нужен тест ?
Что можно переделать ? Один запрос вызывается много раз . Что тут переделывать ? И главное как ?
А причина очень простая и давно известна - влияние инфраструктуры . Я к этому очень быстро пришел просто сравнив результаты тестов в рабочее время и ночью. Ночью в облаке нагрузка принципиально другая. А на физических серверах я не тестировал. Даже если бы и были результаты , в продуктивном облаке оно не имеют смысла .
Вы действительно собрались 4-5 часов теста смотреть визуально?
Про tps уже было указано - среднее арифметическое не устойчиво к выбросам. А выбросы в облаках это обычное дело . Можно запустить один тест на одинаковых виртуалках и получить разные данные .
Я , повторюсь, давно уже не использую tps и mean_exec_time по причине неробастности.
Но самый главный вопрос , на который я жду ответа - вот нашли параметры распределения при выполнении одного запроса с одной нагрузкой - какой практический смысл этих цифр ? Что дальше ?
Это именно тот доклад, который мне наиболее интересен :
Статистический анализ результатов бенчмарков
https://pgconf.ru/talk/2118738
Их не сложно считать, просто они не имеют особого смысла - какая польза от доверительных интервалов , если распределение не нормальное , да еще и мультимодальное ?
Я кстати поэтому , еще и жду публикации доклада - очень интересует вопрос - а почему решили , что при постоянной нагрузке при многократном выполнении одного запроса распределение результатов может быть не нормальное и даже мультимодальное (у меня была принципиально другая начальная гипотеза) ? На конференции , вопрос из онлайна не дошёл до докладчиков .
А к pgbench с tps вообще , лично у меня, большие претензии по причине использования среднего арифметического . По крайней мере , при анализе результатов нагрузочного тестирования , уже давно ( с прошлого года) результаты pgbench не смотрю вывод pgbench. Только в качестве нагрузки.
Как и значения mean_exec_time - не использую, потому, что были аномалии влияющие на результат анализа. Среднее арифметическое :-(
Минутка конспирологии.
Поэтому и занимаю место в партере, жду реакции читателей хабра на статью по теме статистического анализа бенчмарка.
Нет. Просто удивительно - как такая простая идея - использовать математическую статистику для анализа производительности СУБД PostgreSQL так долго была абсолютно без внимания сообщества.
Просто любопытно посмотреть - как изменится реакция читателей Хабра, за прошедший год.
Всех комментаторов , я помню, все комментарии остались .
Реально интересно будет - какие комментарии получит новая работа по той же теме.
На конференции с вопросами было не очень, да вообще скучно, считай никак. Похоже никто из зрителей так и не понял о чем вообще речь какие картинки эти дети тут показывают.
Странно. Вроде как налить воды и нагенерировать текст на пару страниц - тут у ботов нет конкурентов. Это давно известно.
Мы так уже второй год используем , чтобы закрыть KPI по написанию рабочих инструкций , которыми все равно никто не пользуется .
Первоапрельская статья несколько опоздала .
Но все равно - смешно, спасибо😄
Вечером после работы самое то 😉
Ну , а я в свою очередь, подожду когда на Хабре будет опубликована статья по докладу "Статистический анализ результатов бенчмарков"
Очень интересно будет сравнить комментарии с комментариями к статьям на аналогичную тему , в прошлом году.
Ну тут уж как повезет. Либо ничего не измениться, либо просадит производительности СУБД в целом .
Уже в который раз встречаю это словосочетание "отдел производительности" , "управление производительности". что действительно такие бывают ? Кто и за что им интересно деньги платит? как они анализируют производительность СУБД не имея инструментов и методологии.
Это не реально.
1) Это долго
2) требует анализа и расчетов и интерпретации результатов
Кто как. Как правило никто не делает, не анализирует и не проверяет. Просто создают индексы.
Потому, что как правило - нет инструментов для статистического анализа производительности СУБД да и вообще с PosgreSQL performance engineering пока не густо.
"Это" - что ? Что вы под этим подразумеваете ?
А при чем тут Оракл ?