При нагрузочном тестировании 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 так долго была абсолютно без внимания сообщества.
Просто любопытно посмотреть - как изменится реакция читателей Хабра, за прошедший год.
Всех комментаторов , я помню, все комментарии остались .
Реально интересно будет - какие комментарии получит новая работа по той же теме.
На конференции с вопросами было не очень, да вообще скучно, считай никак. Похоже никто из зрителей так и не понял о чем вообще речь какие картинки эти дети тут показывают.
В результате проведения экспериментов выявлено еще одно , очень важное условие:
Для того чтобы имелась возможность выполнить HOT update, страница должна быть в shared_buffers.
По результатам нескольких независимых исследованийА можно детали и/или ссылки на описание экспериментов? Интересует - размер БД и главное характер изменения нагрузки на СУБД в ходе тестов.
Я конечно могу ошибаться, но что-то мне подсказывает, что комментарий взят из ответа нейросети . Стиль очень похож.
Есть сравнительные испытания количесивенногл влияния на производительность изменения fillfactor ?
Ну например - насколько процентов СУБД станет быстрее при массовых update при уменьшении fillfactor на 50%?
@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 по написанию рабочих инструкций , которыми все равно никто не пользуется .
Первоапрельская статья несколько опоздала .
Но все равно - смешно, спасибо😄
Вечером после работы самое то 😉