← На главную
Ситуация, когда после обновления операционной системы до Windows Server 2012 и переноса файловой базы на быстрый твердотельный накопитель производительность платформы 1С не увеличивается, а резко падает, встречается регулярно. Особенно остро деградация быстродействия проявляется на тяжелых расчетных задачах — групповом перепроведении документов и закрытии месяца в бухгалтерских конфигурациях. Разберем по шагам скрытые механизмы операционной системы, архитектурные ограничения и настройки, влияющие на скорость работы пользователей в терминальном режиме.
Совмещение роли контроллера домена (Active Directory) и терминального сервера
Одной из ключевых причин резкой просадки дисковой подсистемы является назначение сервера терминалов контроллером домена (Active Directory Domain Controller). Проанализируем, как это устроено внутри Windows Server:
- Автоматическое отключение кэширования записи дисков: В целях предотвращения повреждения базы данных Active Directory при аварийном отключении питания операционная система принудительно отключает кэширование записи для всех физических дисков контроллера домена. Даже если включить флажок кэша вручную в диспетчере устройств, политика безопасности операционной системы сбрасывает эту настройку после перезагрузки.
- Удар по операциям случайной записи: При отключенном кэше контроллер накопителя вынужден подтверждать каждую операцию записи непосредственно на физические пластины или микросхемы флеш-памяти. В результате производительность операций случайного доступа, которыми оперирует платформа 1С, падает в разы.
- Решение по изоляции ролей: Разделим роли. Контроллер домена ни при каких условиях не должен размещаться на одном хосте с терминальным сервером и файловой базой. Если в инфраструктуре присутствует только один физический сервер, развернем роль Hyper-V и вынесем контроллер домена в изолированную компактную виртуальную машину, оставив хост или вторую виртуальную машину под терминальные сессии пользователей с полностью активным дисковым кэшированием.
Управление электропитанием процессора и парковка ядер
По умолчанию в Windows Server 2012 активирован сбалансированный план электропитания (Balanced), который ведет себя крайне неэффективно по отношению к однопоточным нагрузкам платформы 1С. Выясним причину этой проблемы:
- Сброс тактовой частоты: Планировщик электропитания снижает базовую частоту современных серверных процессоров до минимальных значений при отсутствии высокой загрузки всех ядер. В моменты, когда бухгалтер выполняет расчет в одном потоке, операционная система не успевает мгновенно повысить частоту, в результате чего процессор выполняет операции на частотах уровня 700–1200 МГц вместо паспортных 3.5–4.0 ГГц.
- Механизм Core Parking (парковка ядер): Планировщик отправляет простаивающие физические ядра в состояния глубокого сна C-States. При резком поступлении пакета запросов от сеанса 1С возникают микрозадержки на пробуждение ядер.
- Настройка максимальной производительности: Переключим схему электропитания операционной системы на профиль Высокая производительность (High Performance). Дополнительно проверим параметры BIOS/UEFI сервера и отключим технологии глубокого энергосбережения процессора (C-States, C1E, EIST), зафиксировав максимальную рабочую частоту на всех ядрах.
Очереди к системному диску и каталоги временных файлов
Даже если основной файл базы данных расположен на выделенном SSD, платформа 1С в терминальном режиме генерирует огромный поток мелких временных файлов на системном диске, где расположены профили пользователей. Рассмотрим подробнее этот аспект:
- Локализация временных данных: Каждый запущенный терминальный сеанс активно производит запись в системные каталоги
%TEMP%, %TMP% и пользовательские ветки %APPDATA%. Если системный раздел находится на жестком диске (SAS/SATA HDD) без кэша записи, двадцать параллельно работающих пользователей полностью парализуют дисковую подсистему. Средняя длина очереди к диску при этом превышает допустимые значения, вызывая зависание интерфейса. - Перенос каталогов Temp: Настроим системные переменные среды
TEMP и TMP, перенаправив их на отдельный высокоскоростной SSD-накопитель либо на специально созданный RAM-диск в оперативной памяти сервера. Это разгрузит системный диск от паразитной нагрузки.
Влияние подсистемы Fair Share в службах RDS Windows Server 2012
В Windows Server 2012 была внедрена подсистема динамического распределения ресурсов Fair Share (Fair Share CPU, Fair Share Disk, Fair Share Network). Разберем, как она влияет на длительные регламентные операции:
- Принудительное дросселирование сессий: Когда один из пользователей запускает групповое перепроведение документов или закрытие месяца, процесс
1cv8.exe генерирует непрерывный поток обращений к диску и процессору. Служба Fair Share расценивает такое поведение сеанса как аномалию и искусственно урезает кванты процессорного времени и дисковой очереди для этой RDP-сессии, чтобы освободить ресурсы для других пользователей. Длительность выполнения расчетной операции возрастает в разы. - Отключение балансировки Fair Share: Отключим параметры Fair Share через локальные групповые политики сервера терминалов либо через системный реестр в ветке службы
TSFairShare, позволив ресурсоемким задачам использовать доступную производительность оборудования без искусственных ограничений. - Исключения антивирусной защиты: Проверим работу антивирусного монитора. Файлы баз данных с расширением
.1CD, каталог с базой, исполняемые файлы платформы и пути к временным папкам пользователей должны быть обязательно внесены в список исключений сканирования в реальном времени, иначе антивирус будет блокировать файловые дескрипторы при каждой транзакции.
Ограничения файловой структуры 1С и пути модернизации
Эксплуатация файловой базы размером более нескольких гигабайт при одновременной работе двадцати пользователей входит в прямое противоречие с архитектурой файлового движка платформы:
- Файловые блокировки операционной системы: В файловом режиме блокировка записей и таблиц выполняется средствами файловой системы. При расчете итогов регистров двадцать подключений конкурируют за монопольный доступ к файлу базы. Возникают каскадные ожидания на уровне системных вызовов ОС.
- Предел внутренних таблиц: Предельный физический объем одной внутренней таблицы в файле формата
1Cv8.1CD составляет 4 ГБ. В базе общего объема 15 ГБ таблицы оборотов и остатков регистров находятся на грани технологического предела, что приводит к деградации построения поисковых индексов. - Публикация на веб-сервере: В качестве промежуточной меры без покупки СУБД опубликуем базу данных на локальном веб-сервере (IIS или Apache). В этом сценарии обращения к файлу базы пойдут монопольно от пула процессов веб-сервера, что снизит число прямых файловых конфликтов между пользователями.
- Профилактика целостности: Выполним регулярное техническое обслуживание структуры: протестируем файл утилитой
chdbfl.exe из каталога bin платформы и запустим в конфигураторе тестирование и исправление с переиндексацией и сжатием таблиц. В долгосрочной перспективе единственным надежным решением для базы такого объема и количества пользователей является переход на клиент-серверный вариант (SQL).