Рассмотрим классическую, но от этого не менее болезненную проблему: сервер с 1С:Предприятие x64 и СУБД PostgreSQL начинает жутко тормозить. При этом стандартный мониторинг ресурсов вводит в заблуждение — процессор (CPU) занят всего на 20–30%, оперативная память (ОЗУ) заполнена максимум на 70%, но работа пользователей практически парализована. Главный маркер проблемы — огромная очередь к дисковой подсистеме, которая регулярно скачет до 5–10 и более, а процессы rphost раздуваются в памяти до 10 ГБ и выше.
Ситуация осложняется тем, что на сервере крутится 19 баз данных (среди которых тяжелые конфигурации «1С:Бухгалтерия 3.0», «1С:ЗУП» и отраслевые «1С:Альфа-Авто»), общее число сеансов достигает 50, а используемая лицензия 1С класса ПРОФ накладывает жесткие ограничения на масштабирование и управление рабочими процессами.
В этой статье мы подробно проанализируем причины возникновения «узкого горлышка» и разберем по шагам эффективные методы оптимизации системы без необоснованных финансовых затрат.
---
Для начала проанализируем, почему при свободных ресурсах процессора и памяти система демонстрирует крайне низкую производительность. Здесь сходятся сразу несколько негативных факторов:
rphost, что вызывает их лавинообразное раздувание.fork). В операционной системе Windows этот механизм эмулируется, что приводит к повышенному потреблению памяти на каждое соединение, утечкам виртуальной памяти и неоптимальному кэшированию файлов.rphost. Это связано с колоссальным объемом метаданных конфигурации на интерфейсе «Такси». Единожды построив тяжелый отчет или запустив закрытие месяца, процесс rphost кэширует эти данные и неохотно возвращает оперативную память операционной системе.---
Поскольку мы не можем использовать КОРП-функцию «одна информационная база — один рабочий процесс», нам необходимо заставить платформу 1С своевременно высвобождать память и распределять нагрузку по процессам другими доступными способами.
Выполним оптимизацию настроек нашего локального кластера 1С:
86400 секунд (24 часа) или даже 43200 секунд (12 часов) для высоконагруженных систем. Это позволит платформе в фоновом режиме запускать новые чистые процессы rphost, плавно переводить туда новые сеансы пользователей, а старые «раздувшиеся» процессы мягко завершать без прерывания работы.rphost будет помечен как выключаемый. Рекомендуется установить значение исходя из общего объема ОЗУ на сервере, деленного на предполагаемое количество рабочих процессов.ragent запустить не 1-2 процесса rphost, а, к примеру, 4–6 процессов, что распределит нагрузку более равномерно и снизит риск падения всего сервера при зависании одного из процессов.---
Если конфигурации баз данных сильно отличаются по своей специфике (например, оперативная «Альфа-Авто» с интенсивным вводом документов и расчетная «1С:ЗУП» с тяжелыми регламентными расчетами), имеет смысл изолировать их друг от друга.
Для этого в консоли администрирования 1С мы можем создать несколько отдельных кластеров в рамках одного сервера (запустив их на разных сетевых портах, например, 1541, 1641 и т.д.).
Такое разделение гарантирует, что регламентные операции или тяжелые отчеты бухгалтеров в одном кластере никак не повлияют на стабильность работы менеджеров и мастеров-приемщиков в другом, так как процессы rphost разных кластеров полностью изолированы на уровне операционной системы.
---
Никакая программная оптимизация не поможет, если дисковая подсистема физически не справляется с потоком транзакций. Системным администраторам необходимо категорически отказаться от идеи использования классических HDD (SAS/SATA) под базы данных СУБД.
При выборе накопителей необходимо руководствоваться следующими правилами:
---
Для достижения максимальной производительности СУБД PostgreSQL рекомендуется развернуть на виртуальной или физической машине под управлением Linux (например, Ubuntu, Debian, Rocky Linux или Astra Linux).
Даже если сам Сервер 1С останется работать на Windows-машине (например, из-за специфических COM-соединений или ключей защиты), вынос «слона» на Linux-платформу даст колоссальный прирост скорости работы с памятью и диском благодаря нативной поддержке процессной модели.
Если перенос на Linux временно невозможен, и СУБД остается на Windows, обязательно скорректируем настройки в конфигурационном файле postgresql.conf:
# Пример базовой настройки параметров в postgresql.conf для работы 1С на SSD
# Стоимость случайного чтения. Для SSD снижаем с 4.0 до 1.1 - 1.3
random_page_cost = 1.1
# Ограничение на количество одновременно открытых файлов ОС (актуально для Windows)
max_files_per_process = 8000
# Объем разделяемой памяти для кэширования данных СУБД (рекомендуется около 25% от доступной ОЗУ)
shared_buffers = 8GB
# Оценка размера кэша операционной системы (устанавливаем 50-75% от общего объема ОЗУ)
effective_cache_size = 24GB
# Настройки агрессивного автовакуума для своевременной очистки временных таблиц 1С
autovacuum_max_workers = 4
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.05
Разберем подробнее влияние параметра random_page_cost. По умолчанию он равен 4.0, что оптимизировано под медленный поиск головок HDD. Снижая его до 1.1 при переходе на SSD, мы сообщаем планировщику запросов PostgreSQL, что случайное чтение теперь происходит практически мгновенно. Это заставляет СУБД гораздо чаще использовать эффективное чтение по индексам вместо медленного полного сканирования таблиц (Seq Scan).
---
Если используется версия PostgreSQL до 14 включительно, СУБД генерирует огромный поток мелких транзакций записи при ведении статистики в каталоге pg_stat_tmp. Это нагружает дисковую подсистему и сокращает ресурс SSD.
Для решения этой проблемы перенесем данную директорию на RAM-диск (виртуальный диск, созданный непосредственно в оперативной памяти сервера, например, с помощью бесплатной утилиты ImDisk):
postgresql.conf найдем параметр stats_temp_directory и укажем путь к нашему RAM-диску:
stats_temp_directory = 'R:/pg_stat_tmp'
Примечание: Если используется PostgreSQL 15 и выше, данный шаг выполнять не требуется, так как разработчики СУБД перенесли хранение статистики в общую оперативную память по умолчанию.
---
В высоконагруженных системах совмещение роли Терминального сервера (где пользователи запускают тонкие/толстые клиенты 1С и офисные программы) и СУБД с Сервером 1С на одной физической машине неизбежно приводит к конфликтам за ресурсы.
Проанализируем оптимальную схему распределения нагрузки:
Такой подход полностью изолирует пользовательские сессии от тяжелых транзакционных процессов баз данных и гарантирует максимальную отзывчивость интерфейса 1С.