Сценарий бухгалтерского аутсорсинга, когда небольшое число сотрудников (4–6 пользователей) ведет несколько десятков информационных баз «1С:Бухгалтерия 3.0» и «1С:Зарплата и управление персоналом 3.1», обладает уникальной спецификой нагрузки. Очень часто администраторы сталкиваются с ситуацией: пользователей в системе мало, активных транзакций минимум, но процессор сервера загружен на 100%, интерфейс зависает, а проведение документов замедляется в разы.
В этой статье мы подробно разберем, почему возникает такая проблема, как оптимизировать платформу 1С:Предприятие 8.3 и СУБД PostgreSQL, а также какие аппаратные характеристики сервера критически важны для быстрой и стабильной работы.
Проанализируем механику работы современных типовых конфигураций. В конфигурациях БП 3.0 и ЗУП 3.1 по умолчанию активированы десятки регламентных и фоновых заданий. В их число входят:
1С:Контрагент и 1С:СПАРК Риски.Когда на сервере развернута одна база, регламентные задания выполняются практически незаметно. Однако при наличии 36 баз эти задачи начинают запускаться параллельно во всех информационных пространствах. Каждый запуск порождает отдельный фоновый сеанс и рабочий процесс rphost. В результате 36 баз одновременно пытаются выполнить тяжелые расчеты и дисковые операции, полностью утилизируя ресурсы даже мощного многоядерного процессора.
Рассмотрим комплекс мер по снижению паразитной фоновой нагрузки без ущерба для бухгалтерского учета.
Шаг 1. Блокировка фоновых заданий для архивных и неактивных баз.
Если часть баз используется только для чтения, сдачи редкой отчетности или хранения архивов прошлых периодов, в них необходимо полностью заблокировать выполнение регламентных процессов. Для этого воспользуемся консолью администрирования кластера серверов 1С:Предприятие:
Scheduled jobs denied).rphost.Шаг 2. Отключение второстепенных регламентных заданий в рабочих базах.
В активных базах перейдем в раздел Администрирование — Обслуживание — Регламентные операции — Регламентные и фоновые задания и настроим расписание:
Шаг 3. Ограничение ресурсов на уровне кластера 1С.
Для предотвращения утечек памяти и чрезмерного разрастания процессов настроим параметры рабочего сервера в консоли кластера 1С:
Memory Limit), чтобы платформа своевременно перезапускала неактивные процессы rphost.Разберем требования к аппаратному обеспечению под связку 1С + PostgreSQL для компании аутсорсинга.
1. Процессор (CPU): Частота критичнее количества ядер!
Платформа 1С выполняет большинство тяжелых бизнес-алгоритмов (проведение документов, закрытие периода, расчет себестоимости, расчет страховых взносов) в однопоточном режиме. Если процессор имеет много ядер, но низкую базовую частоту (например, старые серверные процессоры уровня 2.0–2.4 ГГц), 1С будет сильно тормозить.
2. Оперативная память (RAM).
Для одновременного функционирования 36 баз оперативная память является ключевым буфером:
rphost, пулом соединений СУБД PostgreSQL и дисковым кэшем операционной системы. Чем больше страниц баз данных находится в кэше RAM, тем меньше обращений идет к физическим дискам.3. Дисковая подсистема (Storage).
Использование обычных пользовательских (Consumer) SSD для десятков баз 1С недопустимо: при одновременной фоновой записи они быстро исчерпывают ресурс, перегреваются и сбрасывают скорость (троттлинг), а при отключении питания могут повредить базу СУБД.
Power Loss Protection — PLP), например серии Samsung PM9A3, Micron или Kingston DC.Для корректной работы 1С с СУБД PostgreSQL необходимо использовать специализированную сборку с патчами от фирмы «1С» или «Postgres Pro 1C». Стандартная сборка PostgreSQL не оптимизирована для специфики генерации SQL-запросов платформой 1С.
Рассмотрим ключевые параметры файла postgresql.conf, которые необходимо настроить:
Посмотрим на пример базовой конфигурации для сервера с 64 ГБ оперативной памяти:
# Объем памяти под общие буферы (около 25% от всей RAM)
shared_buffers = 16GB
# Оценка доступного кэша операционной системы (50-75% от RAM)
effective_cache_size = 48GB
# Память для сложных операций сортировки и группировки
work_mem = 64MB
# Память для операций обслуживания (автовакуум, создание индексов)
maintenance_work_mem = 2GB
# Стоимость случайного чтения для быстрых NVMe SSD
random_page_cost = 1.1
# Оптимизация автовакуума для множества активных таблиц
autovacuum_max_workers = 4
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
Разберем, почему эти параметры важны:
random_page_cost = 1.1 указывает планировщику запросов, что сервер использует быстрые твердотельные накопители. По умолчанию в PostgreSQL стоит значение 4.0 (рассчитанное на медленные HDD), из-за чего планировщик часто игнорирует индексы 1С и выполняет полное сканирование таблиц (Seq Scan).autovacuum не позволяет накопиться устаревшим «мертвым» строкам (Dead Tuples), что критично при постоянной перезаписи данных в десятках баз.Если бюджет на закупку и администрирование собственного сервера ограничен, проанализируем две эффективные альтернативы:
Для 36 типовых баз и 5 пользователей облачный сервис 1С:Фреш является одним из наиболее экономически выгодных решений. В облаке автоматическое обновление баз, резервное копирование и распределение нагрузки берет на себя провайдер. Это полностью избавляет от необходимости приобретать серверное железо и оплачивать услуги системного администратора.
Вместо создания 36 изолированных баз данных конфигурация «1С:Бухгалтерия 3.0» позволяет включить механизм разделения данных. В этом случае все 36 организаций работают в одной физической информационной базе, но данные каждого клиента полностью изолированы. Нагрузка на процессор снижается в десятки раз, так как все фоновые регламентные задания выполняются единожды, а не дублируются 36 раз.
PostgreSQL для 1С и скорректировать параметры буферов и стоимости чтения под SSD-диски.