← На главную

Многие администраторы и разработчики 1С сталкиваются с парадоксальной ситуацией: одна и та же конфигурация в файловом варианте выгружается в файл .cf буквально за пару минут, а после перевода на клиент-серверный режим процесс растягивается на десятки минут или даже часы. Рассмотрим подробнее, почему это происходит, разберем внутренние механизмы платформы и проанализируем пошагово, как можно диагностировать и устранить эту задержку.

Различие механизмов работы в файловом и клиент-серверном вариантах

Для начала проанализируем ситуацию: почему возникает такая разница в скорости? В файловом варианте Конфигуратор работает с базой данных (файлом 1Cv8.1CD) напрямую. Чтение метаданных происходит локально, без посредников, что минимизирует задержки на передачу данных.

В клиент-серверном варианте цепочка значительно усложняется. Процесс выглядит следующим образом: SQL Server считывает данные из таблиц конфигурации, передает их рабочему процессу сервера 1С (rphost), который выполняет сериализацию данных (упаковку в специфический формат) и передает их клиенту — Конфигуратору. Если файл конфигурации имеет значительный объем (например, 1.2 Гб), объем данных, передаваемых между процессами, может кратно возрастать из-за особенностей XML-разметки и бинарных потоков внутри транспортного протокола 1С.

Проверка разрядности платформы и использования оперативной памяти

Выясним причину, связанную с ресурсами сервера. В обсуждении было отмечено, что на сервере установлено 224 Гб ОЗУ, а платформа используется 64-разрядная. Это правильная конфигурация, однако стоит проверить настройки кластера 1С. Разберем, на что обратить внимание:

1. Лимиты памяти рабочих процессов: В настройках кластера могут быть установлены ограничения на «Безопасный расход памяти за один вызов» или «Максимальный объем памяти рабочих процессов». Если процесс формирования .cf упирается в эти лимиты, сервер начинает принудительно сбрасывать данные в своп на диск или перезапускать рабочие потоки, что катастрофически замедляет выгрузку.
2. Утечки в конкретных релизах: Как отмечалось в сообщениях форума, существуют релизы платформы 8.3, в которых работа с большими файлами конфигурации содержит внутренние ошибки оптимизации. Рекомендуется протестировать процесс на более свежем или, наоборот, проверенном стабильном релизе.

Оптимизация взаимодействия SQL Server и сервера 1С: Shared Memory

Посмотрим на ситуацию, когда SQL Server и сервер приложений 1С находятся на одной физической машине. В этом случае критически важно убедиться, что они общаются через протокол Shared Memory (общая память), а не через сетевой стек TCP/IP. Использование TCP/IP даже на локальной петле (localhost) создает лишнюю нагрузку на сетевые драйверы ОС.

Для проверки и настройки выполним следующие действия в SQL Server Configuration Manager:

1. Перейдем в раздел SQL Server Network Configuration -> Protocols for MSSQLSERVER.
2. Убедимся, что протокол Shared Memory включен (Enabled).
3. В настройках подключения на стороне 1С (в консоли администрирования) убедимся, что в качестве имени сервера указано локальное имя, позволяющее использовать этот протокол.

Влияние временных файлов и дисковой подсистемы

Проанализируем работу сервера 1С с файловой системой. Во время формирования файла .cf сервер активно создает тысячи временных файлов. Эти файлы обычно располагаются в каталоге профиля пользователя, под которым запущена служба 1С (например, AppData\Local\Temp).

Важные моменты для проверки:

1. Накопление мусора: Если в папке Temp скопились сотни тысяч старых файлов, создание новых объектов операционной системой замедляется. Очистим содержимое временных папок.
2. Дедупликация и сжатие: Если диск, на котором расположены временные папки, сильно фрагментирован или на нем включено сжатие данных (NTFS Compression), скорость записи упадет в разы.
3. Антивирусное сканирование: Даже если антивирус формально отключен, его драйверы фильтрации (minifilters) могут перехватывать обращения к каждому мелкому временному файлу. Необходимо добавить в исключения процессы rphost.exe, sqlservr.exe, а также расширения .cf, .сfы и сами каталоги временных файлов.

Настройка параллелизма в SQL Server (MAXDOP)

Разберем еще один глубокий технический аспект — параметр Max Degree of Parallelism. При выгрузке метаданных сервер 1С генерирует множество мелких запросов к системным таблицам Config и ConfigCashe.

Если в SQL Server параметр MAXDOP настроен некорректно (например, установлен в 0 на многоядерном сервере), SQL Server может пытаться распараллелить каждый микро-запрос. Затраты на координацию потоков (Parallelism Overhead) в этом случае превышают пользу от параллельного выполнения, что приводит к значительным задержкам. Для работы с 1С часто рекомендуют устанавливать значение 1, 2 или 4, в зависимости от общего количества ядер и нагрузки.

Фрагментация системных таблиц метаданных

В отличие от файловой базы, где «сжатие» и «тестирование и исправление» (ТИИ) пересобирают структуру файла, в клиент-серверном варианте таблицы метаданных внутри SQL могут быть сильно фрагментированы. Проанализируем состояние таблиц Config, ConfigCashe и BinaryData. Рекомендуется выполнить регламентную операцию Rebuild Index (перестроение индексов) именно для этих системных таблиц. Это может существенно ускорить чтение конфигурации сервером 1С.

Диагностика через «чистую базу»

Чтобы исключить влияние конкретной конфигурации (ее размера и сложности), выполним диагностический эксперимент, предложенный в обсуждении:

1. Создадим пустую информационную базу в том же кластере 1С и на том же экземпляре SQL Server.
2. Попробуем выгрузить из нее пустой файл .cf.
3. Если пустая база выгружается мгновенно, значит, проблема в объеме данных или состоянии таблиц конкретной рабочей базы. Если даже пустая база выгружается долго — проблема в сетевых настройках, протоколах взаимодействия или антивирусном ПО.

Влияние RDP и графической подсистемы

В некоторых случаях (хоть это и кажется маловероятным) работа через RDP может замедлять отрисовку прогресс-бара в Конфигураторе, что косвенно влияет на цикл обработки сообщений приложения. Попробуем отключить кэширование графики (Bitmap Caching) в настройках RDP-клиента или запустить выгрузку непосредственно на консоли сервера, чтобы исключить этот фактор.

Резюмируя: медленная выгрузка .cf в клиент-серверном режиме — это комплексная проблема, которая чаще всего решается настройкой протокола Shared Memory, очисткой временных папок сервера 1С и настройкой исключений антивируса. Выполнение этих шагов позволит сократить время ожидания с часов до минут, вернув производительность к показателям, близким к файловому режиму.