Как исправить ошибку 10054 при реструктуризации тяжелого регистра в 1С?

← На главную

При работе с крупными базами данных (объемом более 500 Гб) и регистрами, содержащими десятки миллионов строк, стандартные операции по изменению структуры метаданных могут превратиться в серьезную техническую проблему. Одной из наиболее распространенных ошибок в такой ситуации является 10054 (An existing connection was forcibly closed by the remote host). Эта ошибка сигнализирует о том, что соединение между сервером приложений 1С и СУБД (или между клиентом и сервером 1С) было принудительно разорвано.

В данной статье мы разберем причины возникновения этой ошибки на платформе 8.3.12 при попытке изменить периодичность регистра накопления (76 миллионов строк) и рассмотрим пошаговые стратегии решения этой задачи.

Разберем причину ошибки 10054

Прежде всего, проанализируем природу ошибки. Код 10054 — это системная ошибка сокетов Windows, означающая «Сброс соединения». В контексте 1С при выполнении реструктуризации это происходит по следующим причинам:

Нехватка оперативной памяти: Процесс rphost (рабочий процесс сервера 1С) пытается обработать огромный объем данных в памяти, достигает установленных лимитов или физического предела RAM, после чего падает или перезапускается кластером.
Таймауты TCP/IP: Длительная операция на стороне SQL-сервера заставляет сетевое оборудование или саму ОС считать соединение «зависшим» и обрывать его.
Аварийное завершение процесса СУБД или rphost: Если один из участников обмена данными завершает работу аварийно (например, из-за ошибки доступа к памяти), вторая сторона получает 10054.

Выясним, как поэтапно решить эту проблему, начиная с настройки инфраструктуры и заканчивая архитектурными изменениями в самой конфигурации.

Решение 1: Оптимизация ресурсов и настроек сервера 1С

Проанализируем текущие настройки сервера приложений. Если вы используете 32-битный сервер 1С, он физически не может адресовать более 4 Гб памяти (а на практике — не более 2-3 Гб), что для таблицы в 76 млн строк катастрофически мало.

Рассмотрим шаги по настройке кластера:

Переход на 64-битную платформу: Это обязательное условие для работы с тяжелыми базами. 64-разрядный rphost может задействовать всю доступную память сервера.
Настройка лимитов памяти в консоли кластера: Посмотрим на параметры рабочего сервера. Если установлены значения «Безопасный расход памяти» или «Критический объем памяти», на время реструктуризации их стоит временно обнулить или значительно увеличить. Это позволит процессу rphost использовать, например, все 88 Гб RAM, доступные на борту.
Увеличение количества процессов: В некоторых случаях помогает временное выделение отдельного рабочего процесса под задачу реструктуризации, чтобы другие пользователи не влияли на стабильность системы.

Решение 2: Подготовка MS SQL Server

Реструктуризация в 1С (особенно на старых версиях платформы до появления механизма фоновой реструктуризации) работает по принципу создания временной таблицы: данные копируются из старой таблицы в новую, затем старая удаляется, а новая переименовывается. Для 76 Гб данных это создает колоссальную нагрузку на дисковую подсистему и логи транзакций.

Проанализируем необходимые настройки SQL:

Режим восстановления (Recovery Model): Перед началом работ обязательно переведите базу в режим Simple. Это предотвратит бесконтрольный рост файла лога транзакций (.ldf), который при такой операции может забить весь диск.
Объем TempDB: Убедитесь, что на диске, где расположены файлы TempDB, достаточно свободного места (минимум в 1.5–2 раза больше объема самой таблицы регистра). SQL Server активно использует временную базу для сортировок и перестроения индексов.
Таймауты в строке соединения: Если ошибка происходит на стороне СУБД, попробуйте увеличить таймауты в настройках сервера 1С.

Решение 3: Ручная реструктуризация (Метод «Золотого стандарта»)

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

Рассмотрим пошаговый алгоритм:

Создайте в конфигураторе новый регистр накопления (например, РегистрНакопления_Новый) с точно такой же структурой, но без установленной периодичности (или с той, которая вам нужна).
Добавьте в новый регистр реквизит СтарыйПериод (если вам нужно сохранить данные о времени), как вы и планировали.
Напишите обработку, которая будет порциями (например, по 100 000 строк) считывать данные из старого регистра и записывать их в новый.

Посмотрим на пример кода для такого переноса:


Выборка = РегистрыНакопления.СтарыйРегистр.Выбрать();
Пока Выборка.Следующий() Цикл
    НовыйНабор = РегистрыНакопления.НовыйРегистр.СоздатьНаборЗаписей();
    НовыйНабор.Отбор.Регистратор.Установить(Выборка.Регистратор);
    
    // Копируем движения
    НоваяЗапись = НовыйНабор.Добавить();
    ЗаполнитьЗначенияСвойств(НоваяЗапись, Выборка);
    НоваяЗапись.СтарыйПериод = Выборка.Период; // Сохраняем период в реквизит
    
    // Записываем порциями, чтобы не переполнять лог
    НовыйНабор.Записать(Истина);
КонецЦикла;

После завершения переноса данных выполните следующие действия:

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

Решение 4: Настройка сетевых параметров ОС

Если сервер 1С и SQL Server разнесены на разные физические или виртуальные машины, проблема может крыться в настройках TCP-стека Windows. При длительных операциях (реструктуризация 76 млн строк может идти часами) соединение может быть разорвано по таймауту KeepAlive.

Проанализируем настройки реестра:

Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и проверьте (или создайте) параметры:

KeepAliveTime (тип DWORD): установите значение 300000 (5 минут). Это заставит систему чаще проверять активность соединения.
KeepAliveInterval (тип DWORD): установите значение 1000 (1 секунда).

Эти настройки нужно применить как на сервере 1С, так и на сервере SQL.

Решение 5: Использование Технологического журнала (ТЖ)

Если ситуация остается неопределенной, нам необходимо «заглянуть под капот» процесса. Для этого настроим Технологический журнал, чтобы поймать момент падения rphost. Нам интересны события EXCP (исключения) и MEM (мониторинг памяти).

Пример настройки logcfg.xml для диагностики:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\v8_logs" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="MEM"/>
        </event>
        <property name="all"/>
    </log>
</config>

Анализ логов позволит точно понять: падает ли процесс от Out of memory или же происходит внешнее прерывание связи сетевым драйвером.

Подведем итоги

Для успешной реструктуризации тяжелого регистра на платформе 8.3.12 наиболее надежным является комбинированный подход:

Обеспечить 64-битную среду и достаточный объем RAM (не менее размера самой таблицы).
Перевести SQL в режим Simple и подготовить TempDB.
В случае неудачи стандартными средствами — использовать метод создания нового регистра и порционного переноса данных кодом 1С.

Такой подход гарантирует сохранность данных и минимизирует время простоя системы при работе с критическими объемами информации.