Проблема медленного сохранения конфигурации (когда процесс после нажатия на кнопку с иконкой дискеты занимает 15–20 минут и более) часто встречается в крупных внедрениях, таких как 1С:Бухгалтерия предприятия КОРП 3.0. Особенно остро это ощущается на платформе 8.3.25 и выше, когда объем файла конфигурации cf превышает 2 Гб. В этой статье мы подробно разберем, почему это происходит, как диагностировать узкие места в инфраструктуре и какие настройки SQL Server помогут сократить время ожидания.
Первым делом проанализируем объем данных. В типовой конфигурации БП 3.0 КОРП файл конфигурации обычно весит около 1–1.2 Гб. Если ваш cf-файл разросся до 2.5 Гб, это свидетельствует о наличии избыточных данных. Рассмотрим основные причины такого роста:
Для начала попробуем выполнить простое действие: выгрузим информационную базу в файл .dt и загрузим ее обратно в пустую базу SQL. Этот процесс полностью пересобирает внутренние таблицы, включая таблицу Config, и зачастую позволяет существенно уменьшить размер конфигурации за счет удаления неиспользуемых фрагментов данных.
Когда мы нажимаем «сохранить», 1С записывает огромный объем двоичных данных (LOB — Large Objects) в таблицу Config. Если этот процесс идет медленно, необходимо проверить состояние таблицы на уровне СУБД. Выясним причину задержки с помощью диагностических запросов.
Рассмотрим запрос, который позволяет оценить структуру и размер хранимых данных в конфигурации:
SELECT [FileName]
,[Creation]
,[Modified]
,[Attributes]
,[DataSize]
,[BinaryData]
,[PartNo]
FROM [название_вашей_базы].[dbo].[Config]
ORDER BY [DataSize] DESC
Если запрос выполняется долго или вы видите огромные значения в поле DataSize, это подтверждает проблему записи тяжелых объектов. Также проанализируем скорость записи, выполнив тестовое обновление (ВНИМАНИЕ: делайте это только на копии базы!):
UPDATE [название_вашей_базы].[dbo].[Config]
SET [BinaryData] = [BinaryData]
WHERE [FileName] = 'some_large_file_name'
Если такая операция занимает значительное время, проблема кроется в производительности дисковой подсистемы SQL-сервера или настройках логирования.
Проанализируем настройки SQL Server, которые напрямую влияют на скорость работы с конфигурацией:
Full, каждое сохранение конфигурации (2.5 Гб) полностью дублируется в лог транзакций (.ldf). Попробуем временно переключить базу в модель Simple для проверки скорости. Если это помогает, значит, узкое место — запись лога.Max Degree of Parallelism = 1. При записи больших двоичных данных SQL может пытаться распараллелить процесс, что приводит к внутренним блокировкам типа LATCH.Config подвержена сильной фрагментации. Обычная переиндексация может быть неэффективна для полей varbinary(max). Выполним полную пересборку индексов:
ALTER INDEX ALL ON Config REBUILD;
Даже при наличии сети 25 Гбит, задержки могут возникать на уровне протоколов. Рассмотрим ситуацию, когда сервер 1С и SQL разнесены по разным машинам. Выясним причину, сравнив время сохранения локально на сервере и удаленно. Если на сервере процесс идет быстрее (как в нашем примере — 14 минут против 18), стоит обратить внимание на следующие настройки:
Shared Memory. Это позволит передавать данные напрямую через оперативную память, минуя сетевой стек.Также критически важно проверить дисковые очереди. Используем Системный монитор (PerfMon). Если во время сохранения очередь к диску, где лежат файлы базы данных или временные файлы 1С, превышает значение 2, это явный признак того, что дисковая подсистема не справляется. Рекомендуется использовать NVMe SSD для размещения базы и особенно для папки временных файлов %TEMP%, так как Конфигуратор активно кэширует данные при сборке cf-файла.
Проанализируем работу антивируса на сервере. В момент сохранения 1С создает тысячи мелких временных файлов. Если антивирус настроен на сканирование каждого изменяемого файла, это может замедлить процесс в несколько раз. Добавим в исключения антивируса следующие объекты:
C:\Program Files\1cv8\srvinfo).%TEMP%, AppData\Local\Temp).rphost.exe, 1cv8.exe, 1cv8c.exe..1cd, .vrs, .grs, .tmp.Подводя итог, если ваша конфигурация сохраняется 18 минут, выполним следующие шаги в указанном порядке:
cf и при необходимости выполним цикл выгрузка/загрузка .dt для очистки метаданных.MAXDOP = 1, проверим шаг роста лога транзакций (он не должен быть маленьким, лучше установить фиксированные 512 Мб или 1 Гб).Соблюдение этих рекомендаций позволяет сократить время сохранения «тяжелых» конфигураций с десятков минут до приемлемых 2-3 минут даже для таких объемных решений, как БП КОРП.