Развертывание высоконагруженной системы 1С:ERP на СУБД PostgreSQL — отличный способ оптимизировать затраты на лицензирование и построить гибкую инфраструктуру. Однако, оставляя настройки СУБД по умолчанию, системные администраторы часто сталкиваются с лавинообразным падением производительности уже через несколько месяцев активной эксплуатации. База растет, количество пользователей увеличивается, и стандартные конфигурации перестают справляться с нагрузкой.
В этой статье мы подробно разберем, как уйти от дефолтных настроек, как правильно организовать регламентные операции без блокировки пользователей, и какую стратегию резервного копирования выбрать для обеспечения стопроцентной сохранности данных.
Разработчики PostgreSQL поставляют СУБД с крайне консервативными настройками. Это сделано для того, чтобы сервер гарантированно запустился даже на самом слабом оборудовании с минимальным объемом оперативной памяти. В таком режиме СУБД использует ничтожно мало ресурсов хоста, сбрасывая большинство промежуточных расчетов на жесткий диск.
Для тяжелых ERP-решений 1С характерна специфическая нагрузка: огромное количество мелких транзакций, частая запись во временные таблицы, сложные многотабличные соединения при построении отчетов. Чтобы СУБД работала стабильно, нам необходимо перераспределить ресурсы сервера и оптимизировать параметры конфигурационного файла postgresql.conf.
Рассмотрим основные параметры конфигурации, которые критически влияют на быстродействие связки СУБД и 1С. Для примера предположим, что наш выделенный сервер базы данных обладает 64 ГБ оперативной памяти (RAM) и 8-ядерным процессором.
Проанализируем ключевые параметры и внесем изменения:
shared_buffers — объем оперативной памяти, используемый PostgreSQL для совместного кэширования данных. По умолчанию он равен всего лишь 128 МБ. Для выделенного сервера под 1С рекомендуется выделять под этот параметр 25% от общего объема RAM. В нашем примере установим значение в 16 ГБ.work_mem — объем памяти, выделяемый для работы одного запроса на сортировку и группировку данных. Если запросу не хватает этого объема, СУБД начинает использовать временные файлы на диске, что резко замедляет систему. Для средних баз 1С рекомендуется устанавливать значения от 32 МБ до 128 МБ. Будьте осторожны: эта память выделяется на каждое соединение, поэтому слишком большое значение при высоком количестве пользователей может исчерпать всю физическую RAM.maintenance_work_mem — память, используемая для выполнения сервисных операций, таких как создание индексов, сбор статистики и очистка (vacuum). Для баз данных 1С ERP рекомендуется устанавливать повышенные значения — от 1 ГБ до 4 ГБ. Это существенно ускорит выполнение регламентных задач.effective_cache_size — ориентировочный объем памяти, доступный для кэширования файлов самой операционной системой и СУБД. Этот параметр помогает планировщику запросов оценить вероятность нахождения данных в RAM. Рекомендуется устанавливать его на уровне 50–75% от общего объема памяти. В нашем случае выставим 48 ГБ.synchronous_commit — параметр, отвечающий за синхронную запись лога транзакций на диск. Установка значения off (выключение синхронизации) дает колоссальный прирост производительности при записи в 1С. В этом случае транзакция считается завершенной до того, как запись физически запишется на накопитель. Риск потери данных при аварийном отключении питания составляет около 0.5–1 секунды работы, что легко нивелируется установкой надежного источника бесперебойного питания (ИБП).temp_buffers — буфер под временные таблицы. Так как платформа 1С активно использует временные таблицы, увеличим этот параметр до 128 МБ или 256 МБ.Разберем пример конфигурации для нашего гипотетического сервера в файле postgresql.conf:
# Основные параметры оптимизации памяти и транзакций
shared_buffers = 16GB
effective_cache_size = 48GB
work_mem = 64MB
maintenance_work_mem = 2GB
temp_buffers = 128MB
max_connections = 500
# Ускорение дисковых операций записи
synchronous_commit = off
commit_delay = 100000
commit_siblings = 5
В старых статьях и рекомендациях часто можно встретить совет проводить регулярную процедуру VACUUM FULL в конце каждой недели. В современных реалиях крупных баз 1С делать этого категорически не стоит!
Выясним причину этого запрета. Команда VACUUM FULL полностью перестраивает таблицы базы данных, освобождая дисковое пространство. Однако на время выполнения она накладывает жесткую эксклюзивную блокировку (Access Exclusive Lock) на всю таблицу. В результате пользователи вообще не могут работать с базой, а на терабайтных базах ERP процедура может затянуться на многие часы или даже дни.
Вместо ручного запуска тяжелых процедур очистки, мы настроим автоматический фоновый процесс — Autovacuum. Наша задача заключается в том, чтобы заставить автовакуум работать агрессивно и непрерывно, убирая "мертвые" строки (bloat) сразу после их появления, не дожидаясь раздувания таблиц.
Для этого изменим следующие настройки в конфигурационном файле:
# Тюнинг автовакуума под интенсивную нагрузку 1С
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
# Снижаем порог срабатывания очистки таблиц до 5% изменений
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
# Ускоряем работу процессов очистки
autovacuum_vacuum_cost_delay = 2ms
autovacuum_vacuum_cost_limit = 3000
Объясним, что мы сделали: снизив коэффициенты срабатывания autovacuum_vacuum_scale_factor с дефолтных 20% до 5%, мы заставили систему инициировать очистку гораздо раньше. Теперь, как только в таблице обновится или удалится 5% записей, автовакуум незаметно для пользователей займется ее обслуживанием, исключая лавинообразное раздувание файлов базы на диске.
Со временем индексы в PostgreSQL фрагментируются и начинают неэффективно использовать дисковое пространство. Традиционная команда REINDEX блокирует запись в таблицу, что парализует работу пользователей 1С.
Начиная с PostgreSQL 12, у нас появился отличный современный инструмент — переиндексация "на лету" с помощью опции CONCURRENTLY. Мы можем выполнять перестройку индексов в фоновом режиме, не прерывая рабочий процесс предприятия:
-- Пример запуска фоновой переиндексации таблицы журнала документов
REINDEX TABLE CONCURRENTLY _DocumentJournal333;
Если же ваша версия PostgreSQL ниже 12-й, либо вы хотите максимально автоматизировать борьбу с раздуванием индексов и таблиц без блокировок, настоятельно рекомендуем использовать внешнюю консольную утилиту pg_repack. Она создает копию таблицы, переносит туда данные, синхронизирует изменения и подменяет оригинал на лету без установки эксклюзивной блокировки.
Создание бэкапов выгрузкой в файл .dt средствами 1С или регулярное использование утилиты pg_dump — это вчерашний день, несущий огромные риски для крупного бизнеса. Во-первых, создание логического дампа создает колоссальную нагрузку на дисковую подсистему и процессор во время работы пользователей. Во-вторых, восстановить базу из дампа объемом более 100 ГБ может занять критически много времени.
Современным стандартом администрирования PostgreSQL в связке с 1С является непрерывное архивирование журналов транзакций (WAL) и создание физических резервных копий. Для этого используются специализированные бесплатные инструменты с открытым исходным кодом:
Использование физического резервного копирования дает нам важнейшую технологию — Point-In-Time Recovery (PITR). С ее помощью мы можем восстановить состояние нашей 1С:ERP на любую секунду в прошлом. Например, если бухгалтер по ошибке запустил разрушительную обработку в 14:15:30, мы можем откатить базу ровно на состояние 14:15:29, минимизировав потери рабочих данных.
Не забывайте регулярно проводить процедуру тестирования бэкапов. Настройте тестовый контур, куда автоматически раз в неделю будет разворачиваться и проверяться на целостность копия вашей рабочей базы 1С.
Если вы до сих пор используете Windows Server 2008 R2 (как автор темы на форуме), настоятельно рекомендуем рассмотреть миграцию на современные операционные системы семейства Linux (Astra Linux, RED OS, Ubuntu, Debian).
PostgreSQL исторически разрабатывался под UNIX-подобные системы и функционирует на Linux значительно эффективнее благодаря более совершенной модели управления процессами и кэшированием страниц оперативной памяти.
Кроме того, стандартная "ванильная" сборка PostgreSQL плохо справляется со специфическими запросами платформы 1С. Для промышленной эксплуатации обязательно используйте специализированные дистрибутивы:
В эти дистрибутивы разработчики интегрируют уникальные патчи, которые оптимизируют планировщик под запросы 1С, ускоряют работу с временными таблицами (например, за счет параметра skip_temp_rel_lock, исключающего лишние блокировки метаданных) и корректно сопоставляют типы данных платформы.
Часто причиной микрозадержек и "подвисаний" интерфейса 1С является динамическое энергосбережение сервера. По умолчанию операционные системы и BIOS серверов стараются экономить электричество, понижая частоты ядер процессора при отсутствии постоянной нагрузки.
Для СУБД это губительно. Запрос от 1С выполняется за миллисекунды, и процессор просто не успевает поднять тактовую частоту ядра, выполняя задачу на минимальной мощности. Чтобы избежать этого:
Выполнив эти простые и понятные действия по глубокой настройке, вы превратите стандартную базу данных в стабильную, отказоустойчивую систему, готовую к любым пиковым нагрузкам вашего предприятия.