Работа со сверхбольшими конфигурациями 1С (размером около 1 Гб и более, такими как 1С:ERP, 1С:Комплексная автоматизация) накладывает серьезные требования на инфраструктуру разработки. Стандартные механизмы хранилища 1С часто упираются в архитектурные ограничения платформы. Процессы захвата объектов, помещения изменений и формирования снимков конфигурации начинают занимать десятки минут, парализуя работу команды разработчиков.
В этой статье мы подробно разберем, почему тормозит хранилище 1С, проанализируем неочевидные узкие места и по шагам настроим систему для достижения максимального быстродействия.
Основная проблема заключается в том, что платформа 1С при выполнении любых операций с хранилищем (будь то сравнение, захват или помещение объектов) отправляет огромное количество мелких, последовательных и синхронных запросов. Платформа физически не умеет объединять их в один большой пакетный запрос. Из-за этой особенности главным врагом разработчика становится сетевая задержка (пинг), а не пропускная способность канала.
Если пинг между машиной разработчика (или терминальным сервером) и сервером хранилища составляет более 1-2 мс, то выполнение операций превращается в бесконечное ожидание. При пинге в 15-30 мс (например, при работе из дома через VPN) время выполнения стандартных операций возрастает лавинообразно.
Проанализируем самый критичный организационно-технический нюанс работы с хранилищем 1С. Крайне важно, чтобы все без исключения разработчики подключались к хранилищу через сервер хранилища по протоколу TCP (tcp://имя_сервера/имя_хранилища) или HTTP/HTTPS.
Если хотя бы один пользователь подключится к хранилищу напрямую через сетевой файловый путь (\\server\share\repository), операционная система сервера переведет файловый доступ в режим строгих блокировок. В этот момент производительность упадет у всей команды разом. Запретите на уровне сетевых доступов прямое чтение папки хранилища разработчиками, оставив подключение только через службу crserver.exe.
Обычный сетевой пинг маленькими пакетами по умолчанию может показывать стабильные 1 мс. Однако при реальной передаче метаданных конфигурации нагрузка на сеть возрастает. Проверим задержку сети при передаче тяжелых пакетов.
Запустим на машине разработчика командную строку и выполним диагностическую команду с размером пакета 60 000 байт:
ping [IP-адрес_сервера_хранилища] -l 60000 -t
Если при тестировании большими пакетами вы наблюдаете потерю пакетов или рост времени отклика (пинг более 2-3 мс), то сетевое оборудование или настройки виртуализации не справляются с нагрузкой. В этом случае разработку необходимо переносить строго внутрь одного терминального сервера (где Конфигуратор и служба хранилища работают локально).
Операции с метаданными активно задействуют дисковую подсистему на трех узлах: локальной машине разработчика, сервере приложений 1С и сервере, где расположен каталог самого хранилища. Рассмотрим аппаратные требования к серверам:
SSD NVMe (PCIe). Обратите внимание на настройки контроллеров в виртуальной среде (например, VMware или Hyper-V) — задержки на уровне проброса дисков могут свести на нет всю скорость SSD.В процессе длительной разработки на машине пользователя накапливается огромный объем служебной информации хранилища. Локальный кэш версий забивается, и Конфигуратор начинает тратить много времени на обращение к нему.
Для решения этой проблемы выполним очистку кэша по шагам:
C:\Users\<Имя_Пользователя>\AppData\Local\1C\1Cv8\<ID_базы>\cfgrepo.comments, а остальные файлы удалите.Также очистку этого специфического кэша можно выполнять в автоматическом режиме, запуская Конфигуратор из командной строки со специальным ключом:
"C:\Program Files\1cv8\8.3.13.1690\bin\1cv8.exe" DESIGNER /F"C:\PathToLocalDB" /N"Admin" /P"Pass" /ConfigurationRepositoryClearCache
Мало кто знает, что у самого хранилища есть внутренний формат хранения данных, который зависит от режима совместимости, установленного при его создании.
Если хранилище создавалось давно, метаданные хранятся внутри базы 1Cv8.1CD монолитным куском. При изменении любого объекта блокируется вся база хранилища. Переведем хранилище на современный формат:
После этого изменения физическая структура базы хранилища перестроится: объекты метаданных будут разбиты на отдельные файлы во внутренней структуре СУБД, что кардинально снизит уровень блокировок при параллельной работе команды.
Даже если сторонний антивирус не установлен на терминальном сервере, встроенная служба безопасности Windows Defender продолжает сканировать файлы в режиме реального времени. Конфигуратор при сравнении конфигураций создает тысячи мелких временных файлов во временной папке пользователя.
Для предотвращения блокировок дисковой активности добавьте в список исключений антивируса/Defender:
1cv8.exe, 1cv8c.exe, crserver.exe.C:\Users\*\AppData\Local\Temp\ (особенно папки, начинающиеся с v8_).Поскольку хранилище конфигурации работает на базе файловой СУБД 1С, со временем его размер может вырасти до десятков гигабайт из-за многолетней истории изменений. Файловая СУБД 1С крайне плохо переносит большие объемы данных при частой перезаписи модулей.
Рекомендуется раз в полгода или год производить свертку хранилища: создавать абсолютно новое, чистое хранилище из текущей актуальной конфигурации. Старое хранилище при этом переводится в режим "только для чтения" и сохраняется в качестве архива для возможности просмотра истории изменений.
Если после выполнения всех рекомендаций скорость работы не увеличилась, воспользуемся утилитой Process Monitor для локализации проблемы. Запустите утилиту во время долгого захвата объекта в 1С и настройте фильтр по процессу 1cv8.exe. Проанализируйте, на каких операциях (чтение файлов кэша, обращение к сети или запись во временные папки) процесс задерживается дольше всего. Это укажет на конкретную причину медленной работы в вашей инфраструктуре.