Comments 21
Производственных средах? А production environment… пойду лучше оригинал почитаю.
PS. "в боевом окружении" самый адекватный перевод, если переводить целиком.
А почему про temp_buffers забыли? Если используются временные таблицы, то очень важный параметр (особенно, если диски не SSD).
random_page_cost туда же (для ssd 1.1-1.3)
Согласен, там все косты надо менять, так как разработчики PostgreSQL еще не осознали, что сейчас БД больше используется с SSD и настройки надо крутить под них.
Посмотрите на список core team. Люди, работающие в 2ndQuadrant, EnterpriseDB, Crunchy Data. Отлично они знают возможности железа. Как и понимают, что в качестве дефолтов нельзя брать параметры хорошего железа.
Впрочем, для автовакуума решили настройки поменять недавно, в основной с той идеей, что чрезмерно активный автовакуум люди заметят и настроят под своё железо, а вот слишком ленивый автовакуум — не настраивают.
Впрочем, для автовакуума решили настройки поменять недавно, в основной с той идеей, что чрезмерно активный автовакуум люди заметят и настроят под своё железо, а вот слишком ленивый автовакуум — не настраивают.
Лучше не надо времянками увлекаться. Это гарантированный поход на диск на create table и распухающий системный каталог. А если сильно не повезёт — то ещё и проблемы с wraparound отхватить можно.
Значение по умолчанию для shared_buffer установлено очень низким, и вы не получите большой выгоды от него. Сделано это потому, что некоторые машины и операционные системы не поддерживают более высокие значения.
Пояснение неверно. Если ОС не даёт дефолтные 128мб — то на этапе initdb будет выбран ещё более низкий дефолт.
А 128мб дефолт — пальцем в небо некоторое значение чтобы запуститься и не мешать всем остальным.
Сильно удивлён зачем тут wal_buffers упомянут.
Описывать work_mem как сортировку — неверно. Его много кто может использовать. hash join тот же, группировки. Что с work_mem делать правильно — log_temp_files = 0 и смотреть логи и temp_blks_read/temp_blks_written в pg_stat_statements. Находите, кто лезет во временные файлы, насколько это нужно, сколько временных файлов у вас и поднимаете work_mem если это имеет смысл.
Ну и что очень важно — встречающийся в интернетах расчёт памяти как max_connections * work_mem — неверен. Один запрос может использовать несколько work_mem, это лимит на один узел плана запроса.
Про синхронный коммит пожалуй повторяться не буду. Стоит ещё раз уточнить, что именно значит здесь надёжность. Угрозы для самой базы нет, могут быть отменены последние транзакции перед крахом, даже если приложению ответили «записано»
По чекпойнтеру вообще не упомянут max_wal_size. Если вы поставите таймаут часовой, а чекпойнты будут срабатывать по объёму записи пару раз в минуту — это ничего не изменит, чекпойнтов будет всё равно слишком много. В итоге вроде начали про чекпойнты правильно, но как-то ровно на половину.
И начисто не упомянут автовакуум. А вещь крайне нужная, которая помимо уборки мусора обновляет статистику для планировщика.
Плюс bgwriter необходимо упомянуть, чтобы сбросом грязных страниц занимался он, а не backend'ы судорожно искали чтобы такого записать из shared_buffers на диск потому что надо прочитать блок, а некуда.
И логирование настроить.
Рекомендуемое значение составляет 25% от общего объема оперативной памяти компьютера.
Интересно, в чём принцип расчёта этого «рекомендованного» значения? Если у меня 128G оперативки на выделенном для Postgres железе, какой смысл ему отдавать всего 32G?
Тем не менее, вы, очевидно, не хотите резервировать всю оперативную память для PostgreSQL.
Опять-таки, почему нет? Разве не в этом смысл выделенных серверов БД?
ИМХО здесь борьба с двойным кешированием в page cache и связанными с этим спецэффектами. Если на машине только PG и ничего более, то (ИМХО опять таки) можно задрать этот параметр. По сути, я лично оставил немного системе и остальное поделил между work_mem и shared на железной машине выделенной под БД. Work_mem при этом брался средне-прикидошно по количеству подключений и размеру параметра… Проблем не вылезло, но и нагрузка там средненькая.
Все это конечно круто, но первой строкой перед любой оптимизацией должно идти для какой системы эта оптимизация происходит. Postgres для веб сервера совсем другие настройки имеет чем Postgres для OLTP и совсем другие для OLAP как в принципе и другая СУБД.
Так как это перевод то возможно в том контексте откуда он взят это и было понятно.
По хорошему настройка на pgtune.leopard.in.ua закроет 80% для начала, а потом когда база вырастет нужен конкретный тюнинг
И кстати Postgres Pro для 1С сейчас приходит с настройками которые очень даже приличные.
Сравнение есть но пиариться не буду )
Так как это перевод то возможно в том контексте откуда он взят это и было понятно.
По хорошему настройка на pgtune.leopard.in.ua закроет 80% для начала, а потом когда база вырастет нужен конкретный тюнинг
И кстати Postgres Pro для 1С сейчас приходит с настройками которые очень даже приличные.
Сравнение есть но пиариться не буду )
Интересно, а в каком тысячелетии PostgreSQL можно будет сказать: вот тебе 50Гб оперативки и дальше развлекайся как хочешь. Копи статистику, анализируй соотношения диска/памяти/CPU…
А сейчас получается: мы по дефолту сделали совершенно отвратительные настройки, и тебе надо изменить их (8 важных и ещё 30 неважных). Ты можешь быть DBA или читать статьи в интернете и тыкать пальцем в небо, пытаясь попасть в хорошие цифры.
А сейчас получается: мы по дефолту сделали совершенно отвратительные настройки, и тебе надо изменить их (8 важных и ещё 30 неважных). Ты можешь быть DBA или читать статьи в интернете и тыкать пальцем в небо, пытаясь попасть в хорошие цифры.
Зато она, в отличии от mysql, не жрет ВСЕ ресурсы сервера на кривых запросах, давай соседям работать адекватно. Я не специалист по mysql, но быстрого ответа не находил для неё.
Для небольших проектов можно пользоваться DB2 Express. Вполне приемлимые ограничения на оперативу и нет ограничений на размер базы. Только по процессору ограничение 2 ядра и это печально. Но там действительно автоматически настройки выставляются
Сильно зависит от задач. Данные алгоритмы обработки знаеют пользователь и разработчик: какие запросы "главнее", переодические задачи, наличие и характеристики реплик.
Автонастройка натренированная на ежедневных задачах может провалиться на месячном или квартальном отчёте, а периодически нагрузка или разовая — СУБД никак не узнает (сбор статистики годами нерелевантен)
Ну провалится настройка на месячном отчёте и он будет не час выполняться, а три. Раз в месяц. Зато на задачах которые выполняются каждый день и каждую минуту, всё будет лучше. В любом случае, между вариантами:
1. Использовать автонастройку, в случае проблем позвать умного DBA, который поправит
2. Нагуглить числа из интернета, в случае проблем позвать умного DBA, который поправит
3. Позвать умного DBA, который поправит сразу
Мне больше нравится вариант 1, потому что не факт, что проблемы будут, а умный DBA — это весьма дорогое существо, а ещё оно может просто сказать, купите сервер мощнее и не парьте мне мозги, что можно и без него сделать.
1. Использовать автонастройку, в случае проблем позвать умного DBA, который поправит
2. Нагуглить числа из интернета, в случае проблем позвать умного DBA, который поправит
3. Позвать умного DBA, который поправит сразу
Мне больше нравится вариант 1, потому что не факт, что проблемы будут, а умный DBA — это весьма дорогое существо, а ещё оно может просто сказать, купите сервер мощнее и не парьте мне мозги, что можно и без него сделать.
Sign up to leave a comment.
Настройка параметров PostgreSQL для оптимизации производительности