При работе с системой 1С:Предприятие, особенно в процессе обновления конфигурации, мы можем столкнуться с различными сложностями. Одной из таких распространенных и, порой, трудно диагностируемых проблем является ошибка с кодом 10054: "An existing connection was forcibly closed by the remote host", что означает "Существующее соединение было принудительно закрыто удаленным хостом". Эта ошибка указывает на неожиданное прерывание сетевого соединения между компонентами 1С, чаще всего между клиентом (или рабочим сервером 1С) и сервером 1С:Предприятия или СУБД.
Давайте подробно рассмотрим сценарий, когда данная ошибка возникает исключительно при обновлении конфигурации информационной базы, и как ее можно эффективно устранить, а также выясним дополнительные причины и методы диагностики.
Когда мы сталкиваемся с такой ошибкой, важно проанализировать контекст ее возникновения. В нашем случае, ошибка появляется в конце длительного процесса обновления конфигурации (около 20 минут), при этом потребление процессора сначала находится на уровне 15-20%, затем резко подскакивает до почти 100%, и через 30 секунд выдается ошибка. Исходная среда включает ОС Windows Server 2012 R2, платформу 1С:Предприятие 8.3 (8.3.10.2375) и MS SQL 2014, причем сервер 1С и SQL расположены на одной виртуальной машине, исключая прямые проблемы с физической сетью. Обновление запускается непосредственно на сервере.
Рассмотрим, какие шаги были предприняты для решения проблемы, но не принесли желаемого результата:
C:\Program Files\1cv8\srvinfo\reg_3541\.... Это стандартная процедура, которая помогает при различных проблемах с некорректными данными кэша, но в данном случае оказалась неэффективной.Мы также знаем, что год назад схожая проблема была успешно решена путем изменения параметров рабочего сервера 1С, а именно: Количество ИБ на процесс было изменено с 1 на 8, а Количество соединений на процесс — с 128 на 180. Эти настройки влияют на то, как кластер 1С распределяет нагрузку и использует ресурсы. Хотя тогда это помогло, в текущей ситуации эти изменения уже не дают результата.
Один из самых мощных инструментов для диагностики проблем на сервере 1С:Предприятия — это технологический журнал. Если он не был включен, как в нашем случае, мы теряем ценнейшую информацию о внутренних процессах, ошибках и взаимодействии компонентов системы. Чтобы включить технологический журнал, нам необходимо создать или отредактировать файл logcfg.xml в каталоге conf кластера серверов 1С (обычно C:\Program Files\1cv8\srvinfo\conf\ или аналогичный путь).
Пример содержимого файла logcfg.xml для базовой регистрации событий:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1C_Logs" history="168" maxfile="10000000">
<event>
<eq property="Name" value="DBMSSQL"/>
</event>
<event>
<eq property="Name" value="SCALL"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="DUMP"/>
</event>
<event>
<eq property="Name" value="CONN"/>
</event>
<event>
<eq property="Name" value="ADMIN"/>
</event>
<event>
<eq property="Name" value="TDEADLOCK"/>
</event>
<event>
<eq property="Name" value="TLOCK"/>
</event>
<event>
<eq property="Name" value="CALL"/>
</event>
<event>
<eq property="Name" value="SESN"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="SRVC"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
</event>
</log>
</config>
В этом примере мы указываем каталог для логов (C:\1C_Logs), глубину хранения (history="168" часов) и максимальный размер файла (maxfile="10000000" байт). После включения технологического журнала и перезапуска службы 1C:Enterprise 8.3 Server Agent, мы сможем анализировать файлы логов, такие как rphost_log (логи рабочего процесса 1С), ragent_log (логи агента сервера) и rmngr_log (логи менеджера кластера). Эти логи могут содержать записи об исключениях (EXCP), ошибках работы с базой данных (DBMSSQL), зависаниях (TDEADLOCK) или принудительном завершении процессов, что крайне важно для понимания причины ошибки 10054.
В отсутствие явных причин, выявленных через стандартные методы диагностики или технологический журнал, иногда приходится прибегать к более радикальным, но часто эффективным методам. Один из таких методов, который был найден и успешно применен в подобной ситуации, заключается в полном пересоздании кластера серверов 1С.
Разберем по шагам, как это было сделано:
.dt файл или бэкап SQL) и восстанавливаем его в эту новую, только что зарегистрированную информационную базу внутри нового кластера. Это позволяет нам получить точную копию данных, но в "чистой" инфраструктуре 1С.Почему этот метод работает?
Пересоздание кластера и базы данных из архива является своего рода "генеральной уборкой". Это позволяет:
Помимо рассмотренного решения, существуют и другие глубинные причины возникновения ошибки 10054, которые следует учитывать при ее диагностике.
Мы выясним, что проблемы могут быть связаны непосредственно с работой компонентов 1С.
rphost): Рабочий процесс rphost.exe отвечает за выполнение основной логики 1С. В процессе обновления он испытывает значительную нагрузку. Иногда rphost может войти в нестабильное состояние из-за утечек памяти, внутренних ошибок или конфликтов, что приводит к его аварийному завершению операционной системой или менеджером кластера 1С (rmngr). Это и выглядит как разрыв соединения. В таких случаях может помочь ручной перезапуск всех рабочих процессов rphost (или службы 1C:Enterprise 8.3 Server Agent) перед началом обновления.FTSIndex) может быть поврежден или чрезмерно разрастись. Операции обновления конфигурации часто включают работу с метаданными и данными, что может вызывать повышенное потребление ресурсов процессом rphost.exe, если ему приходится взаимодействовать с поврежденным или неоптимизированным индексом ППД. Это может приводить к аварийным перезапускам rphost. Решением может быть полное перестроение или удаление и создание заново индекса ППД через консоль кластера 1С или встроенные средства 1С.Допустимый объем памяти для рабочего процесса и Интервал перезапуска могут быть настроены слишком агрессивно. Если rphost превышает установленный объем памяти во время обновления (что часто происходит при больших объемах данных и сложной реструктуризации), менеджер кластера принудительно его завершает. Мы должны рассмотреть увеличение Допустимого объема памяти и Интервала перезапуска, а также проверить такие параметры, как Количество ИБ на процесс и Количество соединений на процесс, как было сделано в прошлом случае.Поскольку 1С использует MS SQL Server, мы должны рассмотреть потенциальные проблемы со стороны СУБД.
query timeout или remote query timeout), SQL Server может сам разорвать соединение с сервером 1С. Мы должны проверить и, при необходимости, увеличить эти параметры в настройках SQL Server.ALTER TABLE, CREATE INDEX и UPDATE. Наличие длительных блокировок от других сеансов (даже от служебных), недостаточная производительность дисковой подсистемы SQL-сервера (медленные диски) или устаревшая статистика могут значительно замедлить процесс обновления. В результате, процесс 1С может ожидать ответа от SQL дольше, чем предусмотрено внутренними тайм-аутами, что приводит к разрыву соединения. Регулярное обслуживание SQL (обновление статистики, перестроение индексов) и мониторинг блокировок (например, с помощью sp_whoisactive) являются критически важными.Даже если сервер 1С и СУБД находятся на одной виртуальной машине, проблемы могут возникать на уровне ОС и виртуальной сети.
hosts, это может вызывать задержки или сбои в установлении и поддержании соединения. Мы должны убедиться, что все имена разрешаются корректно и без задержек..mdf, .ldf) или каталоги временных файлов сервера 1С, может существенно замедлить процесс обновления и даже вызвать разрыв соединения из-за чрезмерной задержки или блокировки доступа к файлам. Мы настоятельно рекомендуем добавить критичные для 1С и SQL процессы (rphost.exe, ragent.exe, rmngr.exe, sqlservr.exe) и каталоги (папки баз данных 1С, папки SQL Server, каталоги кэша 1С) в исключения антивирусного ПО. Брандмауэр Windows (или сторонний) также может блокировать порты, используемые 1С (1541, 1560) или SQL (1433), хотя на одной машине это менее вероятно.Таким образом, хотя проблема ошибки 10054 при обновлении конфигурации может быть вызвана множеством факторов, наиболее радикальное решение, связанное с пересозданием кластера серверов 1С, часто оказывается наиболее эффективным, когда другие методы диагностики и устранения не приносят результата. Важно помнить о комплексном подходе к диагностике, используя все доступные инструменты, включая технологический журнал 1С и логи операционной системы и СУБД.