В процессе активной разработки и поддержки крупных информационных баз на платформе 1С:Предприятие 8.3 (особенно таких тяжелых решений, как 1С:ERP Управление предприятием, 1С:Комплексная автоматизация или 1С:Управление торговлей) специалисты часто сталкиваются с крайне неприятной проблемой. При попытке выполнить сравнение и объединение конфигураций (например, при обновлении через меню Конфигурация — Поддержка — Настройка поддержки — Сравнить, объединить или при сравнении с внешним файлом .cf) процесс намертво застывает на отметке 0%.
При этом конфигуратор не выдает никаких ошибок, загрузка процессора на сервере может как отсутствовать, так и зашкаливать, а само ожидание может длиться часами без какого-либо результата. В этой статье мы подробно разберем, почему возникает эта техническая неполадка, проанализируем её глубокие системные причины и рассмотрим несколько проверенных способов решения проблемы.
Рассмотрим оригинальное и очень изящное решение, к которому пришел автор обсуждения. Если стандартные методы очистки кэша не помогают, а на другом сервере аналогичная база отрабатывает сравнение корректно, проблема кроется в локальном рассогласовании структуры таблиц конфигурации в СУБД и кэша на конкретном рабочем сервере 1С.
Для того чтобы заставить платформу принудительно и полностью переписать метаданные, выполним следующие шаги:
ОбщаяКартинка.Замок). Внесем в нее незначительное символическое изменение или просто перезахватим объект.F7).Почему это помогает? При получении изменений из Хранилища платформа 1С производит принудительное обновление конфигурации «сверху вниз», полностью перезаписывая внутренние индексы, кэш метаданных и выстраивая заново таблицы связей. После этой процедуры внутренний конфликт структуры устраняется, и процесс сравнения/объединения начинает работать в штатном режиме.
Выясним истинную причину, почему сравнение зависает на 0% в клиент-серверном режиме. Очень часто виной всему становится злоупотребление механизмом динамического обновления (так называемым обновлением «на лету» или «демонами»). При частом применении этого метода в служебных таблицах СУБД накапливается мусор.
В базе данных SQL за хранение конфигурации отвечают таблицы dbo.Config (активная конфигурация) и dbo.ConfigSave (сохраняемая конфигурация). При некорректно завершенных динамических обновлениях в таблице Config зависают служебные записи со специальными именами. Платформа при попытке сравнения натыкается на эти записи, уходит в бесконечный цикл сопоставления версий и зависает.
Чтобы решить эту проблему напрямую через СУБД, выполним очистку данных таблиц с помощью SQL-скрипта (предварительно обязательно создав резервную копию базы данных в SQL Server Management Studio):
-- Очищаем таблицу редактируемой конфигурации, чтобы сбросить несохраненные сессии
DELETE FROM dbo.ConfigSave;
-- Удаляем зависшие записи транзакций динамического обновления из активной конфигурации
DELETE FROM dbo.Config WHERE FileName = 'commit';
DELETE FROM dbo.Config WHERE FileName = 'dynamicCommit';
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal';
После выполнения данного скрипта необходимо в обязательном порядке:
ragent).snccntry и временные файлы в папке сервера приложений reg_1541).Проанализируем технические характеристики серверов, указанные в обсуждении. На проблемном сервере была установлена платформа версии 8.3.15.1565, а на работающем — более свежая 8.3.15.1700. Разница в релизах платформы играет критическую роль.
Стоит помнить, что в старых версиях платформы 1С (включая ветку 8.3.15) клиентское приложение и сам Конфигуратор (1cv8.exe) являлись исключительно 32-разрядными программами, даже если серверная часть была 64-разрядной. Для 32-битного процесса операционная система может выделить максимум 2–3 ГБ оперативной памяти.
При сравнении тяжелых конфигураций (таких как ERP) конфигуратор пытается построить в оперативной памяти гигантское дерево метаданных двух конфигураций одновременно. Память мгновенно заполняется, процесс упирается в лимит, начинает бесконечно вызывать сборщик мусора (Garbage Collector) и фактически застывает на 0% прогресса.
Как решить эту проблему:
.cf. Создадим локальную файловую базу на мощном компьютере разработчика, загрузим туда .cf, выполним сравнение и объединение локально. Полученный результат снова сохраним в .cf и просто загрузим в серверную базу через команду Конфигурация — Загрузить конфигурацию из файла.Кэш сервера приложений 1С и локальный кэш пользователя часто содержат устаревшие или поврежденные схемы метаданных. Разберем по шагам, как правильно произвести тотальную очистку кэша:
Шаг 1. Очистка локального кэша пользователя на компьютере, где запускается Конфигуратор:
%USERPROFILE%\AppData\Local\1C\1Cv8%USERPROFILE%\AppData\Roaming\1C\1Cv88a4f3b2c-901d-...).Шаг 2. Очистка серверного кэша на сервере 1С:Предприятия:
C:\Program Files\1cv8\srvinfo\reg_1541).snccntry (это кэш структур баз данных).Сравнение объектов конфигурации генерирует колоссальное количество мелких сетевых запросов между сервером 1С и СУБД (SQL). Если сервер приложений 1С и сервер SQL разнесены на разные физические машины, сетевые задержки могут приводить к потере пакетов под высокой нагрузкой. Сервер 1С уходит в режим бесконечного ожидания ответа от СУБД, а шкала сравнения застревает на 0%.
Рекомендуется проверить настройки сетевых карт на обоих серверах и отключить технологии оптимизации трафика, которые часто некорректно работают с СУБД:
Large Send Offload V2 (IPv4) и Large Send Offload V2 (IPv6) в дополнительных свойствах сетевой карты.
netsh int tcp set global chimney=disabled
Эти меры значительно повысят стабильность передачи мелких пакетов данных между сервером приложений 1С и сервером баз данных SQL, предотвращая зависание сетевых сокетов процессов rphost во время выполнения тяжелых операций сравнения метаданных.