Приветствуем вас, коллеги! Сегодня мы детально разберем крайне распространенную и весьма болезненную проблему, с которой сталкиваются системные администраторы и специалисты 1С при развертывании тяжелых типовых конфигураций в терминальной среде (RDS/RDP). Речь идет о ситуации, когда процессы «1С:Предприятие» начинают лавинообразно поглощать оперативную память на сервере терминалов, забирая по 4 ГБ и более на каждого активного пользователя. Выясним причины такого поведения системы, проанализируем узкие места архитектуры и рассмотрим по шагам несколько эффективных методов борьбы с прожорливостью платформы, начиная от простых оптимизаций настроек и заканчивая архитектурными изменениями.
Для начала давайте разберемся, почему возникает такая ситуация. В рассматриваемом нами кейсе используется конфигурация «1С:Комплексная автоматизация 2» (КА2), работающая в файловом режиме внутри терминальной сессии (RDP). Это классический пример «гремучей смеси» для инфраструктуры по следующим причинам:
dbeng8 непосредственно внутри своего процесса. Каждый запущенный сеанс пользователя вынужден самостоятельно обрабатывать таблицы базы данных, кэшировать индексы и выполнять тяжелые запросы в рамках своей изолированной сессии, дублируя одни и те же данные в ОЗУ сервера.Рассмотрим подробнее наиболее эффективный промежуточный вариант, который не требует покупки дорогостоящей лицензии на сервер «1С:Предприятие», но кардинально решает проблему потребления оперативной памяти в терминале. Это публикация файловой базы на веб-сервере (IIS или Apache) и последующее подключение через тонкий клиент.
Что происходит при такой схеме работы?
1cv8.1cd переносится на веб-сервер. Запросы к базе данных выполняет один процесс веб-сервера (например, пул приложений w3wp.exe для IIS).1cv8c.exe. Он не содержит в себе СУБД dbeng8, не кэширует таблицы локально и занимается исключительно отрисовкой интерфейса (форм «Такси»).Разберем по шагам, как выполнить публикацию на примере веб-сервера IIS:
http://имя_сервера/имя_публикации.Выясним причину, почему для тяжелых конфигураций уровня КА2 и ERP файловый вариант в принципе считается компромиссным и нежелательным. Переход на полноценную клиент-серверную архитектуру (MS SQL Server, PostgreSQL) полностью разделяет уровни представления и базы данных.
При переходе на SQL:
rphost.exe) и сервером СУБД. На терминальном сервере пользователи работают через тонкий клиент, потребляющий минимум памяти.rphost в настройках соответствующих утилит администрирования.Проанализируем ситуацию, когда переход на веб-сервер или SQL по каким-то причинам откладывается. Что можно сделать в настройках самой 1С для снижения нагрузки? Одной из главных причин утечек памяти является механизм полнотекстового поиска (ППД).
По умолчанию система регулярно индексирует все данные для быстрого поиска по всей базе. В файловом режиме это создает огромную нагрузку на ОЗУ. Выполним оптимизацию:
В процессе активной работы пользователей в конфигурации КА2 платформа активно кэширует конфигурацию, метаданные и элементы интерфейса на диске и в оперативной памяти. Со временем кэш 1С повреждается или разрастается до гигантских размеров, что приводит к утечкам ОЗУ. Процесс 1С начинает забирать все больше памяти без видимых причин.
Для решения этой проблемы мы рекомендуем настроить автоматическую очистку кэша. Рассмотрим пример PowerShell-скрипта, который можно запускать по расписанию (например, каждую ночь) или при выходе пользователя из терминальной сессии (через Logoff-скрипты групповых политик):
# Скрипт очистки временных файлов и кэша 1С для всех пользователей терминала
$UsersPath = "C:\Users"
Get-ChildItem -Path $UsersPath -Directory | ForEach-Object {
$Local1C = Join-Path $_.FullName "AppData\Local\1C\1cv8"
$Roaming1C = Join-Path $_.FullName "AppData\Roaming\1C\1cv8"
# Удаление файлов локального кэша
If (Test-Path $Local1C) {
Get-ChildItem -Path $Local1C -Exclude "profiles" -Recurse -Force | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
}
# Удаление файлов роуминг-кэша
If (Test-Path $Roaming1C) {
Get-ChildItem -Path $Roaming1C -Exclude "profiles" -Recurse -Force | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
}
}
Также в настройках списка информационных баз для каждого пользователя можно прописать дополнительный параметр запуска /ClearCache, который будет автоматически очищать кэш метаданных при каждом запуске программы.
Часто системные администраторы замечают, что даже после закрытия сессий пользователей или перезапуска процессов свободная оперативная память на сервере не возвращается. Windows Server кэширует неактивные страницы памяти, переводя их в режим ожидания (Standby list). Диспетчер задач при этом показывает высокую загрузку памяти.
Для принудительной оптимизации рабочих наборов памяти (Working Sets) процессов и очистки списков ожидания можно использовать бесплатную утилиту от Microsoft — EmptyStandbyList.exe. Настроим ее регулярный запуск через Планировщик задач Windows:
C:\Windows\System32\).EmptyStandbyList.exe с аргументом standbylist.workingsets. Это принудительно заставит операционную систему сбросить неиспользуемую память процессов 1С в файл подкачки, освобождая физическую ОЗУ.Современный интерфейс 1С «Такси» активно использует графические эффекты, сглаживание шрифтов и анимацию. При работе в терминальном режиме через протокол RDP вся отрисовка выполняется процессором сервера, что вызывает дополнительный расход памяти процессами 1cv8.exe из-за особенностей графической подсистемы GDI+.
Выполним следующие шаги для снижения нагрузки на отрисовку:
Подводя итог нашему разбору, отметим: утилизация оперативной памяти процессом файловой 1С в объеме до 4 ГБ при работе с тяжелой конфигурацией КА2 — это ожидаемое архитектурное следствие работы локального СУБД-движка и огромного объема кода метаданных. Наиболее надежным, масштабируемым и правильным решением является публикация информационной базы на веб-сервере IIS или Apache для работы через легкий тонкий клиент, либо полноценная миграция на клиент-серверную архитектуру с использованием SQL. Побочные методы оптимизации (чистка кэша, отключение ППД и регламентных заданий) помогут временно сгладить острые углы, но в долгосрочной перспективе не заменят грамотного архитектурного разделения слоев приложения.