Comments 39
Спасибо но уже где-то было ...https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0
Интересно, а есть рекомендации по оптимизации Microsoft SQL Server под твердотельные накопители?
M$ где-то хвалился что они сами детектируют SSD/HDD (точнее говоря измеряют метрики).
Ну здесь они душой вроде бы не кривили. Сколько я не копал, сильного изменения производительности относительно настроек по дефолту на твердотельных не заметил.
Всё равно самым узким местом была 1С, даже с учётом того, что базы размерами всего гигов по 50-100 были. Те, несколько процентов, что удалось отвоевать на конфигах mssql, всё равно терялись на уровне производительности логики вышестоящего приложения (того самого 1С).
Всё равно самым узким местом была 1С, даже с учётом того, что базы размерами всего гигов по 50-100 были. Те, несколько процентов, что удалось отвоевать на конфигах mssql, всё равно терялись на уровне производительности логики вышестоящего приложения (того самого 1С).
размер ОЗУ превышает размер базы на диске). Не очень понятно, почему сообщество postgres до сих пор использует настройки по-умолчанию, актуальные для сервера с небольшим объемом ОЗУ и дисками HDDУ вас не ОЗУ большое, у вас просто база маленькая)
Эта тема целиком раскрыта тут www.youtube.com/watch?v=aaecM4wKdhY
Не очень понятно, почему сообщество postgres до сих пор использует настройки по-умолчанию, актуальные для сервера с небольшим объемом ОЗУ и дисками HDD, а не для современных серверов. Надеюсь в скором времени это исправят.
Не исправят, потому что это не ошибка. Параметры постгреса по умолчанию установлены таким образом, чтобы база запускалась на чём угодно, включая холодильники и кофеварки. Для оптимизации производительности его нужно настраивать (сюрприз!). Поздравляю автора статьи с этим открытием.
Исправляют что-то не только из-за ошибок, но и из-за добавления удобства.
В mysql, например, раньше были примеры конфигов — my-small, my-large, my-medium, my-huge, в базе годились как и для холодильника (меньше 64мб), так и для вполне приличного вдс (1-2гб). И даже был отдельный пример для 4гб с подключением иннодб my-innodb-heavy-4G
Да, безусловно, в идеальном мире, базу данных должен настраивать администратор под конкретные задачи, блаблабла. Но в подавляющем большинстве случаев этих конфигов хватало для того, что бы на свежеподнятом вдс не напарываться на дурацкие проблемы прямо из коробки и не надо было звать дорогостоящего администратора или разбираться с этими нюансами самостоятельно.
В mysql, например, раньше были примеры конфигов — my-small, my-large, my-medium, my-huge, в базе годились как и для холодильника (меньше 64мб), так и для вполне приличного вдс (1-2гб). И даже был отдельный пример для 4гб с подключением иннодб my-innodb-heavy-4G
Да, безусловно, в идеальном мире, базу данных должен настраивать администратор под конкретные задачи, блаблабла. Но в подавляющем большинстве случаев этих конфигов хватало для того, что бы на свежеподнятом вдс не напарываться на дурацкие проблемы прямо из коробки и не надо было звать дорогостоящего администратора или разбираться с этими нюансами самостоятельно.
Безусловно, в идеальном мире можно настраивать базу только исходя из доступных ресурсов железа. Но на самом деле не менее важен профиль нагрузки, характер хранимых данных и другие вещи. Типовой конфигурации постгреса хватает для работы. Если вас перестала устраивать его производительность — значит, пора начать думать (хотя наверное правильнее было бы делать это сразу) или нанимать специалиста.
Подход не очень правильный. Автоконфигуратор от Постгреса для настройки под типовые конфигурации был бы очень полезен и приятен.
Юзкейс:
Надо поставить Постгрес вот на эту машину. Конфигурация машины известна, примерный профиль нагрузки тоже известен. Хочется в красивой менюшке потыкать кнопочки и готово. Более-менее оптимальные настройки выставлены.
Добавить возможность сохранить конфиг и применять его на другие такие же машины и вообще хорошо будет.
Юзкейс:
Надо поставить Постгрес вот на эту машину. Конфигурация машины известна, примерный профиль нагрузки тоже известен. Хочется в красивой менюшке потыкать кнопочки и готово. Более-менее оптимальные настройки выставлены.
Добавить возможность сохранить конфиг и применять его на другие такие же машины и вообще хорошо будет.
так ведь есть
pgconfigurator.cybertec.at
pgconfigurator.cybertec.at
И вот ещё один, попроще: https://pgtune.leopard.in.ua/
Вбиваете количество ОЗУ, тип дисков и вам дают минимальные изменения, которые нужно внести в конфиг под эту конфигурацию.
Тут уж больно минимальные. Оценить конкретные стоимости seq/random/cpu/memory можно только на своей железке. И какой-нить pg_tune --analyze был бы очень полезен.
А сейчас вся эта оценка перекладывается на админа, а разработчики постгре умывают лапки.
А сейчас вся эта оценка перекладывается на админа, а разработчики постгре умывают лапки.
спасибо за ссылку, pgtune меняет random_page_cost при смене типа дисков с HDD на SSD, а выше упомянутый pgconfigurator — нет.
Почему в коммерческих базах данных даже на версиях типа Express есть автонастройка параметров, тем более параметров планировщика запросов, а в СУБД, которая позиционирует себя как конкурент промышленным коммерческим СУБД — нет. Это для меня действительно сюрприз со знаком -
При том, что уже 2022-й год на дворе, AI якобы стучится в окно. А чёртов постгрес даже сам посчитать оптимальную разбивку памяти не может. Какой там AI...
Зачем СУБД заниматься несвойственной ей деятельностью? Если нужно, все эти параметры легко накатываются в момент установки каким-нибудь Ансиблом.
И, заметьте, мы не рассматриваем достаточно распространённые случаи, когда на сервере не только постгрес, но и другое ПО, которому тоже нужно оставить кусок памяти. Про это постгрес должен телепатически догадаться?
Имхо, высосанное из пальца нытьё.
И, заметьте, мы не рассматриваем достаточно распространённые случаи, когда на сервере не только постгрес, но и другое ПО, которому тоже нужно оставить кусок памяти. Про это постгрес должен телепатически догадаться?
Имхо, высосанное из пальца нытьё.
С каких пор максимальная утилизация приложением железа считается несвойственной для приложения деятельностью? Этим должны феи из страны грёз заниматься? Какой процент установок Постгрес делается Ансиблом или подобными системами, неужели близкий к 100? Откуда Ансиблу знать оптимальные параметры под конкретное железо и профиль нагрузки конкретной БД?
Как правило, БД - это сердце любого приложения, где вообще есть БД. Какого лешего на сервере с 1Тб RAM предлагать по умолчанию work_mem=4Mb? Ты что-то слышал про системные вызовы, позволяющие определить запущенные приложения и используемую ими память, не прибегая к телепатии? Если требуется сделать запас, почему нельзя это сделать указанием одного параметра (фиксированного или динамического макс. порога исползования RAM) вместо пяти? Что, ПО СУБД не способно посчитать оптимальную разбивку самостоятельно?
Имхо, комментарий человека с мышлением IT-неандертальца, не делающего хорошо свою работу, не стремящегося повысить эффективность работы, и забивающего на сигналы пользователей продукта об устаревшей конфигурации (да и моральном устаревании подхода с фиксированной конфигурацией как такового), "ведь это лишь нытьё". Так может, СУБД вообще не нужны, супермэн ты наш суровый, можно ж в csv данные хранить, зачем перенимать свойственную им функцию хранения данных ещё куда-то?
От себя добавлю, что я выставил минимальные параметры seq_page_cost = random_page_cost = 0.1, чтобы отдать приоритет данным в памяти над дисковыми
По-моему автор чего-то сильно нагородил здесь. Открываем документацию:
By default, these cost variables are based on the cost of sequential page fetches; that is, seq_page_cost is conventionally set to 1.0
Если я правильно понял, то выставив в 0.1 он просто ухудшил стоимость остальных операций в 10 раз (остальные это сканы на CPU), т.е. предпочёл использовать обращение к диску вместо использования процессора. Т.е. всё наоборот сделал, относительно заявленного.
А как это всё на AWS? Там наверное из коробки настроено?
я может придераюсь и не знаю сколько и каких данных в таблицах, но где limit в запросе? если всё же аналитику считать, то скорее всего данный запрос будет всё хуже и хуже работать с увеличением данных.
По поводу тюнинга PostgreSQL есть такой проект github.com/jfcoz/postgresqltuner
Грустно, когда люди работают с дефолтными настройкам
Грустно, что в 21 веке, когда активно развиваются и внедряются нейросети и ИИ, мы в самой технологичной отрасли вынуждены экспериментальным способом находить оптимальные настройки. Я бы понял это в 70х, 80х или даже в 90х, но не в 2020 году
Эксперимент тут ни при чём. Один раз вдумчиво прочитать 10-15 страниц официальной документации ради получения знаний, достаточных для 90% случаев настройки — довольно невысокая цена, как мне кажется… то, что люди, как обычно, начинают читать мануалы только когда всё встало колом — отдельная проблема, к постгресу отношения не имеющая.
Вы, видимо, особо не ознакамливались с документацией по Postgres, иначе бы знали, что она содержит более 3 тыс страниц, из них настройка сервера занимает 90 repo.postgrespro.ru/doc/pgpro/11.1.1/ru/postgres-A4.pdf так что не нужно про 10-15 страниц и 90% случаев. Это балабольство
Вообще, как работает процесс обучения — человек сталкивается с проблемой и ищет ее решение. Только адресный поиск информации с последующим ее закреплением может дать результат. Чтение о чем-то сферическом запишется в кратковременную память и растворится, так же, как институтские лекции по матану
И, конечно, нужно точно знать какой параметр может дать больший прирост производительности относительно других. Об этом в документации тоже не напишут
Вообще, как работает процесс обучения — человек сталкивается с проблемой и ищет ее решение. Только адресный поиск информации с последующим ее закреплением может дать результат. Чтение о чем-то сферическом запишется в кратковременную память и растворится, так же, как институтские лекции по матану
И, конечно, нужно точно знать какой параметр может дать больший прирост производительности относительно других. Об этом в документации тоже не напишут
Предлагаю не переходить на личности и не понижать уровень дискуссии необоснованными утверждениями.
Я утверждаю, что для настройки постгреса, подходящей в подавляющем количестве случаев достаточно ознакомиться и осознать не все 3000 страниц и даже не 90. Знания о параметрах, связанных с оперативной памятью, I/O, bgwriter`ом и вакуумом расположены в документации достаточно компактно. Отправной точкой для, как вы выражаетесь, «адресного поиска» может служить любой онлайн-калькулятор вроде pgtune.leopard.in.ua.
Я утверждаю, что для настройки постгреса, подходящей в подавляющем количестве случаев достаточно ознакомиться и осознать не все 3000 страниц и даже не 90. Знания о параметрах, связанных с оперативной памятью, I/O, bgwriter`ом и вакуумом расположены в документации достаточно компактно. Отправной точкой для, как вы выражаетесь, «адресного поиска» может служить любой онлайн-калькулятор вроде pgtune.leopard.in.ua.
А еще неплохо бы выучить тогда архитектуру конкретной СУБД, чтобы понимать какой параметр ОЗУ или I/O или CPU будет оказывать большее или меньшее влияние на производительность. Ставить бездумно параметры с сайтов типа pgtune.leopard.in.ua и смотреть, что получится, не понимая их сути — не самая здравая идея
Вы опять приписываете мне идеи, которых я не высказывал.
Какой параметр в каждом конкретном случае окажет большее влияние — зависит от многих критериев, в том числе не связанных с железом и никакая автонастройка все их не в состоянии объять. Разумеется, бездумно ничего ставить не нужно, именно для этого я и рекомендую обратиться к документации, а точнее тем её немногим страницам, которые как раз описывают влияние на СУБД. Pgtune я привёл в качестве примера отправной точки, раз уж вы отказываете людям в способности загуглить, что в первую очередь стоит настраивать после установки постгреса.
Какой параметр в каждом конкретном случае окажет большее влияние — зависит от многих критериев, в том числе не связанных с железом и никакая автонастройка все их не в состоянии объять. Разумеется, бездумно ничего ставить не нужно, именно для этого я и рекомендую обратиться к документации, а точнее тем её немногим страницам, которые как раз описывают влияние на СУБД. Pgtune я привёл в качестве примера отправной точки, раз уж вы отказываете людям в способности загуглить, что в первую очередь стоит настраивать после установки постгреса.
Однако почему-то в коммерческих СУБД, например в DB2, есть автонастройка параметров (AUTOMATIC) www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.admin.config.doc/doc/r0005181.html + реализованы профили настроек для различных приложений через переменную DB2_WORKLOAD, например 1C, SAP и тд
Хорошо, когда у вас база, на которой крутится нечто, с уже хорошо хорошо известными параметрами и имеющее профиль настроек. Но это скорее исключение в инновационной сфере, а поддержка всяких энтерпрайзных продуктов — это тема отдельная и не очень-то относящаяся к постгресу по понятным причинам. Он скорее не для мамонтятины, а для чего-то нового.
Ну и я, если бы был на свою голову, DBA DB2 или там Оракла какого-нибудь, не стал бы безоговорочно доверять подобным автонастройкам и профилям, хотя бы до проведения натурных испытания со сравнением с собственной конфигурацией.
Ну и я, если бы был на свою голову, DBA DB2 или там Оракла какого-нибудь, не стал бы безоговорочно доверять подобным автонастройкам и профилям, хотя бы до проведения натурных испытания со сравнением с собственной конфигурацией.
Как правило реляционные СУБД используются для широко распространённых продуктов — различных бухгалтерских, ERP систем и других систем различного финансового учёта, да и вообще, для хранения больших объемом структурированной информации. Там мало нужны инновации и свои велосипеды. Системные требования давно прописаны и конфигурации известны. И именно для таких продуктов старается сейчас позиционировать себя PGSQL, в частности компания Postgres Pro активно пиарится для 1С. Потому что инновации — это конечно хорошо, но основная маржа будет с рядового потребителя с массовым продуктом
Ну так и все распространённые рецепты для постгреса тоже давно известны, благо, комьюнити у него обширное и активное. Никакой неподъёмной задачи конфигурация базы из себя не представляет и отсутствие автонастройки и профилей не является значимым недостатком (мы же всё ещё про IT-бизнес, у них обычно с экспертизой проблем нет).
Возвращаясь к теме статьи — то, что её автор узнал для себя про веса операций (при условии, что остальные настройки у него в порядке) так поздно и это стало для него открытием — досадное недоразумение, только и всего.
Возвращаясь к теме статьи — то, что её автор узнал для себя про веса операций (при условии, что остальные настройки у него в порядке) так поздно и это стало для него открытием — досадное недоразумение, только и всего.
Sign up to leave a comment.
Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз