Обновление 1С встало на одном проценте: ищем, что держит процесс
Содержание
Обновление 1С зависает чаще всего по одной из трёх причин: базу держит чужой сеанс или фоновое задание, файлы блокирует антивирус, либо серверу СУБД не хватает места на диске для реструктуризации. Первым делом откройте диспетчер задач: если процесс 1cv8.exe (или sqlservr.exe, postgres.exe) грузит диск и процессор — обновление идёт, ждите. Если нагрузка ноль минут десять подряд — процесс чего-то ждёт, и причину надо искать.
Проверять причины выгоднее по порядку: сеансы и антивирус отнимают пять минут, а разбор блокировок в СУБД и кода обработчиков требует администратора и разработчика.
Зависло или просто долго: как отличить за пять минут
Обновление проходит две разные стадии, и висят они по-разному:
- 🔧 Обновление конфигурации и структуры базы — в Конфигураторе, после команды «Обновить конфигурацию базы данных». Здесь идёт реструктуризация: платформа перестраивает таблицы под новые реквизиты и индексы.
- 🔄 Обработчики обновления — при первом запуске в режиме «1С:Предприятие». Программа показывает окно «Обновление версии программы» с процентом выполнения и переносит данные под новый релиз.
На большой базе обе стадии честно идут часами. Реструктуризация таблицы регистра бухгалтерии на 30–50 ГБ может занять 2–4 часа, и всё это время полоса прогресса стоит на месте.
Признаки того, что процесс работает:
- В мониторе ресурсов Windows (
resmon.exe, вкладка «Диск») видно, что1cv8.exeили процесс СУБД пишет файлы. - Размер файла
1Cv8.1CD(файловая база) или файлов данных SQL меняется. - Растёт временный каталог: для файловой базы — рядом с
1Cv8.1CD, для серверной —tempdbу MS SQL или каталогbase/pgsql_tmpу PostgreSQL.
Признаки того, что процесс ждёт: нулевая загрузка диска и процессора, окно Конфигуратора не меняется, а в СУБД видна блокировка.
Не снимайте процесс 1cv8.exe во время реструктуризации, пока не убедились, что он действительно стоит. Обрыв на середине перестройки таблиц в файловой базе грозит повреждением 1Cv8.1CD. Перед любым обновлением нужна свежая выгрузка .dt или резервная копия средствами СУБД.
Антивирус и системные утилиты, которые держат файлы базы
Во время обновления платформа создаёт и удаляет сотни временных файлов. Антивирус с проверкой «при доступе» перехватывает каждую запись. В лучшем случае всё замедляется в разы, в худшем — антивирус держит файл, платформа ждёт освобождения, и процесс замирает.
Что ещё держит файлы:
- 🛡 антивирус и встроенная защита Windows с проверкой в реальном времени;
- 💾 программы резервного копирования, которые снимают копию каталога базы по расписанию;
- ☁️ клиенты облачной синхронизации (Яндекс Диск, OneDrive), если база лежит в синхронизируемой папке;
- 🔍 служба индексирования Windows.
Добавьте в исключения антивируса (и на рабочей станции, и на сервере):
| Каталог | Что там |
|---|---|
| каталог файловой базы | 1Cv8.1CD, временные файлы реструктуризации |
%APPDATA%\1C\1cv8 | кэш конфигураций, каталог шаблонов tmplts |
%LOCALAPPDATA%\1C\1cv8 | локальный кэш клиента |
%TEMP% пользователя | распаковка файлов обновления |
каталог srvinfo сервера 1С | кэш и журналы кластера |
| каталоги данных и журналов СУБД | файлы MS SQL или PostgreSQL |
Исключать стоит и процессы: 1cv8.exe, 1cv8c.exe, rphost.exe, ragent.exe, rmngr.exe.
Резервное копирование и синхронизацию на время обновления остановите вручную. Если задание резервного копирования стоит на ночь, а обновление вы ставите туда же, они гарантированно столкнутся.
Быстрая проверка: на время обновления отключите проверку в реальном времени (если политика безопасности это позволяет) и повторите. Если стало быстро — дело в антивирусе, настраивайте исключения и включайте защиту обратно.
Сеть, общая папка и загрузка файлов обновления
Сеть вызывает зависания двух видов.
Файловая база в сетевой папке. Реструктуризация гоняет гигабайты по сети. На Wi-Fi или через VPN обновление базы в 5 ГБ легко растягивается на ночь, а короткий обрыв связи оставляет процесс в подвешенном состоянии. Правило простое: обновляйте файловую базу на том компьютере, где она физически лежит, или скопируйте каталог базы на локальный диск, обновите и верните обратно (при закрытой базе).
Загрузка обновления из интернета. Если окно висит ещё до начала реструктуризации, проблема в скачивании:
- 🌐 прокси-сервер не пропускает запросы платформы — проверьте настройки прокси в окне запуска 1С;
- 🔐 не проходит проверка сертификата сайта обновлений из-за устаревших корневых сертификатов Windows;
- 🧱 межсетевой экран режет длинные загрузки.
Обходной путь, который работает всегда: скачайте файл обновления .cfu (или полный дистрибутив .cf) вручную на сайте поддержки под своим логином интернет-поддержки, установите его в каталог шаблонов и в Конфигураторе выберите Конфигурация → Поддержка → Обновить конфигурацию, указав файл вручную.
Для серверной базы сеть важна между сервером 1С и сервером СУБД. Если они на разных машинах, медленный канал между ними замедляет реструктуризацию сильнее, чем слабый процессор.
Сеансы, фоновые задания и блокировки на сервере СУБД
Это самая частая причина «вечного» обновления клиент-серверной базы. Для обновления структуры нужен монопольный доступ. Если в базе остался хотя бы один сеанс — бухгалтер, забывший закрыть программу, обмен по расписанию или регламентное задание, — Конфигуратор выдаёт ошибку блокировки или ждёт.
Освободите базу перед стартом
- В режиме «1С:Предприятие» в разделе
Администрированиенайдите команду «Блокировка работы пользователей», установите блокировку с кодом разрешения и временем начала. - В консоли администрирования серверов 1С откройте свойства информационной базы, включите «Блокировка начала сеансов включена» и «Блокировка регламентных заданий включена», укажите код разрешения.
- В той же консоли откройте список сеансов базы и проверьте, что остались только ваши.
- Запускайте Конфигуратор с кодом разрешения: параметр
/UC<код>в строке запуска.
Завершение чужих сеансов из консоли обрывает работу пользователей без сохранения. Предупредите людей заранее, обновляйте в нерабочее время.
Посмотрите, кто держит таблицы в СУБД
Если сеансов 1С нет, а Конфигуратор всё равно стоит без нагрузки на диск, загляните в саму СУБД. Там может висеть транзакция, начатая внешней программой, скриптом обслуживания или «зомби»-соединением от упавшего рабочего процесса.
Для MS SQL Server:
SELECT session_id, blocking_session_id, wait_type, wait_time, command, DB_NAME(database_id) AS db
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
Для PostgreSQL:
SELECT pid, pg_blocking_pids(pid) AS blocked_by, state, wait_event_type, left(query, 80)
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;
Запрос покажет, какой сеанс кого блокирует. Дальше смотрите, что это за соединение: если оно принадлежит вашему же Конфигуратору — ждите, идёт работа. Если это задание обслуживания (перестроение индексов, бэкап) — дождитесь его конца или перенесите обновление.
Ещё одна классика — переполненный журнал транзакций. У MS SQL в модели восстановления «Полная» файл .ldf при реструктуризации большой таблицы растёт на десятки гигабайт. Когда место на диске кончается, транзакция встаёт. Перед обновлением сделайте резервную копию журнала и проверьте свободное место на диске с журналом.
Нехватка места на диске, памяти и скорости
Реструктуризация не меняет таблицу на месте. Платформа создаёт новую таблицу, копирует туда данные и только потом удаляет старую. Значит, на пике нужно примерно вдвое больше места, чем занимает самая крупная перестраиваемая таблица, плюс временные файлы и журнал.
Ориентиры, которые стоит проверить до старта:
| Ресурс | Что проверить | Минимальный запас |
|---|---|---|
| Диск с файловой базой | свободное место | не меньше размера 1Cv8.1CD |
| Диск с данными СУБД | свободное место | не меньше размера крупнейшей таблицы ×2 |
| Диск с журналом транзакций (MS SQL) | место под рост .ldf | с запасом на размер базы |
tempdb / временный каталог PostgreSQL | место под сортировки | десятки гигабайт для базы 100+ ГБ |
| Оперативная память | свободная во время работы | без ухода в файл подкачки |
Узнать размер таблиц можно в самой СУБД, а для файловой базы — по размеру файла 1Cv8.1CD. Если места мало, обновление может не упасть с ошибкой, а надолго замереть при попытке расширить файл.
Что ещё замедляет процесс до состояния «висит»:
- 🐢 база на обычном HDD вместо SSD — реструктуризация упирается в случайный доступ к диску;
- 🧠 сервер 1С и СУБД на одной машине с 8 ГБ памяти — оба процесса начинают вытеснять друг друга в подкачку;
- 📈 огромный журнал регистрации файловой базы — его перед обновлением полезно сократить через
Администрирование → Журнал регистрациив Конфигураторе.
Перед обновлением большой файловой базы выполните «Тестирование и исправление» со сжатием таблиц: файл 1Cv8.1CD часто уменьшается в разы, и реструктуризация идёт заметно быстрее.
Повреждённый кэш и ошибки в файлах конфигурации
Кэш конфигурации на компьютере пользователя хранится в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 в папках с длинными именами вида GUID. Когда кэш не совпадает с новой версией конфигурации, Конфигуратор может зависнуть при открытии, при сравнении конфигураций или сразу после обновления.
Как сбросить кэш :
- Закройте все окна 1С на этом компьютере.
- Запустите базу с параметром
/ClearCache— в свойствах базы в окне запуска, поле дополнительных параметров запуска. - Если не помогло — удалите вручную папки с GUID-именами в обоих каталогах. Список баз (
ibases.v8i) при этом лежит отдельно и не пострадает.
Для серверной базы есть ещё серверный кэш в каталоге srvinfo. Его чистят при остановленной службе агента сервера 1С — остановка службы обрывает все сеансы всех баз кластера, поэтому делайте это только в согласованное окно обслуживания.
Если кэш ни при чём, проверьте саму базу:
- 🧩 Файловая база — утилита
chdbfl.exeиз каталогаbinплатформы или режимАдминистрирование → Тестирование и исправлениев Конфигураторе. Начинайте с проверки логической целостности без исправления, затем, если найдены ошибки, — с исправлением на копии базы. - 🧩 Серверная база — тот же режим «Тестирование и исправление» в Конфигураторе плюс проверка целостности средствами СУБД.
Отдельный случай: в Конфигураторе висит прошлое незавершённое обновление, и основная конфигурация уже отличается от конфигурации базы данных. Платформа при открытии предлагает обновить структуру и снова зависает. Здесь помогает либо довести обновление конфигурации базы данных до конца при освобождённой базе, либо вернуть конфигурацию базы данных (Конфигурация → Конфигурация базы данных → Вернуться к конфигурации БД) и начать заново.
Обновление встало после запуска: обработчики и ошибки в коде
Конфигуратор отработал, вы запустили программу, а окно «Обновление версии программы» стоит на 40% уже час. Здесь работает код конфигурации: обработчики переносят данные под новые реквизиты.
Почему это может «висеть»:
- 🧮 обработчик перебирает миллионы записей — на большой базе это часы, и это нормально;
- 🔌 доработки типовой конфигурации конфликтуют с новым кодом: обработчик падает в цикле ошибок или ждёт данных, которых нет;
- 🧱 расширение конфигурации перестало подходить к новому релизу и мешает запуску;
- 👥 обновление запустили два пользователя одновременно, и второй ждёт первого.
Как диагностировать:
- Откройте журнал регистрации (из Конфигуратора
Администрирование → Журнал регистрации) и отберите события за последний час с уровнем «Ошибка». Обработчики обновления пишут туда событие с понятным названием про обновление информационной базы. - Если ошибка повторяется на одном обработчике — это сбой кода, а не медленная работа. Текст ошибки и имя процедуры дадут разработчику точный адрес проблемы.
- Отключите на время запуска расширения, если они есть: в списке расширений снимите флаг «Активно», запустите обновление, потом включите и проверьте совместимость.
Часть обработчиков в современных конфигурациях выполняется отложенно, в фоне, уже после входа пользователей. Их ход виден в разделе Администрирование → обслуживание, пункт результатов обновления программы. Пока отложенная обработка не закончена, отдельные отчёты могут показывать неполные данные — это не зависание.
Если базу дорабатывали, обновление нетиповой конфигурации делайте сначала на копии. Конфликт доработок с типовым кодом проявляется именно здесь, и разбирать его на рабочей базе в понедельник утром — худший сценарий.
Обновление из командной строки с журналом
Когда интерфейс висит без сообщений, полезно повторить обновление структуры пакетно и получить журнал:
"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe" DESIGNER /S"srv1c\buh" /N"Администратор" /P"пароль" /UC"обновление" /UpdateDBCfg /Out"C:\temp\update_log.txt"
Номер версии платформы в пути замените на свой. Параметр /Out пишет в файл все сообщения, которые Конфигуратор показал бы в окне, — по нему видно, на каком этапе процесс остановился.