Что изучить в PostgreSQL 18 перед настройкой базы 1С

PostgreSQL 18 установили на учебный сервер. Рядом лежит старый postgresql.conf, который годами работал с 1С. Копировать его рано: в PostgreSQL 18 появились асинхронный ввод-вывод, B-tree skip scan и новый вывод EXPLAIN ANALYZE.

Вам нужен не список курсов, а маршрут проверки. Сначала освойте административные операции, затем научитесь читать планы запросов и собирать статистику. Настройки для 1С проверяйте последними и только на отдельном стенде.

Перед экспериментами подготовьте Linux, наблюдение за нагрузкой и резервную копию. Тогда у каждого изменения будут исходное состояние, измеримый результат и путь назад.

Официальная документация закрывает основы администрирования

Начните с части III документации PostgreSQL 18. Она охватывает установку, конфигурацию сервера, управление ролями, базами и обслуживание.

Главы этой части самостоятельны. Документация PostgreSQL прямо указывает, что их можно читать по отдельности. Первые главы не требуют предварительного знакомства с администрированием PostgreSQL.

Читать всю часть подряд незачем. Выберите ближайшую рабочую задачу и повторите её на стенде.

Эта таблица задаёт порядок работы: раздел документации выбирают под операцию, а не под свободный вечер.

Материалы по тонкой настройке предполагают, что читатель уже работал с PostgreSQL. Если роли, каталоги и службы пока незнакомы, начните с подготовки Linux-сервера для 1С. На стенде вам придётся управлять не только СУБД, но и операционной системой.

После основ изучите планы запросов

Случайная правка параметров редко объясняет задержку. Глава 14 документации PostgreSQL 18 связывает скорость запроса с несколькими факторами. Часть из них меняет администратор, остальные заложены в устройство системы.

Поэтому следующий материал после основ — раздел Using EXPLAIN. Он показывает, какой план выбрал PostgreSQL и как планировщик оценил стоимость операций.

Для первого опыта возьмите запрос с учебной базы:

EXPLAIN SELECT * FROM test_table WHERE id = 100;

Затем выполните его с фактическими данными:

EXPLAIN (ANALYZE) SELECT * FROM test_table WHERE id = 100;

EXPLAIN ANALYZE запускает запрос, а не только строит предполагаемый план. Не переносите такой опыт на изменяющий запрос в рабочей базе: UPDATE, DELETE или INSERT действительно поменяют данные.

PostgreSQL 18 выводит сведения BUFFERS при EXPLAIN ANALYZE по умолчанию. Это изменение отмечено в обзоре настройки PostgreSQL 18 от Tomoda Hinata. Старый учебный материал может предлагать включать тот же вывод отдельным параметром.

Смотрите не на одну итоговую стоимость. Сопоставляйте оценённые строки с фактическими, ищите чтение лишних блоков и проверяйте временные файлы. Один параметр work_mem не исправит план, если планировщик неверно оценил число строк.

B-tree skip scan тоже меняет привычную картину. PostgreSQL 18 способен использовать многоколоночный B-tree в ситуациях, где старый сервер мог выбрать другой путь. Поэтому планы до и после обновления нужно сравнивать, а не считать прежний индекс бесполезным заранее.

Если запрос построен через WITH, пригодится материал про поведение CTE в планах PostgreSQL. Он продолжает эту задачу: понять план, прежде чем менять запрос или конфигурацию сервера.

Один план не показывает нагрузку всей базы

EXPLAIN отвечает на вопрос об одном запуске. Администратору 1С нужен второй уровень: какие запросы съедают время за смену и как часто они выполняются.

Для этого подходит модуль pg_stat_statements. По данным обзора Tomoda Hinata, модуль объединяет похожие запросы и заменяет литералы заполнителями вроде $1. Запуски с разными номерами документов попадают в одну группу.

Модуль нужно добавить в shared_preload_libraries, после чего перезапустить PostgreSQL. Одного CREATE EXTENSION недостаточно для полноценного сбора статистики.

shared_preload_libraries = 'pg_stat_statements'

После перезапуска создайте расширение в учебной базе:

CREATE EXTENSION pg_stat_statements;

Перезапуск влияет на доступность сервера. Поэтому сначала отработайте процедуру на стенде: сохраните конфигурацию, проверьте журнал запуска и убедитесь, что модуль загрузился.

Порядок защищает от преждевременного тюнинга: сначала находят нагрузку, затем объясняют её планом и метриками хоста.

Для сквозной проверки пригодится маршрут наблюдения от Linux до PostgreSQL и процессов 1С. Он помогает связать медленный запрос с состоянием диска, памяти и серверных процессов.

Рекомендации для 1С нельзя копировать без проверки версии

Общий учебник по PostgreSQL и рекомендации для 1С решают разные задачи. Первый объясняет механику СУБД. Материал 1С учитывает характер нагрузки платформы, но часть его настроек появилась задолго до PostgreSQL 18.

Например, оба материала предлагают начать shared_buffers с четверти оперативной памяти. По random_page_cost формулировки расходятся: обзор PostgreSQL 18 даёт около 1.1 для SSD и NVMe, а рекомендации 1С — диапазон 1.1–1.3 для SSD.

Это не повод выбрать среднее значение. Настройка меняет оценку стоимости доступа к данным и может повлиять на план. Сначала зафиксируйте старый план, затем поменяйте один параметр и повторите запрос.

Вывод один: строка из учебного материала служит гипотезой для стенда, а не готовым фрагментом рабочего postgresql.conf.

Ориентиры из таблицы взяты из двух названных материалов: обзора Tomoda Hinata для PostgreSQL 18 и статьи «Настройки PostgreSQL для работы с 1С:Предприятием. Часть 2» на 1С:ИТС. Перед переносом проверяйте, к какой версии относится каждый параметр.

Особенно осторожно работайте с work_mem. Это память не на весь сервер и не на одно подключение. Её могут одновременно запросить несколько операций внутри разных сеансов. Поэтому расчёт только от объёма RAM не показывает верхнее потребление.

Не начинайте и с отключения сохранности данных. Материал 1С оставляет fsync включённым. Для synchronous_commit = off он прямо указывает риск потерять примерно 0,5–1 секунду подтверждённых изменений при сбое.

Такое решение нельзя принимать как обычный способ ускорения. Сначала определите допустимую потерю данных, проверьте восстановление и согласуйте риск с владельцем системы.

PostgreSQL 18 требует повторной проверки старого конфига

Переносить прежний файл целиком неудобно даже тогда, когда сервер запускается. Вы теряете новые значения по умолчанию и не видите, какие строки остались от старой версии.

В PostgreSQL 18 появился отдельный механизм асинхронного ввода-вывода. Обзор Tomoda Hinata перечисляет методы worker, io_uring и sync. Там же указано, что значения effective_io_concurrency и maintenance_io_concurrency по умолчанию выросли с 1 до 16.

Это меняет контекст старых рекомендаций по дисковой подсистеме. Сначала сохраните конфигурацию, которую создала версия 18. Затем переносите только параметры, для которых можете назвать причину и способ проверки.

Работайте короткими сериями:

1. Зафиксируйте версию PostgreSQL и исходный конфигурационный файл.
2. Снимите план выбранного запроса и показатели нагрузки.
3. Измените один параметр.
4. Перезапустите или перечитайте конфигурацию нужным способом.
5. Повторите тот же запрос при сопоставимых условиях.
6. Верните исходное значение, если показатель не улучшился.

Этот порядок не доказывает пригодность настройки для рабочей базы. Он отсеивает изменения, которые не выдержали даже контролируемой проверки.

Резервная копия нужна до экспериментов

Сохранённый postgresql.conf защищает только настройки. Он не вернёт данные после ошибочной команды, обновления или сбоя накопителя.

До испытаний настройте копирование и проведите тестовое восстановление. Не считайте успешный pg_dump доказательством: результат подтверждает только база, развёрнутая в отдельный каталог или отдельный экземпляр PostgreSQL.

Выбор метода зависит от требуемой точки восстановления. Логический дамп, физическая копия и архивирование WAL закрывают разные сценарии. Их порядок настройки описан в материале про создание восстанавливаемой копии PostgreSQL.

После восстановления повторите административную операцию из первой таблицы. Затем включите статистику, выполните учебный запрос и верните конфигурацию назад. Так вы проверите не отдельную команду, а весь маршрут.

Маршрут подготовки к рабочему изменению

Возьмите одну задачу, а не весь PostgreSQL сразу. Например: проверить, стоит ли менять random_page_cost после перехода на PostgreSQL 18.

Дальше двигайтесь по одному маршруту:

1. Найдите административную операцию в части III документации PostgreSQL 18.
2. Воспроизведите её на отдельном сервере с копией структуры базы.
3. Получите исходный план через EXPLAIN и фактический — через EXPLAIN ANALYZE.
4. Подключите pg_stat_statements и найдите группу запросов по накопленной статистике.
5. Сопоставьте общий ориентир с рекомендацией 1С.
6. Измените один параметр и повторите тот же сценарий.
7. Проверьте возврат исходной конфигурации и восстановление копии.
8. Подготовьте рабочее изменение только после совпадения всех проверок.

Бесплатный материал приносит пользу, когда оставляет три вещи: проверяемое действие, наблюдаемый показатель и способ отката. Подборка ссылок без них знакомит с PostgreSQL, но не готовит к настройке базы 1С.