← На главную
При обновлении конфигурации «Бухгалтерия предприятия» с редакции 2.0 на редакцию 3.0 на информационных базах крупного размера (от 10 ГБ и выше) специалисты часто сталкиваются со следующей ошибкой:
server_addr=tcp://SQLDB2017:1560 descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1584 file=src\DataExchangeTcpClientImpl.cpp
Эта ошибка возникает в момент, когда длительный процесс реструктуризации или обработки данных принудительно прерывается. Разберем подробнее, почему происходят подобные сбои и какие проверенные варианты решения существуют.
Причины возникновения ошибки 10054
Код ошибки 10054 в сетевом стеке Windows означают, что соединение по протоколу TCP было аварийно заблокировано или закрыто со стороны сервера. В контексте платформы «1С:Предприятие» это происходит по следующим причинам:
- Аварийное завершение рабочего процесса
rphost. Во время многочасовой реструктуризации процесс 1С расходует оперативную память. При исчерпании доступной памяти или возникновении критического сбоя в платформе рабочий процесс rphost нештатно завершает работу, а клиентский сеанс теряет связь с сервером.
- Автоматический перезапуск процессов в кластере 1С. Если в настройках кластера серверов 1С заданы ограничения по объему выделенной памяти или интервалу перезапуска рабочих процессов, кластер принудительно завершает процесс, превысивший лимит.
- Сброс неактивного TCP-соединения сетевым оборудованием или ОС. Если между клиентом и сервером 1С длительное время не передаются данные (сервер выполняет тяжелый SQL-запрос), сетевые экраны или ОС могут расценить соединение как зависшее и разорвать сокет.
- Нагрузка со стороны службы полнотекстового поиска и журнала регистрации. В фоновом режиме процессы индексации или запись в файл журнала регистрации (
.lgd / .lgf) вызывают дополнительные блокировки и приводят к падению серверного процесса.
Способ 1. Настройка кластера серверов 1С и параметров операционной системы
Для предотвращения нештатного завершения процессов во время длительного обновления необходимо временно снять ограничения кластера серверов 1С:
- Откроем консоль администрирования кластера серверов 1С.
- В свойствах кластера установим параметр «Интервал перезапуска рабочих процессов» равным 0.
- Обнулим или существенно увеличим параметры «Предельный объем выделенной памяти» и «Превышение объема выделенной памяти».
- Переведем рабочий процесс в режим выполнения одной задачи или временно запустим службу сервера 1С с ключом
-single.
- В реестре ОС Windows на сервере 1С и сервере СУБД увеличим параметры таймаута TCP KeepAlive (параметры
KeepAliveTime и KeepAliveInterval), чтобы исключить сброс неактивных сессий сетевым стеком.
Способ 2. Подготовка информационной базы к переходу
Перед запуском процедур обновления выполним предварительную подготовку базы данных в Конфигураторе и в режиме «1С:Предприятие»:
- Отключение полнотекстового поиска. В режиме конфигуратора или через Администрирование полностью отключим индексы
ПолнотекстовыйПоиск. Это освободит ресурсы сервера.
- Блокировка регламентных заданий. В свойствах информационной базы на сервере 1С установим флаг «Блокировка выполнения регламентных заданий», чтобы исключить параллельное выполнение внутренних процессов
РегламентныеЗадания.
- Очистка журнала регистрации. Временно переведем
ЖурналРегистрации в режим записи только ошибок или сократим его объем.
- Тестирование и исправление. В режиме Конфигуратора выполним процедуру «Тестирование и исправление» с включенными пунктами проверки логической целостности и пересчета итогов.
- Назначение специальных прав. Пользователю, под которым запускается переход, назначим роль
Администратор системы (для перехода на ред. 3.0) и полные права.
Способ 3. Выполнение обновления через локальную файловую базу (метод DT)
Для больших баз данных, где переход на сервере длится несколько суток и падает по таймауту, наиболее эффективен метод временного перевода базы в файловый режим на отдельном мощном ПК:
- Выгрузим информационную базу из MS SQL в файл выгрузки (
.dt).
- Развернем полученный файл
.dt в файловом режиме на локальном компьютере, оснащенном высокоскоростным SSD-диском и 64-битной платформой «1С:Предприятие». В биосе ПК желательно отключить функцию Hyper-Threading для максимальной производительности однопоточных вычислений.
- Запустим процесс обновления конфигурации на 64-битной платформе. В файловом режиме на высокопроизводительном ПК обработка данных выполняется значительно быстрее и не зависит от сетевых таймаутов кластера.
- После успешного завершения всех обработчиков перехода на редакцию 3.0 выгрузим базу обратно в файл
.dt и загрузим её в рабочую базу на MS SQL Server.
Способ 4. Свёртка базы данных или перенос остатков
Если база содержит данные за 5–10 лет и её размер превышает десятки гигабайт, штатное обновление может требовать колоссального времени. В таком случае проанализируем целесообразность свёртки:
- Перенос остатков. Наиболее надежный способ для "тяжелых" баз — создание чистой информационной базы редакции 3.0 и перенос вводных остатков на начало текущего или предшествующего года с помощью специализированных обработок выгрузки/загрузки данных.
- Штатная свёртка периода. Перед обновлением выполним свёртку базы за прошлые периоды (оставив данные за последние 2 года, необходимые для расчета больничных и отпускных в Бухгалтерии). Это уменьшит количество документов в таблицах базы данных и ускорит реструктуризацию.
Способ 5. Оптимизация на уровне СУБД (MS SQL Server)
При работе в среде MS SQL Server выполним следующие операции перед стартом обновления:
- Переведем модель восстановления базы данных (Recovery Model) в режим Simple (Простая), чтобы журнал транзакций (
.ldf) не переполнялся при массовых изменениях таблиц.
- Выполним обновление статистики базы данных командой
UPDATE STATISTICS.
- Проведем дефрагментацию и перестроение индексов таблиц базы данных.
Сочетание предварительного обслуживания СУБД, корректной настройки параметров кластера 1С и использования 64-битной платформы позволяет успешно завершить переход с Бухгалтерии 2.0 на 3.0 без разрыва соединения по ошибке 10054.