Обновление 1С идёт часами: где теряется время и как его вернуть

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

Частое заблуждение — «обновление тормозит, потому что слабый компьютер бухгалтера». На практике время чаще съедают сетевая папка с файловой базой, антивирус, проверяющий каждый файл, и многогигабайтный журнал регистрации. Новый процессор тут не поможет, а перенос базы на локальный диск — поможет сразу.

Где теряется время: диагностика этапов обновления

Обновление 1С состоит из трёх этапов. Засеките каждый отдельно, иначе вы будете лечить не то.

Как измерить

1. Запустите обновление через командную строку с ключом /Out — в лог попадут время начала и конца операций конфигуратора.
2. На этапе реструктуризации откройте «Монитор ресурсов» Windows. Если диск загружен на 100%, а процессор на 10–15%, упираетесь в диск.
3. Для SQL-базы смотрите «Монитор активности» SQL Server: какой запрос идёт дольше всего и на какой таблице.
4. На третьем этапе загляните в журнал регистрации: события обновления информационной базы показывают, какой обработчик шёл дольше.

Чтобы понять, какие таблицы самые тяжёлые, в MS SQL выполните стандартный запрос:

SELECT TOP 20 t.name AS table_name,
       SUM(p.row_count) AS rows_cnt,
       SUM(p.reserved_page_count) * 8 / 1024 AS size_mb
FROM sys.dm_db_partition_stats p
JOIN sys.tables t ON t.object_id = p.object_id
WHERE p.index_id IN (0, 1)
GROUP BY t.name
ORDER BY size_mb DESC;

Имена вида _AccumRg12345 или _InfoRg678 сопоставьте с объектами метаданных через ПолучитьСтруктуруХраненияБазыДанных() в обработке или консоли запросов. Чаще всего в лидерах — регистры сведений с версиями объектов, журналы обмена и регистры остатков за десять лет.

Подготовка базы перед обновлением: что почистить

Чем меньше данных в изменяемых таблицах, тем быстрее реструктуризация и обработчики. Резервную копию перед обновлением делайте всегда — без неё не начинайте ни один из шагов ниже.

Что даёт прирост

• 🗂️ Журнал регистрации. За годы он вырастает до десятков гигабайт. Сократите его в конфигураторе: Администрирование → Журнал регистрации, кнопка сокращения, оставьте последние 3–6 месяцев. Старые записи можно выгрузить в файл.
• 🧾 Версии объектов. В типовых конфигурациях на базе БСП версионирование включается в разделе Администрирование. Если оно годами копило каждую запись документа, таблица версий весит больше остальной базы. Включите удаление устаревших версий и запустите очистку заранее, за день-два до обновления.
• ❌ Помеченные на удаление. Удалите их обработкой удаления помеченных объектов, пока база не обновлена.
• 🔁 Изменения в планах обмена. Если узел обмена давно не синхронизировался, таблицы регистрации изменений хранят миллионы записей. Мёртвые узлы удалите, живые синхронизируйте.

Тестирование и исправление — не всегда

Режим Администрирование → Тестирование и исправление в конфигураторе полезен, если база жила со сбоями. Но на большой базе он идёт часами и монопольно. Перед каждым плановым обновлением его запускать не нужно. Исключение — файловая база после аварийного отключения питания.

Как ускорить обновление файловой базы

Файловая база больше всего страдает от медленного доступа к файлу 1Cv8.1CD. Вот что даёт эффект по порядку убывания.

1. Обновляйте на той машине, где лежит база. Обновление по сети через общую папку идёт в разы медленнее: каждое чтение страницы — сетевой запрос. Скопируйте каталог базы на локальный SSD, обновите, верните обратно. Пока идёт копирование, никто не должен работать в базе.
2. Исключите каталог базы из проверки антивирусом. Антивирус перехватывает обращения к файлу размером в гигабайты. Исключение добавляйте на каталог с базой и на временные каталоги 1С, а не отключайте защиту целиком.
3. Сожмите таблицы. В Тестирование и исправление есть флажок сжатия таблиц информационной базы. Файл после удаления данных не уменьшается сам, сжатие возвращает место и ускоряет чтение.
4. Очистите кэш клиента. Запуск с ключом /ClearCache убирает устаревший кэш конфигурации у пользователя. Это не ускоряет саму реструктуризацию, но снимает «обновление зависло на старте» после установки.
5. Проверьте размер. Файловая база на 15–20 ГБ и больше обновляется мучительно в любом случае. Это сигнал к переходу на клиент-серверный вариант.

Ускорение обновления 1С в клиент-серверном варианте (SQL)

В клиент-серверной базе узкое место смещается в СУБД. Здесь работают другие приёмы.

Серверная реструктуризация

По умолчанию реструктуризацию выполняет конфигуратор на машине администратора: данные гоняются по сети туда и обратно. Ключ -Server у команды /UpdateDBCfg переносит работу на сервер 1С, рядом с СУБД. В актуальных версиях платформы есть и новый механизм реструктуризации (-v2): он меняет только затронутые поля, не переписывая таблицу целиком.

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER ^
 /S"srv1c\buh" /N"Администратор" /P"пароль" ^
 /UpdateDBCfg -Server -v2 ^
 /Out"C:\logs\update_buh.log" /DisableStartupDialogs

Номер версии в пути подставьте свой. Если ключ -v2 ваша версия платформы не принимает, это видно в логе — уберите его.

Фоновое обновление

Ключ -BackgroundStart запускает подготовку реструктуризации в фоне, пока пользователи работают. Завершение (-BackgroundFinish) требует уже короткого монопольного доступа. Для базы, где окно простоя — 30 минут ночью, это главный приём: тяжёлая часть уходит в рабочее время.

Настройки СУБД на время обновления

• 💾 Модель восстановления. В MS SQL при полной модели (FULL) реструктуризация раздувает журнал транзакций на десятки гигабайт. На время обновления переключите базу в SIMPLE, после — верните FULL и сразу сделайте полную резервную копию, иначе цепочка копий журнала прервётся.
• 📊 Статистика и индексы. Обновите статистику и перестройте фрагментированные индексы до обновления, а не после. Обработчики обновления — те же запросы, им тоже нужна свежая статистика.
• 🗄️ tempdb и журнал — на быстрый диск. Реструктуризация активно пишет во временную базу.
• 🐘 PostgreSQL. Перед обновлением выполните VACUUM ANALYZE по базе. Если в логе СУБД часто встречаются сообщения о слишком частых контрольных точках, увеличьте max_wal_size.

Регламентные задания

Перед обновлением включите блокировку регламентных заданий в свойствах информационной базы в консоли кластера. Иначе обмен или загрузка курсов может начаться в момент реструктуризации и держать блокировки на тех же таблицах.

Обновление через командную строку и пакетный запуск

Обновление через помощник в режиме 1С:Предприятие удобно для одной базы. Когда баз пять и больше, быстрее скрипт: он не ждёт кликов и работает ночью.

Типовая цепочка для одной базы:

set EXE="C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe"
set BASE=/S"srv1c\buh" /N"Администратор" /P"пароль"

rem 1. Резервная копия в .dt
%EXE% DESIGNER %BASE% /DumpIB"D:\backup\buh.dt" /Out"D:\logs\buh.log" -NoTruncate

rem 2. Обновление конфигурации из файла поставки
%EXE% DESIGNER %BASE% /UpdateCfg"D:\upd\1Cv8.cfu" /Out"D:\logs\buh.log" -NoTruncate

rem 3. Обновление конфигурации базы данных
%EXE% DESIGNER %BASE% /UpdateDBCfg -Server /Out"D:\logs\buh.log" -NoTruncate

rem 4. Обработчики обновления в режиме предприятия
%EXE% ENTERPRISE %BASE% /C"ЗапуститьОбновлениеИнформационнойБазы;ЗавершитьРаботуСистемы" /DisableStartupDialogs

Что учитывать

• 🔢 Цепочка релизов. Файл .cfu обновляет только с определённых предыдущих версий. Если база отстала на пять релизов, скрипт должен пройти их по очереди. Помощник обновления в типовых конфигурациях подбирает цепочку сам.
• ⚡ Параллельность. Несколько баз можно обновлять одновременно, но каждая реструктуризация нагружает диск и память. На сервере с 8 ядрами и SSD 2–3 параллельных обновления — разумный предел, дальше они начинают мешать друг другу.
• 🔒 Заблокированные сеансы. Если базу заблокировали для работы пользователей с кодом разрешения, передайте его ключом /UC.
• 📄 Лог. Ключ -NoTruncate дописывает лог, а не перезаписывает его. Удобно, когда шаги идут одной цепочкой.

Загрузка данных из .dt

Загрузка .dt (/RestoreIB) упирается в те же диск и СУБД. Запускайте её на сервере, а не с рабочей станции. Для MS SQL на время загрузки тоже помогает модель SIMPLE.

Хранилище конфигурации и обновление доработанных баз

Если конфигурация подключена к хранилищу, обновление поставщика усложняется. Объединение требует захвата объектов в хранилище, а захват корня с тысячами объектов идёт долго.

Приёмы, которые экономят часы

1. Обновляйте в отдельной базе. Разработчик снимает копию из хранилища в чистую базу, выполняет сравнение и объединение там, проверяет и только потом помещает результат в хранилище одной операцией.
2. Сервер хранилища вместо общей папки. Хранилище через crserver (по протоколу tcp://) работает заметно быстрее, чем файловое хранилище в сетевой папке, особенно при захвате и помещении большого числа объектов.
3. Сохраняйте настройки сравнения. При каждом обновлении поставщика решения по одним и тем же доработанным объектам повторяются. Сохранённые настройки объединения из файла избавляют от ручного прохода по дереву.
4. Выносите доработки в расширения. Чем меньше изменений в основной конфигурации, тем быстрее сравнение. Конфигурация «на поддержке без возможности изменения» обновляется почти как типовая.

После помещения в хранилище рабочие базы получают изменения командой обновления из хранилища и затем той же реструктуризацией. На них действуют все приёмы из разделов про файловую и SQL-базу.

Железо и сеть: что реально влияет на скорость

Практические выводы:

• 🖥️ Сервер 1С и СУБД на одной машине или в одной стойке — реструктуризация меньше гоняет данные по сети.
• 🌐 Обновлять базу через VPN с ноутбука администратора — плохая идея. Подключитесь к серверу по RDP и запустите конфигуратор там.
• 🧊 Виртуальная машина с «тонким» диском на общем хранилище часто даёт непредсказуемую скорость. На время обновления узнайте у администратора виртуализации, не идёт ли параллельно резервное копирование всего хоста.

Частые ошибки

• Запуск обновления в рабочее время «на авось». Реструктуризация на большой базе не прерывается без последствий. Если процесс убить, база может остаться в промежуточном состоянии, и понадобится восстановление из копии.
• Отключение антивируса целиком. Хватит исключений на каталоги баз и временных файлов 1С.
• Модель SIMPLE «навсегда». Её забывают вернуть, и база месяцами живёт без возможности восстановления на момент времени.
• Ожидание конца обработчиков в окне монопольного доступа. В типовых конфигурациях часть обработчиков отложенная: они идут в фоне после входа пользователей. Ход виден в разделе Администрирование → Обслуживание, в результатах обновления. Держать всех за дверью до их окончания не нужно.

Частые вопросы