Comments 22
s/huge_pages = try/huge_pages = on/
Не очевидно, что эта настройка что-то кардинально улучшит.
Эта конфигурилка может быть полезной для начальной настройки, но уровень статьи гораздо выше.
Ага, особенно монтирование pg_stat_tmp в tmpfs для postgresql 15+ наводит на мысли о "высочайшем" уровне статьи.
Можно было создать часть ram как блочное устройство и смонтировать туда но что бы это изменило? Или что вы имеете ввиду?
Начиная с 15 версии posgresql не использует каталог pg_stat_tmp, а хранит статистики в shared memory.
в документации обратная информация https://www.postgresql.org/docs/16/storage-file-layout.html
Именно в этом месте документацию не поправили. В отличие например от описания параметра stats_temp_directory, которая и задает расположение этого каталога.
Вот тут: https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/ хорошо описано, что там сделали с коллектором статистики, и, в частности, почему каталог pg_stat_tmp все же оставили. Кратко - для совместимости с расширениями, которые могут полагаться на наличие этого каталога.
Да вы правы, теперь процессы пишут в основную шаренную память. И в целом нагрузка на запись на pg_stat_tmp значительно уменьшилась. Но запись то всё равно есть. По поводу этого момента у нас нет чётких тестов, может уже и не стоит это делать. Но критичного в этом ничего нет на результаты тестов это не повлияет. Если у вас есть аргумент что это критически повлияло на тесты или еще на какой-то момент, с удовольствием почитаю.
Настолько высокий что прописывает с потолка взятые значения без учета текущей конфигурации железа, и всё это руками в консоли. Автор явно не знаком с минимальной автоматизацией
Про значения с потолка я промолчу, вы явно не понимаете зачем были проведены данные тесты, про автоматизацию вы видимо пропустили или не читали статью, банально "sed" уже упрощает жизнь. Что уж там говорить про парсер данных и полную автоматизацию тестирования за исключением отрисовки графиков их да я делал руками. Расскажете как будете автоматизировать?
Если вы интересуетесь вопросами ускорения программ, то могу посоветовать пересобрать PostgreSQL с Profile-Guided Optimization (PGO): https://ru.wikipedia.org/wiki/Profile-guided_optimization . Я собираю результаты применения PGO к разным приложениям (в том числе и БД) вот тут - https://github.com/zamazan4ik/awesome-pgo , с результатами для PostgreSQL можно ознакомиться здесь - https://github.com/zamazan4ik/awesome-pgo/blob/main/postrgresql_results.md .
А почему у вас на графике где 2 стоковые версии PG15 и PG16 производительность выше чем на графике где Вы сравниваете 4 версии (включая enterprise) и причем там другие цифры (у ванилы ниже) ? А потом утверждаете что энтерпрайз по tps уделала ванилу? Бред какой-то у Вас.
PG16 на SELECT only с 8 048 239 получается уделывает PG16 Enterprise, но потом вы откуда-то взяли другой график где иные цифры для PG16 ванила
Ну а последний график где только для PG16 Enterprise была проведена оптимизация performance - это вообще странное сравнение. А почему для ванилы PG16 не было сделано это же и она не была добавлена на график? Какое-то однобокое сравнение с закосом на Enterprise версию. Посыл статьи в том чтобы пропиарить Enterprise версию?
Какой мне смысл пиарить Enterprise версию? мне за это не платят к сожалению)) Здесь был упор на то что Enterprise версии показывали более лучшие результаты от сюда и тюнили самую свежую версию, мы же видим динамику от версии к версии. Можно было и все версии протестить в таком перфоманс режиме только цель была не такая, цель была показать разницу в дефолтных и тюнингованных настройках на любой из версий.
>цель была показать разницу в дефолтных и тюнингованных настройках на любой из версий.
вот только "любой" оказалась Enterprise версия
Помнится, лет 10+ назад, когда поставили задачу "развернуть 1С на Linux", сперва установил всё "в лоб", с дефолтными настройками (на DB2 и PostgreSQL) - результат оказался настолько удручающий, что чуть не решили покупать MS SQL (быстродействие на тестах триалки от MS показывало на порядки лучшие результаты, чем альтернативы), но потом чуть подтюнинговав конфиги, удалось выйти на близкие показатели (нет, "чуда не произошло", превысить производительность "эталонной конфигурации" я не смог, но хотя бы с десятков раз дошёл до десятков процентов, и да, я далеко не DBA, а лишь системный администратор, но даже моей квалификации оказалось достаточно), так что тестировать производительность на дефолтных конфигах - "такое себе".
Выжимаем максимум из PostgreSQL