Comments 13
В качестве метода оптимизации использован метод покоординатного спуска
По ссылке открывается п.19.4.5 Фоновая запись страницы Документация к Postgres Pro Enterprise 16.4.1
Не нашел там ничего про покоординатный спуск
Не туда смотрю?
Спасибо за статью.
Различие есть и 8% - уже немало, поэтому идея требует дальшейшего развития.
Подскажите, на каком железе проводите тесты? Если hdd, а не ssd, то на скорость от запуска к запуску будет влиять расположение данных на диске.
Все ли данные тестовой БД влазят в shared buffers?
Принимаются ли перед началом тестов меры, чтобы состояние памяти (shared buffers, кеш ОС, грязные страницы) были полностью равны для каждого запуска?
К отключению vaccuum есть вопрос, так как только что записанные при инициализации данные не годятся для чтения - любое чтение будет создавать грязные страницы и увеличивать нагрузку на запись. Тут на мой взгляд правильнее прогнать принудительный vacuum, но выключить autovacuum, чтобы не влиял непредсказуемым образом на результат.
Сможете опубликовать полный набор скриптов для инициализации БД и запуска теста, чтобы воспроизвести ваши результаты?
Спасибо , за комментарий
Подскажите, на каком железе проводите тесты?
Все работы проводятся в облачной среде.
Все ли данные тестовой БД влазят в shared buffer
Скорее всего да. Судя по hit ratio.
Принимаются ли перед началом тестов меры, чтобы состояние памяти (shared buffers, кеш ОС, грязные страницы) были полностью равны для каждого запуска?
По завершении итерации теста выполняется vacuum analyze
выключить autovacuum, чтобы не влиял непредсказуемым образом на результат
Вряд ли этот будет сделано . Причина - это никогда не будет сделано в продуктивен. Да есть рекомендация - отключать автовакуум при проведении бенчмарков . Но , я отношусь к такой рекомендации пока с большим подозрением и сомнением .
Сможете опубликовать полный набор скриптов для инициализации БД и запуска теста, чтобы воспроизвести ваши результаты?
Ок. Принято. Сделаем .
Тут категорически соглашусь - воспроизводимость результатов эксперимента это осень важно.
Конечно , прошу прощения опубликовать полный список скриптов для расчёта метрики производительности , пока не получится . Во-первых объем довольно большой , во-вторых решение еще в процессе исследования , постоянных изменений и не готово в качестве продукта . Но для данного эксперимента результатов pgbench вполне достаточно .
8% - уже немало, поэтому идея требует дальшейшего развития
Самый ближайший результат будет - автоматизация процесса .
После инсталляции новой СУБД , запускаю скрипт , например в ночь, и получаю готовый набор измененных параметров СУБД по сравнению с дефолтными, для достижения оптимальной производительности при тестовой нагрузке при данной конфигурации инфраструктуры. Т.е. последовательно увеличиваю нагрузку и меняю параметры .
Тема в работе.
Сможете опубликовать полный набор скриптов для инициализации БД и запуска теста, чтобы воспроизвести ваши результаты?
Добавлены тексты скриптов для запуска нагрузочного и финального теста pgbench
С расчетом метрики производительности, сорри, тем еще в исследовании , как готовый продукт - не готово. Объем большой, документации нет, методология использования - в разработке и тестировании .
:-) Статья вызывает "сложные" чувства...
С одной стороны вполне годная, как вводная/начальная, для настройки параметров PG, да и в принципе любых параметров ("железа" или OS) влияющих на производительность приложения.
С другой стороны необходимо четко понимать, оптимальная настройка PG базы для конкретного приложения примерно на порядок сложнее. Влияющих факторов очень много, один параметр настройки влияет на оптимальность настройки другого. И если вы настроили "последовательно" даже 5 параметров PG (из пары десятков) на максимальную/оптимальную производительность - это совершенно не означает что "другое" вполне определенное сочетание данных параметров не даст вам более оптимальную по производительности систему, т.е. большую производительность (или меньшее потребление ресурсов) при той же нагрузке на БД...
И при этом я уж не говорю о параметрах OS сервера БД, зачастую заметно влияющих на производительность PG базы и "приводящих" к другому "сочетанию" настроек оптимальных параметров производительности PG + настроек параметров "железа" и/или виртуальной среды для OS БД.
Вот как то так.... :-)
необходимо четко понимать, оптимальная настройка PG базы для конкретного приложения примерно на порядок сложнее.
В конце статьи специально уточнено :
Развитием идеи, возможно будет разработка инструмента адаптивной оптимизации параметров СУБД в зависимости от меняющейся нагрузки на СУБД. Но, это в относительно далекой перспективе, конечно
Дело в том, что меня всегда удивляло - откуда берутся эти цифры из так называемых best practics ? Пришла задачу на инсталляцию новой СУБД , какие значения менять по сравнению с дефолтными ? И самое главное почему ?
До текущего момента все эти цифры, скажем честно брались с потолка , просто потому, что кто то , где то прочитал и передал друзьям и коллегам и в результате например никто и не задумывается - а почему именно такое значение для например autova_max_workers ? А кто тотпроверял другие ?
Теперь будет по другому - запускается автоматический скрипт и подбирает оптимальные значения параметров для данной инфраструктуры .
Затем будет развитие - для данной архитектуры (нужно будет использовать кастомные скрипты в pgbench).
А задача адаптивной оптимизации параметров по текущей продуктивной нагрузке на СУБД зто перспективная тема .
Наверное уже на следующий год займусь плотнее.
:-) Подбирать параметры PG под нагрузку от pgbench для клиента особого смысла нет... Это только на "очень простых" прикладных приложениях можно смоделировать (с помощью pgbench) реальную нагрузку на БД клиентского профиля нагрузки приложения (что по факту так же потребует еще кучу тестов и времени), а именно работа БД под реальной нагрузкой цель оптимизации параметров БД на определенных вычислительных ресурсах...
БД инсталлируется не "просто так", а под конкретное прикладное приложение, с определенной планируемой нагрузкой (как на приложение, так и на БД). Нормальный и вменяемый разработчик прикладного ПО дает обычно первоначальные "усредненные" рекомендации по "железу", параметрам OS и БД под конкретную планируемую прикладную нагрузку для решения определенной прикладной задачи. Конечно к agile подходу решения прикладной задачи это применить практически невозможно, но тут уж "сам себе злобный буратино"...
А вот дальше... Дальше всегда наступает момент когда "меняется профиль нагрузки на БД" и/или меняются "выделенные для БД вычислительные ресурсы" и только знание "принципов работы БД" и знание "какой параметр БД и как влияет на работу БД" помогут оптимизировать ее работу.
Ознакомился с другой вашей статьей. Впечатления примерно такие же как и от этой...
"Отношение операционной скорости к объемной скорости и будет принято как производительность СУБД." - это обобщенное заключение верное.
Вот только "по факту" для процесса "оптимизации параметров конкретной БД" нужно учитывать и изменения этих "двух скоростей" по времени + поставленные (или фактические) ограничения других метрик - приложения/БД/OS/"железа"/"цены решения".
Именно по этой причине ваш вывод что контролировать/измерять/оценивать необходимо только "сглаженные данные" в общем неверен (начиная со скважности измерения и заканчивая длительностью). Все зависит от поставленных/определенных условий.
У вас есть другая методика расчёта метрики производительности СУБД ?
:-) Метрики производительности - это просто метрики... Проблема с непониманием принципов работы БД - это просто проблема.
Настройка параметров БД под определенные требования (в соответствии в контролируемыми метриками) - отдельный процесс. Требующий как получения "правильных" метрик, так и их "правильный" анализ, так и "правильное" изменение параметров влияющих на метрики так как требуется "заказчику".
Для вас оставлю ссылку которая возможно даст вам дополнительную информацию которой вам возможно не хватало по PG - https://tembo.io/blog/optimizing-memory-usage
Этюд: использование метода покоординатного спуска для оптимизации параметров СУБД