Ну например , как самое заметное - ни одной статьи на хабре с мая 2021 по февраль 2024 .
Или проще говоря - отсутствие реальной работы в виде созданной прибавочной стоимости и нового общественно-полезного продукта .
Все разработанные и внедрённые процессы и методики этот всё - не новое и не я придумал, это лишь использование чужого опыта и чужих решений .
Остальное в области психологии и межличностных взаимоотношений . В предыдущем комментарии отлично описано. Не буду повторяться , просто как говорится - подписываюсь под каждым словом.
Я тоже смеялся и улыбался, пока в реальности не понял, что это такое. И вот тогда, уже стало не до шуток. Теперь по поводу термина "выгорание" не шучу.
реализующего механизмы т.н. искусственного интеллекта
Вот когда механизмы , так называемого "искусственного интеллекта" пройдут хотя бы тест Тьюринга , вот только тогда , придет время для философского обдумывания ситуации.
Теме "искусственного интеллекта" лет чуть меньше , чем вообще вычислительной технике.
Пока с философской точки зрения - ничего не изменилось.
Сможете опубликовать полный набор скриптов для инициализации БД и запуска теста, чтобы воспроизвести ваши результаты?
Добавлены тексты скриптов для запуска нагрузочного и финального теста pgbench
С расчетом метрики производительности, сорри, тем еще в исследовании , как готовый продукт - не готово. Объем большой, документации нет, методология использования - в разработке и тестировании .
необходимо четко понимать, оптимальная настройка PG базы для конкретного приложения примерно на порядок сложнее.
В конце статьи специально уточнено :
Развитием идеи, возможно будет разработка инструмента адаптивной оптимизации параметров СУБД в зависимости от меняющейся нагрузки на СУБД. Но, это в относительно далекой перспективе, конечно
Дело в том, что меня всегда удивляло - откуда берутся эти цифры из так называемых best practics ? Пришла задачу на инсталляцию новой СУБД , какие значения менять по сравнению с дефолтными ? И самое главное почему ?
До текущего момента все эти цифры, скажем честно брались с потолка , просто потому, что кто то , где то прочитал и передал друзьям и коллегам и в результате например никто и не задумывается - а почему именно такое значение для например autova_max_workers ? А кто тотпроверял другие ?
Теперь будет по другому - запускается автоматический скрипт и подбирает оптимальные значения параметров для даннойинфраструктуры .
Затем будет развитие - для даннойархитектуры (нужно будет использовать кастомные скрипты в pgbench).
А задача адаптивной оптимизации параметров по текущей продуктивной нагрузке на СУБД зто перспективная тема .
8% - уже немало, поэтому идея требует дальшейшего развития
Самый ближайший результат будет - автоматизация процесса .
После инсталляции новой СУБД , запускаю скрипт , например в ночь, и получаю готовый набор измененных параметров СУБД по сравнению с дефолтными, для достижения оптимальной производительности при тестовой нагрузке при данной конфигурации инфраструктуры. Т.е. последовательно увеличиваю нагрузку и меняю параметры .
Если за основу брать снимки pg_stat_statements, то они ведь уже содержат усреднённые значения.
Значения среднего времени выполнения запроса . Не производительности СУБД.
На текущем этапе исследований анализируется производительность СУБД в целом , в не время выполнения запроса . И еще важное замечание - метрика время отклика. СУБД подвержено ошибкам первого и второго рода . например во время реальной аварии , время отклика может уменьшаться .
Дополнительное применение медианы по большим временным интервалам кажется избыточным, так как скрывает детали происходящего
Задача - анализировать тенденцию. Не причину отдельных всплесков , мне нужны тренды . Учитывая предметную область - нисходящий тренд. Понять причину резких выбросов вряд ли можно и нужно . Повторю/уточню - работы ведутся в областной среде - виртуализация шумит постоянно.
а для расследования инцидентов - будто бы и не очень.
Совсем наоборот - именно для расследования инцидентов производительности и используется. Примеры в статьях.
Корреляционный анализ для определения причин деградации производительности СУБД https://habr.com/p/849778/
pg_stat_statements не хватает процентилей времени
Пример решения есть в статье
Построение гистограммы максимального и среднего времени выполнения запросов для PostgreSQL https://habr.com/p/805813/
Принимаются ли перед началом тестов меры, чтобы состояние памяти (shared buffers, кеш ОС, грязные страницы) были полностью равны для каждого запуска?
По завершении итерации теста выполняется vacuum analyze
выключить autovacuum, чтобы не влиял непредсказуемым образом на результат
Вряд ли этот будет сделано . Причина - это никогда не будет сделано в продуктивен. Да есть рекомендация - отключать автовакуум при проведении бенчмарков . Но , я отношусь к такой рекомендации пока с большим подозрением и сомнением .
Сможете опубликовать полный набор скриптов для инициализации БД и запуска теста, чтобы воспроизвести ваши результаты?
Ок. Принято. Сделаем .
Тут категорически соглашусь - воспроизводимость результатов эксперимента это осень важно.
Конечно , прошу прощения опубликовать полный список скриптов для расчёта метрики производительности , пока не получится . Во-первых объем довольно большой , во-вторых решение еще в процессе исследования , постоянных изменений и не готово в качестве продукта . Но для данного эксперимента результатов pgbench вполне достаточно .
В статью пока не вошел анализ ожиданий (слишком большие таблицы. Наверное, может быть будет чуть позже) . В общем идея в следующем - неоптимальная настройка параметров контрольной точки, как минимум, резко увеличивает количество ожиданий IO при выполнении клиентских запросов при условии постоянной нагрузки на СУБД в ходе тестов. . Что вполне и совершенно очевидно - пропускная способность дисковой подсистемы - ограничена .
Но сейчас IT-компании удалёнку только сокращают, при чём повсеместно, это не трэнд одной страны или только бигтехов. В чём же дело?
Причина не простая , а очень простая - менеджерам нужно показать и доказать свою нужность и необходимость постоянно слоняясь по офису, осуждая в курилке флуд , и проводя постоянные собрания в комнатах для собраний.
И вся работа в найме (не знаю, как в других отраслях, но в IT уж точно) заточена просто на то, что мэнэджеры вместо выстраивания комфортных и эффективных процессов, улучшения оценки сроков выполнения задач и всего такого озабочены тем, как прогнуть, обмануть соискателя, выжать из него все соки и выпнуть, как только поломается.
Каждому , кто посчитает, что нашел новый рецепт
Помните , что менталитет японцев принципиально отличается от нашего.
Бамбук не растет
на камнях в горах одиноких.
Фудзи грустит в тишине .
Ну например , как самое заметное - ни одной статьи на хабре с мая 2021 по февраль 2024 .
Или проще говоря - отсутствие реальной работы в виде созданной прибавочной стоимости и нового общественно-полезного продукта .
Все разработанные и внедрённые процессы и методики этот всё - не новое и не я придумал, это лишь использование чужого опыта и чужих решений .
Остальное в области психологии и межличностных взаимоотношений . В предыдущем комментарии отлично описано. Не буду повторяться , просто как говорится - подписываюсь под каждым словом.
Я тоже смеялся и улыбался, пока в реальности не понял, что это такое. И вот тогда, уже стало не до шуток. Теперь по поводу термина "выгорание" не шучу.
В IT с 1987 года.
Кроме рекламы - ничего .
У меня было реальное выгорание , в прошлом году.
Хорошо, что я не последовал подобным статьям(а их в поиске большинство ), а поискал информацию на психологических и медицинских источниках.
Проблема выгорания была решена путем смены области работы - вернулся из руководителя обратно в инженеры .
Сто тысяч раз себя похвалил за решение.
На самом деле фраза выглядит сильно иначе "Общественное бытие определяет общественное сознание".
Ответ на вопрос
В первом же предложении
Вот когда механизмы , так называемого "искусственного интеллекта" пройдут хотя бы тест Тьюринга , вот только тогда , придет время для философского обдумывания ситуации.
Теме "искусственного интеллекта" лет чуть меньше , чем вообще вычислительной технике.
Пока с философской точки зрения - ничего не изменилось.
А как вы узнаете отсутствие баг в новой минорной версии ?
Например - баг с online_analyze после обновления на 15.8.1.
Основная причина обновлений - исправление обнаруженных уязвимостей.
У вас есть другая методика расчёта метрики производительности СУБД ?
Добавлены тексты скриптов для запуска нагрузочного и финального теста pgbench
С расчетом метрики производительности, сорри, тем еще в исследовании , как готовый продукт - не готово. Объем большой, документации нет, методология использования - в разработке и тестировании .
В конце статьи специально уточнено :
Развитием идеи, возможно будет разработка инструмента адаптивной оптимизации параметров СУБД в зависимости от меняющейся нагрузки на СУБД. Но, это в относительно далекой перспективе, конечноДело в том, что меня всегда удивляло - откуда берутся эти цифры из так называемых best practics ? Пришла задачу на инсталляцию новой СУБД , какие значения менять по сравнению с дефолтными ? И самое главное почему ?
До текущего момента все эти цифры, скажем честно брались с потолка , просто потому, что кто то , где то прочитал и передал друзьям и коллегам и в результате например никто и не задумывается - а почему именно такое значение для например autova_max_workers ? А кто тотпроверял другие ?
Теперь будет по другому - запускается автоматический скрипт и подбирает оптимальные значения параметров для данной инфраструктуры .
Затем будет развитие - для данной архитектуры (нужно будет использовать кастомные скрипты в pgbench).
А задача адаптивной оптимизации параметров по текущей продуктивной нагрузке на СУБД зто перспективная тема .
Наверное уже на следующий год займусь плотнее.
Самый ближайший результат будет - автоматизация процесса .
После инсталляции новой СУБД , запускаю скрипт , например в ночь, и получаю готовый набор измененных параметров СУБД по сравнению с дефолтными, для достижения оптимальной производительности при тестовой нагрузке при данной конфигурации инфраструктуры. Т.е. последовательно увеличиваю нагрузку и меняю параметры .
Тема в работе.
Значения среднего времени выполнения запроса . Не производительности СУБД.
На текущем этапе исследований анализируется производительность СУБД в целом , в не время выполнения запроса . И еще важное замечание - метрика время отклика. СУБД подвержено ошибкам первого и второго рода . например во время реальной аварии , время отклика может уменьшаться .
Задача - анализировать тенденцию. Не причину отдельных всплесков , мне нужны тренды . Учитывая предметную область - нисходящий тренд. Понять причину резких выбросов вряд ли можно и нужно . Повторю/уточню - работы ведутся в областной среде - виртуализация шумит постоянно.
Совсем наоборот - именно для расследования инцидентов производительности и используется. Примеры в статьях.
Корреляционный анализ для определения причин деградации производительности СУБД https://habr.com/p/849778/
Пример решения есть в статье
Построение гистограммы максимального и среднего времени выполнения запросов для PostgreSQL https://habr.com/p/805813/
Спасибо , за комментарий
Все работы проводятся в облачной среде.
Скорее всего да. Судя по hit ratio.
По завершении итерации теста выполняется vacuum analyze
Вряд ли этот будет сделано . Причина - это никогда не будет сделано в продуктивен. Да есть рекомендация - отключать автовакуум при проведении бенчмарков . Но , я отношусь к такой рекомендации пока с большим подозрением и сомнением .
Ок. Принято. Сделаем .
Тут категорически соглашусь - воспроизводимость результатов эксперимента это осень важно.
Конечно , прошу прощения опубликовать полный список скриптов для расчёта метрики производительности , пока не получится . Во-первых объем довольно большой , во-вторых решение еще в процессе исследования , постоянных изменений и не готово в качестве продукта . Но для данного эксперимента результатов pgbench вполне достаточно .
Спасибо , за замечание .
Исправлено .
Добрый день. Если интересно по поводу оптимизации настроек контрольной точки Этюд: использование метода покоординатного спуска для оптимизации параметров СУБД / Хабр (habr.com)
В статью пока не вошел анализ ожиданий (слишком большие таблицы. Наверное, может быть будет чуть позже) . В общем идея в следующем - неоптимальная настройка параметров контрольной точки, как минимум, резко увеличивает количество ожиданий IO при выполнении клиентских запросов при условии постоянной нагрузки на СУБД в ходе тестов. . Что вполне и совершенно очевидно - пропускная способность дисковой подсистемы - ограничена .
Причина не простая , а очень простая - менеджерам нужно показать и доказать свою нужность и необходимость постоянно слоняясь по офису, осуждая в курилке флуд , и проводя постоянные собрания в комнатах для собраний.
В САМУЮ ТОЧКУ !
Спасибо , тебе - анонимный минусатор. Ты сделал , мой день ! ;-)