PostgreSQL тормозит с 1С? Оптимизация настроек для высокой скорости

Содержание

Рекомендации по настройке PostgreSQL для быстрой работы 1С
Полезные материалы
Пример файла postgresql.conf
Настройка pg_stat_temp (устарело)
Как настроить PostgreSQL для быстрой работы 1С

Полезные материалы

ИТС: https://its.1c.ru/db/metod8dev/content/5866/hdoc
Решение проблемы с зависанием (ИТС KZ): https://its.1c.kz/db/metod8dev/content/4692/hdoc
Доклад про батл с MS SQL от 2018 года: https://infostart.ru/1c/articles/962876/

Пример файла postgresql.conf

Файл настроек сервера СУБД компании MoscowSoft доступен по ссылке: https://disk.yandex.ru/d/iUTz4WFyYiHcXw

У нас 64Гб ОЗУ, несерверное железо. Процессор Intel i7-9700K 8 ядер с частотой 3,6GHz. SSD-диски и для системы и для файлов СУБД. Для нашей ситуации оптимальными оказались настройки по ссылке выше. В вашей ситуации все может быть по-другому.

Настройка pg_stat_temp (устарело)

Начиная с версии 15 PostgreSQL эта настройка не используется. Ранее создавали виртуальный диск в памяти (можно создать как в Windows, так и в Linux). И хранение временных файлов при работе PostgreSQL настраивали на этом виртуальном диске. Это помогало ускорить работу и сохранить ресурс жестких дисков.

Как настроить PostgreSQL для быстрой работы 1С

Разобраться с настройкой PostgreSQL под 1С проще, чем кажется. Да, терминов много, но на практике основных параметров – с десяток. Хватит, чтоб база перестала задумываться на каждом документе.

Почему вообще нужна настройка

PostgreSQL ставится с дефолтными настройками. Они рассчитаны на компьютер начала 2000-х – гигабайт памяти, один процессор. Ну чтоб везде запускалось. Понятно, что на нормальном сервере с 32 гигабайтами RAM это работает процентов на 30 мощности.

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

Где живут все настройки

Файл называется postgresql.conf.

Лежит в папке с данными PostgreSQL, обычно что-то вроде /var/lib/pgsql/версия/data/ в Linux или в папке Data под Windows. После правки большинства параметров базу придется перезапустить – это важно. Поэтому настраивают обычно ночью или в выходной.

Память – главное, с чего начать

shared_buffers

Это память для кеша страниц. Все процессы PostgreSQL делят ее между собой. Формула простая – четверть от всей RAM. Если на сервере 32 Гб, ставим 8 Гб.

shared_buffers = 8GB

Больше 8 гигабайт ставить аккуратно, могут быть проблемы с замедлением. Проверяйте потом, как работает.

work_mem

Память для одного запроса – сортировки, объединения таблиц. Каждая сессия получает свой кусок. Считается по формуле RAM/32 или RAM/64, можно прикинуть 32-128 мегабайт.

Для 32 Гб памяти подойдет:

work_mem = 128MB

Если ставите слишком много, а пользователей куча – память закончится быстро. Тут баланс нужен.

maintenance_work_mem

Это для служебных задач – VACUUM, ANALYZE, создания индексов. Формула: RAM/16 или work_mem умножить на 4. Получается где-то 256 Мб – 4 Гб. Для 32 Гб ставим:

maintenance_work_mem = 2GB

effective_cache_size

Тут базе объясняем, сколько вообще памяти доступно для кеша. Не только PostgreSQL – учитывая кеш операционки. Берем 50-75% от всей RAM. Для 32 Гб:

effective_cache_size = 24GB

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

Скорость дисков – параметры планировщика

random_page_cost и seq_page_cost

База не знает, какие у вас диски. HDD крутится медленно, SSD шустрый, NVMe вообще летает. Параметр random_page_cost говорит, во сколько раз дороже случайное чтение по сравнению с последовательным.

Для HDD: random_page_cost = 4.0 (по умолчанию)
Для RAID из HDD: random_page_cost = 1.5-2.0
Для SSD: random_page_cost = 1.1-1.3
Для NVMe: random_page_cost = 0.1

Для SSD настройки будут такие:

random_page_cost = 1.1 seq_page_cost = 1.0

При правильном значении оптимизатор начнет чаще использовать индексы вместо полного сканирования таблиц.

Кстати, если база маленькая и вся помещается в память – можно ставить random_page_cost совсем низким. Тогда даже "случайное" чтение идет из кеша, а не с диска.

Количество подключений

max_connections

Сколько пользователей могут подключиться одновременно. По умолчанию 100. Для 1С часто рекомендуют ставить 200. Каждое подключение жрет память, так что много не всегда хорошо.

max_connections = 200

Если нужно больше соединений – используйте пулер типа PgBouncer. Он переиспользует подключения, экономит ресурсы.

Параметр требует перезапуска сервера.

Журнал WAL и контрольные точки

Что такое WAL

WAL – Write Ahead Log, журнал предзаписи. Все изменения сначала пишутся туда, потом уже в саму базу. Если сервер упадет – база восстановится из WAL.

checkpoint_timeout и max_wal_size

Контрольные точки – это когда все грязные страницы из памяти сбрасываются на диск. Делается это по времени или по размеру WAL.

checkpoint_timeout = 15min max_wal_size = 2GB

Чем больше max_wal_size, тем реже checkpoint, но дольше восстановление после сбоя. Для 1С с активной записью можно ставить 2-4 Гб.

checkpoint_completion_target

Как долго растягивать запись checkpoint – чтоб не было резкого всплеска нагрузки. Ставят обычно 0.9 – то есть записывать 90% времени между checkpoint'ами.

checkpoint_completion_target = 0.9

Это сглаживает нагрузку на диск, избегаем тормозов.

synchronous_commit и fsync

Параметр fsync включает синхронную запись на диск после каждого COMMIT. Гарантирует сохранность, но медленнее. Можно выключить, если есть RAID с кешем и UPS. Иначе рискуете данными при сбое.

synchronous_commit мягче – можно поставить off. Транзакция считается завершенной до записи на диск. Быстрее процентов на 30, но при крахе последние транзакции могут потеряться. База останется консистентной, просто последние секунды работы пропадут.

Для 1С часто используют:

fsync = on synchronous_commit = off

Это баланс между скоростью и безопасностью.

Автовакуум – чтоб база не раздувалась

Зачем нужен VACUUM

PostgreSQL не удаляет строки сразу. При UPDATE или DELETE старая версия остается, накапливается "мусор". VACUUM чистит это. Если не чистить – таблицы раздуваются, запросы тормозят.

autovacuum_max_workers

Сколько процессов автовакуума запускать одновременно. Для многоядерных серверов можно поставить 3-4.

autovacuum_max_workers = 4

autovacuum_vacuum_scale_factor

По умолчанию vacuum запускается, когда изменено 20% таблицы. Для больших таблиц это много. Можно снизить до 0.05-0.1, чтоб чистка шла чаще небольшими порциями.

autovacuum_vacuum_scale_factor = 0.1

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

autovacuum_naptime

Как часто проверять, нужен ли vacuum. По умолчанию 1 минута. Можно оставить как есть.

Главное – никогда не выключайте autovacuum полностью. Это приведет к деградации производительности и возможному краху базы.

Специфичные настройки для 1С

Есть несколько параметров, которые 1С требует:

standard_conforming_strings = off escape_string_warning = off max_locks_per_transaction = 256 row_security = off

Это про экранирование символов и количество блокировок в транзакции. 1С работает по-своему, ей эти настройки нужны.

Postgres Pro или обычный PostgreSQL?

Для 1С часто рекомендуют Postgres Pro. Это российская версия с доработками. Отличия:

Автоматическая настройка под 1С сразу после установки
Техподдержка на русском 24/7
Сертификация ФСТЭК для госсектора
Сжатие данных в 2-5 раз
Multimaster-репликация

Обычный PostgreSQL тоже работает с 1С. Но Postgres Pro заточен именно под эту связку. Выбирайте в зависимости от бюджета и требований.

Индексы – без них никуда

Индексы в PostgreSQL ускоряют поиск. Вместо перебора всей таблицы база смотрит в индекс и сразу находит нужные строки.

Основной тип – B-tree. Создается по умолчанию. Подходит для большинства задач – поиск, сортировка, диапазоны.

CREATE INDEX idx_name ON table_name (column_name);

Для 1С индексы создаются автоматически. Но иногда полезно добавить свои – если видите медленные запросы на конкретные поля.

Бывают функциональные индексы – по результату функции, а не по самому полю. Например, индекс по lower(author) для поиска без учета регистра.

Hash-индексы используют редко. GiST и GIN – для полнотекстового поиска и массивов. Для обычных таблиц 1С это не нужно.

Индексы ускоряют чтение, но замедляют запись. При INSERT/UPDATE индекс тоже обновляется. Не надо индексировать все подряд – только то, по чему часто ищете.

Мониторинг – чтоб понять, что происходит

После настройки проверяйте, как работает. Включите логирование медленных запросов:

log_min_duration_statement = 3000 log_destination = 'syslog'

Это запишет все запросы дольше 3 секунд. Смотрите логи, ищите узкие места.

Можно использовать расширение pgstattuple для проверки раздувания таблиц. Или запросы из блогов – они покажут процент мусора. Если больше 20% – надо настраивать autovacuum агрессивнее.

Проверяйте статистику checkpoint'ов:

log_checkpoints = on

Если checkpoint происходят слишком часто или долго – регулируйте max_wal_size и checkpoint_completion_target.

Примерный конфиг для сервера на 32 Гб

Вот что получается для реального сервера с 32 Гб RAM, 8 ядрами CPU и SSD-дисками:

# Память shared_buffers = 8GB work_mem = 128MB maintenance_work_mem = 2GB effective_cache_size = 24GB # Диски random_page_cost = 1.1 seq_page_cost = 1.0 # Подключения max_connections = 200 # WAL и checkpoint checkpoint_timeout = 15min max_wal_size = 2GB checkpoint_completion_target = 0.9 wal_buffers = 16MB fsync = on synchronous_commit = off # Autovacuum autovacuum = on autovacuum_max_workers = 4 autovacuum_naptime = 1min autovacuum_vacuum_scale_factor = 0.1 # Для 1С standard_conforming_strings = off escape_string_warning = off max_locks_per_transaction = 256 row_security = off # Мониторинг log_checkpoints = on log_min_duration_statement = 3000

Это базовая настройка. Конкретные значения зависят от вашей нагрузки – сколько пользователей, какие операции, размер базы. Тестируйте, смотрите логи, корректируйте.

Не забывайте про железо

Самая лучшая настройка не поможет, если железо слабое. PostgreSQL любит быструю память, много ядер и шустрые диски. SSD или NVMe предпочтительнее HDD. RAID-контроллер с кешем и батарейкой снимает риски при отключении fsync.

Если база на виртуалке – выделите достаточно ресурсов. Не экономьте на vCPU и RAM. Виртуализация добавляет накладные расходы, это надо учитывать.

В Linux настройте профиль производительности через tuned. По умолчанию может стоять энергосбережение, процессор не разгоняется полностью. Отключите transparent huge pages – они мешают PostgreSQL.

Тестирование после настройки

Настроили? Теперь тестируйте. Запустите типовые операции 1С – проведение документов, формирование отчетов. Засеките время до и после.

Посмотрите на тестирование производительности встроенными средствами 1С. Должен быть прирост процентов на 20-40. Если меньше – копайте дальше, смотрите логи.

Используйте инструмент pgbench для синтетических тестов. Он покажет, как изменилась пропускная способность. Хотя для 1С важнее реальные бизнес-процессы, а не синтетика.

Прогоните базу под нагрузкой несколько дней. Проверьте раздувание таблиц, частоту autovacuum, скорость запросов. Если что-то не так – докручивайте параметры.

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