← На главную

Переход с устаревшей редакции конфигурации на актуальную, например с 1С:Бухгалтерия предприятия 2.0 на 3.0, на информационных базах крупного объема нередко сопровождается серьезными сложностями. В процессе обновления администраторы сталкиваются как с методологическими вопросами выбора последовательности релизов, так и с аварийными падениями рабочего процесса сервера 1С с ошибкой: server_addr=tcp://... descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение в момент реструктуризации больших таблиц (например, регистра бухгалтерии Хозрасчетный).

Разберем по шагам правильную методологию обновления, выясним причины возникновения ошибки 10054 и рассмотрим комплекс мер по оптимизации платформы и MS SQL Server для успешного завершения процесса.

Методология перехода между редакциями конфигурации

Проанализируем типовую дилемму: стоит ли обновлять конфигурацию редакции 2.0 сразу на дистрибутив перехода редакции 3.0 с более старого релиза или необходимо предварительно довести текущую ветку до актуального состояния.

Правильный подход:

1. Обновить конфигурацию редакции 2.0 последовательно до последнего актуального релиза текущей ветки.
2. Выполнить переход на соответствующий релиз редакции 3.0, предназначенный именно для этой версии 2.0.
3. Довести редакцию 3.0 до актуального рабочего релиза.

Попытка «перескочить» через релизы редакции 2.0 напрямую в 3.0 методологически некорректна. Это приводит к пропуску процедур начального заполнения и конвертации данных, что в дальнейшем гарантированно вызовет ошибки логической целостности и кратно увеличит время реструктуризации.

Причины падения процесса rphost и ошибки 10054 при реструктуризации

Ошибка с кодом 10054 (WSAECONNRESET) означает, что сетевое соединение между клиентом (Конфигуратором) и рабочим процессом сервера rphost было принудительно сброшено. Причинами такого сбоя при обновлении крупных баз выступают:

1. Переполнение адресного пространства 32-разрядного сервера 1С: При реструктуризации таблиц с миллионами записей 32-битный процесс rphost упирается в лимит 2–3 ГБ оперативной памяти и аварийно падает (Crash).
2. Срабатывание защитных механизмов кластера 1С: Настроенные ограничения потребления памяти на процесс или вызов принудительно перезапускают рабочий процесс.
3. Блокировки и фрагментация журнала транзакций MS SQL Server: Слишком малый шаг автоувеличения файла лога (LDF), например по 50 МБ, приводит к колоссальному количеству виртуальных файлов лога (VLF), дисковым задержкам и таймаутам.
4. Фоновая активность: Выполнение регламентных заданий во время реструктуризации создает дополнительную нагрузку и конкурирующие блокировки.

Подготовка СУБД MS SQL Server к тяжелой реструктуризации

Рассмотрим порядок настройки MS SQL Server перед запуском обновления базы объемом от 30–40 ГБ и более:

1. Перевод модели восстановления в режим Simple: Переключите модель восстановления базы данных на Простая (Simple) на время выполнения обновления, чтобы предотвратить лавинообразный рост журнала транзакций (LDF).
2. Предварительное расширение и настройка LDF: Установите размер файла журнала транзакций с запасом (например, 15–30 ГБ) и настройте шаг автоувеличения фиксированным блоком (например, 1024 МБ или 10–20%), а не мелкими порциями в мегабайтах.
3. Настройка базы tempdb: Убедитесь, что системная база tempdb расположена на быстром SSD/NVMe диске и имеет достаточный запас свободного пространства для промежуточных выборок.
4. Обслуживание индексов и статистик: До начала обновления выполните перестроение индексов (Rebuild Index) и полное обновление статистик (UPDATE STATISTICS WITH FULLSCAN).

Настройка кластера серверов 1С:Предприятие

Разберем параметры кластера, которые необходимо скорректировать на время реструктуризации:

1. Отключение блокировок по памяти: В консоли администрирования кластера серверов 1С во свойствах кластера временно выставьте значения 0 (без ограничений) для параметров Допустимый объем памяти, Максимальный объем памяти рабочих процессов и Безопасный расход памяти за один вызов.
2. Блокировка регламентных заданий: В свойствах информационной базы установите флаг Блокировка регламентных заданий включена. Это исключит старт фоновых процедур во время изменения структуры метаданных.
3. Использование 64-разрядной платформы: Для реструктуризации тяжелых регистров (более 3–5 млн записей) критически важно использовать 64-битный сервер 1С:Предприятие.

Очистка кэша и сетевые параметры

Для предотвращения нестабильного поведения платформы выполним следующие системные действия:

1. Очистка кэша: Удалите содержимое каталогов пользовательского кэша %localappdata%\1C\1cv8 и %appdata%\1C\1cv8, а также очистите системные журналы перед стартом.
2. Сетевые параметры и адресация: Если клиент и сервер 1С работают в рамках одной машины или сложной сети, укажите явное сопоставление IP-адреса и имени сервера в файле hosts операционной системы, а в строке подключения используйте точный порт кластера (например, 192.168.0.1:1541).
3. Настройка TCP Keep-Alive: Отключите функции аппаратной разгрузки сетевой карты (TCP Chimney / Large Send Offload) во избежание сброса длительных «молчащих» соединений операционной системой.

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