PostgreSQL после установки настроен на сервер с одним гигабайтом памяти. Введите параметры своего сервера, и калькулятор соберёт фрагмент postgresql.conf: память, соединения, журнал, autovacuum и запись в лог того, что потом понадобится при разборе «тормозит».
Положите его отдельным файлом в каталог conf.d или допишите в конец postgresql.conf: при повторе параметра действует последнее значение. Строки с пометкой «перезапуск» применяются только после перезапуска базы.
Включите JavaScript, чтобы увидеть расчёт.
select sourcefile, sourceline, name, error from pg_file_settings where error is not null;
Пустой ответ означает, что файл прочитан без ошибок. Запрос работает до применения настроек.
select pg_reload_conf(); select name, setting from pg_settings where pending_restart;
Второй запрос покажет параметры, которые ждут перезапуска.
Перезапуск обрывает все сессии. Сервисы RX переподключатся сами, но пользователи получат ошибки в момент перезапуска.
Сначала на тестовом контуре. Калькулятор не видит вашу нагрузку. Он даёт разумную отправную точку, после которой нужно смотреть на работу базы: долю чтения из кэша, чекпоинты, временные файлы. Это показывает rxdoctor.
Формулы открыты. Значения по умолчанию взяты из нашей эксплуатации Directum RX на PostgreSQL и Postgres Pro, с каждым можно поспорить.
shared_buffers равен четверти памяти, отведённой базе. Остальное нужно кэшу операционной системы, о нём планировщику сообщает effective_cache_size (70 %). work_mem выдаётся на каждую сортировку в каждом соединении, поэтому считается от числа соединений: половина свободной памяти, поделённая на max_connections, в пределах от 4 до 64 МБ. Завышенный work_mem при сотнях соединений заканчивается тем, что ядро убивает процесс базы.
У Directum RX больше десятка сервисов, и у каждого свой пул соединений. Мы закладываем полтора соединения на одновременно работающего пользователя плюс сто на сервисы и обслуживание. Значение по умолчанию 100 для RX мало уже на сотне пользователей. Выше 600 соединений дешевле поставить PgBouncer, чем растить лимит: каждое соединение это отдельный процесс и около 10 МБ памяти.
При max_wal_size по умолчанию (1 ГБ) массовые операции RX вызывают чекпоинты каждые несколько минут, и отклик проседает волнами. Мы даём от 4 до 16 ГБ в зависимости от размера базы и чекпоинт раз в 10 или 15 минут с растянутой записью. Плата за это: восстановление после сбоя идёт дольше, а каталог pg_wal занимает больше места. wal_compression уменьшает объём журнала ценой небольшой нагрузки на процессор.
Значение random_page_cost = 4 по умолчанию рассчитано на вращающиеся диски. На SSD с ним планировщик выбирает полное чтение таблицы там, где индекс быстрее. Параллельные исполнители ограничены двумя на запрос: RX это много коротких запросов, и распараллеливание каждого только мешает соседям.
По умолчанию autovacuum приходит, когда в таблице изменилось 20 % строк. У больших таблиц RX (задания, история, права доступа) это миллионы мёртвых строк до первой очистки. Мы снижаем порог до 1 % для очистки и 0,5 % для сбора статистики и сокращаем паузу между проходами. Очистка идёт чаще и маленькими порциями, таблицы не раздуваются, планировщик работает со свежей статистикой.
Запросы дольше двух секунд, ожидания блокировок дольше секунды, временные файлы больше 10 МБ, долгие проходы autovacuum и чекпоинты. Без этого разбор «вчера тормозило» превращается в гадание. Модуль pg_stat_statements и track_io_timing дают статистику по запросам и времени ввода-вывода. idle_in_transaction_session_timeout закрывает сессии, которые открыли транзакцию и замолчали: они держат блокировки и мешают очистке.
Для реплики включаются слоты и wal_log_hints, чтобы после переключения старый основной сервер можно было вернуть через pg_rewind без полного копирования. max_slot_wal_keep_size ограничивает журнал, который удерживает слот: выключенная реплика без этого параметра заполнит диск основного сервера. Команду архивирования калькулятор не придумывает, она зависит от того, чем вы делаете бэкапы.
При shared_buffers от 8 ГБ большие страницы заметно снижают накладные расходы на память. Калькулятор показывает значение vm.nr_hugepages с запасом 10 %. Точное число даёт сама база: show shared_memory_size_in_huge_pages (с версии 15). Проверяйте результат по /proc/meminfo: если HugePages_Rsvd равен нулю при работающей базе, страницы не используются. PostgreSQL с huge_pages = try в этом случае молча работает на обычных страницах и ничего не пишет в лог.
Три вещи, о которых забывают. Раздел /dev/shm в контейнере равен 64 МБ, параллельным запросам этого не хватает: нужен ключ --shm-size. Лимит памяти контейнера должен покрывать shared_buffers, соединения и /dev/shm вместе. Данные должны лежать на томе, а не в слое контейнера.
Чего калькулятор не знает: ваших интеграций, отчётов, ночных заданий и прикладной разработки. Тяжёлый отчёт может потребовать больше work_mem для одной роли, большая таблица может потребовать своих настроек autovacuum. Это настраивается по результатам наблюдения.
Сколько серверов, памяти и дисков нужно под вашу систему в целом. Калькулятор сайзинга
Пороги памяти и диска для брокера сообщений. Калькулятор настроек RabbitMQ
Как сохранить базу и проверить, что из бэкапа можно вернуться. Команды бэкапа