Ошибка 10054 удаленный хост принудительно разорвал существующее подключение

Содержание:

1.    Переход на последнюю версию платформы 1С как решение ошибки

2.    Очистка кеша на сервере для решения проблемы

3.    Исправление проблемы с подключением IPv6

Возникновение ошибки «Удаленный хост принудительно разорвал существующее подключение с 1С» зачастую сопровождается кодом 10054 (0x00002746). Откуда возникает эта ошибка и как ее исправить – об этом мы поговорим в данной статье.  

1.     Переход на последнюю версию платформы 1С как решение ошибки

Если у вас появилась ошибка «Удаленный хост принудительно разорвал существующее подключение», возможно, Вы совершили переход с одной версии на платформы на другую. В таком случае для исправления ошибки следует перейти на последнюю версию платформы 1С, которая будет более стабильной, или откатиться назад, если имел место переход на экспериментальную версию платформы. Хотя стоит отметить, что разработчики платформы, оперативно исправляют существенные баги. И с этой ошибкой были замечены всего лишь несколько версий платформы, которые уже канули в лету.  

2.   Очистка кеша на сервере для решения проблемы

Изменение версии платформы – не единственная из возможных причин возникновения ошибки «Удаленный хост принудительно разорвал подключение (10054)». Соответственно, обновление или откат также не являются универсальными решениями проблемы. В любом случае, если вы рядовой пользователь, Вам надо обращаться к системному администратору. Своими действиями вы никак не могли вызвать данную ошибку. Если же Вы специалист и ищете решение данной проблемы, то первым делом надо заняться очисткой кеша на сервере, очистить все сессии и перезагрузить сервер. 

Также не стоит забывать о такой простой вещи, как недостача свободного места на диске, где установлен SQL сервер. Одно из вытекающих решений – очистка памяти. Наконец, одно из популярных решений, которое помогает с этой проблемой, если вас 32 битный 1С сервер, это установка 64 битной версии 1С сервера. Если ничего из вышеперечисленного не помогло, то следует попробовать сжать базу, перезапустить службы агента сервера 1С, попробовать сделать выгрузку/загрузку.  

3.     Исправление проблемы с подключением IPv6

Ещё один нередкий случай: ошибка «Удаленный хост принудительно разорвал существующее подключение (10054)» возникает по причине подключения IPv6. Проверить это можно, открыв командную строку и выполнив команду Ping по имени вашей страницы. Проверьте адрес – по ответу сразу будет понятно, какой протокол в приоритете. Если это так, то следует отключить IPv6 через системный реестр и перезагрузить компьютер. Это можно сделать, создав запись в разделе HKLMSYSTEMCurrentControlSetservicesTCPIP6Parameters, запись «Параметр DWORD (32-бита)» с именем «DisabledComponents» и значением 0xff.

Специалист компании «Кодерлайн»

Юрий Сахно

Лечим 54ю ошибку в 1С

 Описание ошибки

server_addr=tcp://<имясервера>:1562 descr=Ошибка сетевего доступа к серверу (Windows Sockets — 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение.) line=1031 file=.srcDataExchangeTcpClientImpl.cpp

Как бороться с этой проблемой

Настроить Технологический журнал и разобрать его логи.
Наиболее частыми причинами бывают падения серверной части 1С:Предприятия.
В также можно убедиться, посмотрев — ане создаются ли дампы (смотреть путь logcfg.xml, если настройка dump-ов в нем отсутствует, то в каталоге %USERPROFILE%Local SettingsApplication Data1C1Cv81Dumps, например C:Documents and Settings<Имя пользователя>Local SettingsApplication Data1C1Cv81dumps. Падения платформы чаще всего могут возникать из-за запросов с нестандартными параметрами. Дампы отсылайте в техподдержку 1С email:v8@1c.ru.
1. Чаще всего мне встречалась проблема в журнале документов в отборах запросы были похожи на этот:

SELECT ALLOWED TOP 35 R.Date_Time A1,
R.Number A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
R.Fld9605 A13,
R.Document A14,
R.Marked A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Description
A17,CAST(R.Fld9606 AS REF(Reference52)).Description A18,CAST(R.Fld9611
AS REF(Reference93)).Description A19, CASE WHEN R.Fld9609 REFS
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Description WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Description WHEN R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Description WHEN R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Description END
A20,CAST(R.Fld9605 AS REF(Reference79)).Description A21
FROM DocumentJournal9604 R WHERE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) AND
(R.Date_Time > DATETIME(2006,12,31,12,0,0) OR (R.Date_Time =
DATETIME(2006,12,31,12,0,0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
ORDER BY A1 ASC, A14 ASC’

2. Пример лога ТЖ, показывающее причину падений сервера при обновлении полнотекстового поиска
11:40.9690-0,EXCP,1,process=rphost,p:processName=<база данных>,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:Program Files (x86)1cv81dumpsrphost_8.1.13.41_7d4e2366_20090609021136_10236.mdmp,Context=’
ОбщийМодуль.МодульРегламентныхЗаданий : 46 : ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);’

Итоговым решением в этом примере будет отключить фоновый процес в проблемной базе. Дождаться нового релиза платформы и обновиться.
Более подробно про падения платформы смотрите в моем блоге.
3. Пример ТЖ для циклический перезапуск процессов. Для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.
4. Убедиться, что причиной являются/не являются действия администратора в консоли

—————————-

Ниже представлен вариант решения коллегой.

Всем заинтересованным в решении проблем с падением платформы с ошибками:

10051, 10053, 10054, 10064

Как показал разбор полетов по падениям платформы, с выше указанными ошибками:

— Большинство падений вызвано именно работой фоновых заданий, как и предполагалось в топике.

— Не хваткой дискового пространства

— Наличием большого числа не завершенных транзакций в журнале 1С

* * *

— Прежде чем заниматься разбором с технологическим журналом, проанализируйте используемые в конфигурации фоновые задания и отключите те, которые не требуются Вам для работы, конфигурации (банально, анализ 14 ГБ мусора можно считать времяпрепровождением, если Вам нечем заняться… :))) )

— Проанализируйте и внесите исправления в дописанные Вами фоновые задания, убедитесь в том, что они завершаются с нормальным кодом завершения (без ошибок и не закрытых транзакций)

— Внесите в алгоритмы фоновых заданий фрагменты кода, ошищающие, принудительно, память используемую в ходе их работы (Не стоит надеяться на то, что 1С при завершении особождает использованную память)

— Проанализируйте и ИСПРАВЬТЕ ПРОБЛЕМЫ ФУНКЦИОНИРОВАНИЯ типовых фоновых заданий конфигурации

— Выполните регламентные процедуры с базой данных, через пункт меню Администрирование-Тестирование и исправление, не забудьтеобязательно, выполнить сжатие базы данных

— Проанализируйте объем используемого пространства сервером SQL, вероятно что серверу банально нехватает памяти

— Проверьте политки настройки Active Directory

— И также сожмите/очистите журнал транзакций SQL вот примерно таким кодом (для SQL 2000):

Если после этих операций падения продолжаются, тогда продолжайте следовать рекомендациям:

— Пробуйте внести изменения в файлы HOSTS операционной системы (вероятнее всего будет достаточно прописать ассоцирование только в файлы на одной/двух машинах, где падения происходят наиболее часто)

— Пробуйте разнести сервера 1С предприятия и SQL, если они у Вас на одной машине.

— Или наоборот установите их на одной машине (если хватает ресурсов) Отмечаются случаи, когда именно перенос серверов на один сервер помогало (На мой взгляд очень сомнительно и больше относится именно к причине начала работы, это сжатие журналов транзакций)

— Проверьте время отклика сервера (вероятнее всего, что все будет в пределах нормы, а редкие провалы во времени обслуживания, не могут столь сильно влиять на работу сервера предприятия)

— Проверьте работу маршрутизаторов в сети (Редко, но бывает, что именно их перенастройка влияет на количество падений)

— Проверьте конфликты оборудования в сети (это к вопросу, почему желательно иметь оборудование одного поставщика в сети. Кто хочет может проверить, например, в тех. документации 3COM написано: если сетевая карта обнаруживает, что взаимодействует с аналогичной сетевой картой, то она может быть переключена в более производительный режим, засчет перехода на оптимизированный алгоритм обработки сетевых пакетов, проверено на личном опыте скачок производительности до 50%)

— Проверьте уровни сигналов у потребителей/конечных компьютеров (может быть банально, низкий уровень сигналов, постоянные повторные запросы блоков, задержка очереди на обслуживание в сети, а следовательно в конце концов получение сообщения, что конечный серевер разорвал соединение, когда количество попыток превысит время ожидания поступления сигнала. Если хотите разобраться в данном вопросе обратитесь к протоколу работы Ethernet/CSMA CD/CSMA. Количество попыток в передаче пакета по данному протоколу не бесконечно… ))) Да и буфер в картах тоже не беспределен.)

— Добавьте памяти на сервера

— Переведите часть/всех пользователей в терминальный режим (Т.е. обеспечьте то, что МНОГИЕ пользователи определеяют как ТОНКОГО КЛИЕНТА 1C). В качестве такого сервера я бы рекомендовал Citrix Metaframe или Terminal Server MS

Вероятнее всего, когда Вы выполните указанные рекомендации, за исключением разбора проблем с железом, стабильность работы возрастет настолько что падения платформы станут очень редкими, что перекроют технологические промежутки по обслуживанию базы данных, выполнять которые всеже НЕОБХОДИМО и не думайте, что те рекомендации что указаны выше Панацея от всех проблем.

Они решат многие, но не все проблемы.

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

(С) Шарафан Александр (AXELOT, Москва)

———————————

Ряд проблем связан с утечками памяти.
1. Перезагрузите сервер.
2. Если у Вас 1 рабочий процесс, добавьте еще несколько, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса.

3. Если у Вас 32х разрядна версия сервера 1С, то пора купить 1С:Предприятие 8.2. Лицензию на сервер (x86-64).

Исследуйте роли «Пользователя», если они есть в типовой конфигурации конечно, и в частности, после того как вычислите проблемныйдокумент с помощью ТЖ, нужно найти проблемную роль (кто жалуется).
Далее для роли Пользователя смотрим РЛС документа, если дополнительных настроек нет (чисто), то правой кнопкой на нем — поиск ссылок на объект, и последовательно просматриваем РЛС для роли «Пользователь» для каждого объекта.

Ошибочное принятие высокой интенсивности пользователей за атаку на протокол в некоторых случаях Windows.
>Запустить программу regedit.exe, добавь новое значение типа DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и присвой ему значение 00000000
Имеет смысл делать для ОС Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx).

p.s. Кроме того, 54 ошибку можно получить на релизах <= 8.1.12.98 при ри конвертации конвертором ИБ 77(DBF) -> 81(SQL) в типовой ТиС (демо, взятой с ИТС) релиз. 954 в клиент-серверном варианте.
обойти можно так:
— выполните конвертацию в файловый фариант информационной базы 1С:Предприятия 8.1,
— выгрузите полученную информационную базу в файл,
— загрузите в клиент-серверный вариант информационной базы 1С:Предприятия 8.1.

Собрать логи ТЖ можно файлом logcfg.xml.

1С ошибка 10054 на Debian Squeeze

Удалённый хост принудительно разорвал существующее подключение

Удалённый хост принудительно разорвал существующее подключение

Удалённый хост принудительно разорвал существующее подключение

Данная ошибка с кодом 10054, критического характера, проявляется у пользователей в момент проведения записи. Чаще всего встречается у старых релизов 1С 8.2.

Скриншот ошибки 10054:

Вообще, появление этой ошибки, говорит о том, что происходит неожиданное для разработчика сервера 1С действие:

• приходит некорректный запрос;
• некоректные данные;
• запрос вызывающий большую выборку, с которой он не может встретится;
• частный случай: номер документа был больше, чем длина заданная в нумераторе;
• проверьте работу при отключенных антивирусах или firewall-е

Исправление:

Заключается в локализации проблемы, насколько это возможно:

• определении вида документа,
• регистра, с которым происходит ошибка,
• пользователя,
• компьютера.

Затем делается копия базы (средствами 1С или СУБД).

Если перезапуск сервера, решает проблему, продолжаете наблюдение. Добавьте скрипт рестарта службы ночью в нерабочее время.

Если перезапуск циклический проверьте не настроен ли у вас автоматический перезапуск в свойствах кластера:

Проводится тестирование и исправление с пересчетом итогов и реиндексацией таблиц.

Поднимается прежняя копия базы, в которой проблема наблюдается, сверяются находятся отличия, возможно это натолкнет на причину.

Если решить проблему не удается, следующим шагом будет настройка и анализ технологического журнала.

Что может выяснится в процессе:

• наличие вызывающих сбой регламентных заданий: например переиндексация полнотекстового поиска, не забывайте очищать переменные в таких модулях;
• для версии 8.2 можно попробовать добавить еще один процесс сервера, но не злоупотребляйте при недостатке памяти (в 8.3 это делается автоматически)
• отключите RLS (Контроль на уровне записей);
• нехватка места на диске или его медленная работа;
• очистка кэша пользователя, удаление временных файлов в Temp;
• проведите shrink(сжатие) таблиц в sql
  DBCC SHRINKFILE(ИмяБазы, 2)

Если нагрузка на сервер, на грани 100%, рассмотрите вариант разделения сервера базы данных и сервера 1С, обычно это замедляет, но стабилизирует работу (в 8.3 есть механизм общей памяти, который ускоряет взаимодействие сервера и).

• Добавьте память на сервер, если это возможно.
• Возможным решением, будет замена сервера на 64 битный, но для начала проверьте работоспособность у знакомых, где он стоит.
• Не помешает такая же проверка и на 32 битной, чтобы понять ошибка в данных или конкретном сервере.
• Выгрузка с загрузкой может устранить проявление.
• Крайней мерой рассмотрите перенос данных через конвертацию данных или догрузка данных в рабочую копию (длительная процедура)

Проверьте журналы Windows на предмет системных ошибок:

• в работе сети
• оборудования
• приложения
• перезапустите роутеры,свитчи (редко, но бывает проблемы именно в них)

Если проблема не решена в короткое время, возможно вам потребуется помощь сертифицированных администраторов или экспертов 1С.

Раньше люди нуждались в продуктах, чтобы выжить. Теперь продукты нуждаются в людях, чтобы выжить.

Источник

Windows Sockets — 10054(0x00002746)

Описание ошибки

server_addr=tcp:// :1562 descr=Ошибка сетевего доступа к серверу (Windows Sockets — 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение.) line=1031 file=.srcDataExchangeTcpClientImpl.cpp

Как бороться с этой проблемой

Настроить Технологический журнал и разобрать его логи.
Наиболее частыми причинами бывают падения серверной части 1С:Предприятия.
В также можно убедиться, посмотрев — ане создаются ли дампы (смотреть путь logcfg.xml, если настройка dump-ов в нем отсутствует, то в каталоге %USERPROFILE%Local SettingsApplication Data1C1Cv81Dumps, например C:Documents and Settings Local SettingsApplication Data1C1Cv81dumps. Падения платформы чаще всего могут возникать из-за запросов с нестандартными параметрами. Дампы отсылайте в техподдержку 1С email:v8@1c.ru.
1. Чаще всего мне встречалась проблема в журнале документов в отборах запросы были похожи на этот:

SELECT ALLOWED TOP 35 R.Date_Time A1,
R.Number A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
R.Fld9605 A13,
R.Document A14,
R.Marked A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Description
A17,CAST(R.Fld9606 AS REF(Reference52)).Description A18,CAST(R.Fld9611
AS REF(Reference93)).Description A19, CASE WHEN R.Fld9609 REFS
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Description WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Description WHEN R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Description WHEN R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Description END
A20,CAST(R.Fld9605 AS REF(Reference79)).Description A21
FROM DocumentJournal9604 R WHERE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) AND
(R.Date_Time > DATETIME(2006,12,31,12,0,0) OR (R.Date_Time =
DATETIME(2006,12,31,12,0,0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
ORDER BY A1 ASC, A14 ASC’

2. Пример лога ТЖ, показывающее причину падений сервера при обновлении полнотекстового поиска
11:40.9690-0,EXCP,1,process=rphost,p:processName= ,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:Program Files (x86)1cv81dumpsrphost_8.1.13.41_7d4e2366_20090609021136_10236.mdmp,Context=’
ОбщийМодуль.МодульРегламентныхЗаданий : 46 : ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);’

Итоговым решением в этом примере будет отключить фоновый процес в проблемной базе. Дождаться нового релиза платформы и обновиться.
Более подробно про падения платформы смотрите в моем блоге.
3. Пример ТЖ для циклический перезапуск процессов. Для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.
4. Убедиться, что причиной являются/не являются действия администратора в консоли

Ниже представлен вариант решения коллегой.

Всем заинтересованным в решении проблем с падением платформы с ошибками:

10051, 10053, 10054, 10064

Как показал разбор полетов по падениям платформы, с выше указанными ошибками:

— Большинство падений вызвано именно работой фоновых заданий, как и предполагалось в топике.

— Не хваткой дискового пространства

— Наличием большого числа не завершенных транзакций в журнале 1С

— Прежде чем заниматься разбором с технологическим журналом, проанализируйте используемые в конфигурации фоновые задания и отключите те, которые не требуются Вам для работы, конфигурации (банально, анализ 14 ГБ мусора можно считать времяпрепровождением, если Вам нечем заняться… :))) )

— Проанализируйте и внесите исправления в дописанные Вами фоновые задания, убедитесь в том, что они завершаются с нормальным кодом завершения (без ошибок и не закрытых транзакций)

— Внесите в алгоритмы фоновых заданий фрагменты кода, ошищающие, принудительно, память используемую в ходе их работы (Не стоит надеяться на то, что 1С при завершении особождает использованную память)

— Проанализируйте и ИСПРАВЬТЕ ПРОБЛЕМЫ ФУНКЦИОНИРОВАНИЯ типовых фоновых заданий конфигурации

— Выполните регламентные процедуры с базой данных, через пункт меню Администрирование-Тестирование и исправление, не забудьтеобязательно, выполнить сжатие базы данных

— Проанализируйте объем используемого пространства сервером SQL, вероятно что серверу банально нехватает памяти

— Проверьте политки настройки Active Directory

— И также сожмите/очистите журнал транзакций SQL вот примерно таким кодом (для SQL 2000):

Где pub_log — имя Вашей базы данных

Вариант 3:
sp_detach_db — отключим с данной процедурой базу, а sp_attach_db — подключим снова. Журнал транзакций при этом очистится.
(ПОдробнее можно прочесть в разделах MSDN Q256650 (для SQL 7.0) и Q272318 (для SQL 2000).)

Вариант 4: (Для 7.0)
DBCC SHRINKFILE (file_name, target_size)
DBCC SHRINKDATABASE (database_name, target_percent)
BACKUP LOG database_name WITH TRUNCATE_ONLY

Если после этих операций падения продолжаются, тогда продолжайте следовать рекомендациям:

— Пробуйте внести изменения в файлы HOSTS операционной системы (вероятнее всего будет достаточно прописать ассоцирование только в файлы на одной/двух машинах, где падения происходят наиболее часто)

— Пробуйте разнести сервера 1С предприятия и SQL, если они у Вас на одной машине.

— Или наоборот установите их на одной машине (если хватает ресурсов) Отмечаются случаи, когда именно перенос серверов на один сервер помогало (На мой взгляд очень сомнительно и больше относится именно к причине начала работы, это сжатие журналов транзакций)

— Проверьте время отклика сервера (вероятнее всего, что все будет в пределах нормы, а редкие провалы во времени обслуживания, не могут столь сильно влиять на работу сервера предприятия)

— Проверьте работу маршрутизаторов в сети (Редко, но бывает, что именно их перенастройка влияет на количество падений)

— Проверьте конфликты оборудования в сети (это к вопросу, почему желательно иметь оборудование одного поставщика в сети. Кто хочет может проверить, например, в тех. документации 3COM написано: если сетевая карта обнаруживает, что взаимодействует с аналогичной сетевой картой, то она может быть переключена в более производительный режим, засчет перехода на оптимизированный алгоритм обработки сетевых пакетов, проверено на личном опыте скачок производительности до 50%)

— Проверьте уровни сигналов у потребителей/конечных компьютеров (может быть банально, низкий уровень сигналов, постоянные повторные запросы блоков, задержка очереди на обслуживание в сети, а следовательно в конце концов получение сообщения, что конечный серевер разорвал соединение, когда количество попыток превысит время ожидания поступления сигнала. Если хотите разобраться в данном вопросе обратитесь к протоколу работы Ethernet/CSMA CD/CSMA. Количество попыток в передаче пакета по данному протоколу не бесконечно… ))) Да и буфер в картах тоже не беспределен.)

— Добавьте памяти на сервера

— Переведите часть/всех пользователей в терминальный режим (Т.е. обеспечьте то, что МНОГИЕ пользователи определеяют как ТОНКОГО КЛИЕНТА 1C). В качестве такого сервера я бы рекомендовал Citrix Metaframe или Terminal Server MS

Вероятнее всего, когда Вы выполните указанные рекомендации, за исключением разбора проблем с железом, стабильность работы возрастет настолько что падения платформы станут очень редкими, что перекроют технологические промежутки по обслуживанию базы данных, выполнять которые всеже НЕОБХОДИМО и не думайте, что те рекомендации что указаны выше Панацея от всех проблем.

Они решат многие, но не все проблемы.

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

Ряд проблем связан с утечками памяти.
1. Перезагрузите сервер.
2. Если у Вас 1 рабочий процесс, добавьте еще несколько, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса.

3. Если у Вас 32х разрядна версия сервера 1С, то пора купить 1С:Предприятие 8.2. Лицензию на сервер (x86-64).

Исследуйте роли «Пользователя», если они есть в типовой конфигурации конечно, и в частности, после того как вычислите проблемныйдокумент с помощью ТЖ, нужно найти проблемную роль (кто жалуется).
Далее для роли Пользователя смотрим РЛС документа, если дополнительных настроек нет (чисто), то правой кнопкой на нем — поиск ссылок на объект, и последовательно просматриваем РЛС для роли «Пользователь» для каждого объекта.

Источник

Устранение ошибки «удаленный хост разорвал существующее подключение 1С»

Причиной данной ошибки в основном является перезапуск рабочего процесса. Из-за увеличения процесса rphost, рост которого является причиной уменьшения быстродействия БД, системные администраторы прибегают к редактированию параметра перезапуска рабочих процессов. Вследствие изменения данных параметров служит отключение пользователей от БД.

Рекомендации по устранению ошибки

Вариант 1

Для того, чтобы освободить память от рабочих процессов 1С, рекомендуется использовать функцию автоматического перезапуска рабочих процессов. В параметрах локального кластера 1С необходимо установить интервал перезапуска 86400 секунд. Также нужно задать объем памяти 900000 Кб. Интервал превышения — 0 секунд.

Рисунок 1 — Параметры локального кластера 1С

Вариант 2

Использование более чем одного рабочего процесса, когда число пользователей меньше 100 человек. Данную настройку можно применить в параметрах рабочего сервера, который доступен в консоли администрирования 1С.

Рисунок 2 — Параметры рабочего сервера 1С

Вариант 3

Очистить серверный кэш 1С. Инструкция по ссылке.

Вариант 4

Также причиной может являться работа протокола IPv6. Отключение IPv6 через реестр на сервере, где находится роль сервера 1С делается так: заходим в реестр, переходим по пути:

HKLMSYSTEMCurrentControlSetservicesTCPIP6Parameters

Далее создаем запись «Параметр DWORD (32-бита)» с именем «DisabledComponents» и значением 0xff. Перезагружаем компьютер.

Источник

   SuperMario

13 — 02.05.18 — 18:27