Платформа 8.2.15.319, СУБД MS SQL 2008. Пользователей ~110. Происходит эпизодически, причем может не проявляться 2 недели, затем выбрасывает одного пользователя и часто начинает выбрасывать случайных пользователей, помогает перезагрузка серверов.
Куда копать?

что говорит
технологический журнал?

(1) не запускал. Какое событие нужно отлавливать?

(0) мб не в тему, а журнал событий, связанный с СУБД сервером или 1С, не пробывали смотреть?

(3) админ смотрел в прошлый раз когда ошибки посыпались, говорил что нечего необычного там нету

(4) я вам скажу быть не может, у меня если пользователя китдает, то у СУБД есть ошибка. там вообще даже, если ошибка транзакции есть, и то должно быть Предупреждение событие у СУБД. у меня iBM DB-2 Express.
не верь админам, мой вообще мне такие вещи втирал, неделю на файловой работали, вместе СУБД, узнал, когда решил зайти в 1С, увидел путь ...

(2)
событие - исключение

учитывая Вашу тему v8: Оценка загруженности дисковой подсистемы на SQL сервере

какой протокол соединения сервера 1с и субд ?

если named pips -  то поменяте на shared memory или TCP .

(6) 1С сервер вроде TCP\IP протокол сам пробрасывает по умолчанию ...

(7)
неоднократно встречал  ситуации
что 1с8 соединялась с ms sql server
по протоколу
named pips

кто был инициатором 1с или ole db клиент - не знаю.

по поводу "вроде" желательно ссылочку.

(6) запустил журнал. Буду ждать ошибку

(9) открой в 1С сервере, центральный сервер - свойства. протокол у тебя там какой?

клиенты к серверу обращаются только по tcp, нечего там смотреть. А вот сервер может обращаться к СУБД по named pipes или tcp, по named pipes может обращатся если сервер 1с и субд расположенны на одной машине.

(11) На разных машинах сервер 1с и сервер СУБД

06:31.5890-0,EXCP,0,process=rphost,ClientID=121,Exception=NetDataExchangeException,Descr=Ping time out expired on connection

Вот такое исключение словил. Можно ли говорить что есть проблемы с сетью, если люди работают в терминалах и физической возможности аварийно завершить работу сети нету.

(13)
вот решение подобной проблемы
http://forum.wtware.ru/viewtopic.php?p=17420

(14) Почитал. Но у нас нету антивируса не на машине с сервером 1с, не на машине с СУБД

явная проблема с сеткой

(14)(16) Подскажите как понять в каком звене СУБД - сервер 1с  был разрыв соединения?

гипотетически подозреваю, что между сервером 1с и СУБД так как не указан пользователь.

либо проблема с сетью
либо стоит ограничение на кол-во одновременных подключений

причем это может быть как на уровне  так и на уровне ms sql

на уровне тср/udp как правило при сбое оборудования и аттаках.
на уровне ms sql - когда происходит преподключение (по-моему раз в час или в 2)
к субд, происходит долгое завершение сеанса (тоже до 2 часов)

например в developer версии по умолчанию доступно 5 подключений
и в случае коллизий два и больше процесса их могут исчерпать.

Сегодня проблема повторилась. В технологическом журнале в этот момент были следующие ошибки.

Ошибка SDBL:Открытых транзакций нет

Ошибка SDBL:Соединение с базой данных не удерживается. Отпустить контекст соединения невозможно.

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

Платформа 8.2.15.319. Толстый клиент обычное приложение

Еще в забыл добавить что есть АРМ в которые заходят через web клиенты

http://infostart.ru/profile/33726/blog/oshibka-sdblsoedinenie-s-bazoy-dannykh-ne-uderzhivaetsya/

(22) Попал я в замкнутый круг. При нескольких рабочих процессах в веб клиенте вылетает "Параметр сеанса не инициализирован", с одним процессом вылетает ошибка SDBL в обычном приложении.
Завтра попробую поставить 8.2.16.362

(23) ну как на 16 платформе проблема осталась?

(24) На 16 была ошибка sdbl, но не такая массовая. Еще на 15 заметил, что в технологическом журнале есть сообщения о дедлоках, сейчас работаю над устранением. Несколько рабочих процессов еще не пробовал включать.

Возможно, на все дело в "старом" локальном кэше
Попробуйте очистить локальный кэш пользователя.
Детали здесь: http://j008.ru/ps/024_Err_SDBL

Были подобные проблемы. Это может быть и проблема сети, и сбой в рпхосте, и проблема в данных. Для начала тетсирование и исправление запустите. А так много чего нужно проверить что бы отловить.

(27) Да что только не запускали. И ТиИ делали и технологический журнал смотрели. Кроме дедлоков нечего незаконного не нарыл. Решили проблему запустив 4 rphost и 1 из них 1 резервный.

(28) Уверены что решили:)? Подождите еще недельку.

Если будут проблемы - пишите, есть методики.

(30) Да уже недели 2-3 прошло. Я не уверен что рпхост не падает, но если он и падает, то коннекты подхватывает резервный. Так о каких вы методиках говорите? Расскажите проверю

у меня подобная проблемма была из-за паралельных маршрутов между серверами.

мне помогло http://kb.mista.ru/2/doku.php?id=it:set_dual_net

2(5) Оно у вас есть потому что до такой подробности настроен лог  инстанса ДБ2

Ну вообще то переключение на резервный(и так далее) и есть методика.(наверняка еще сервер перезагружаете) Только нужно разобраться с первопричиной, потому как чать пользователей испытывают эту проблему некотрое время.

(34) Рестартуем rphost средствами 1с, когда он разрастается больше 800мб. Рестартуем службу агента 1с раз в неделю.
Мне тяжело просмотреть все возможные "железячные" проблемы так как доступа у меня к железу нету, а админ довольно скептически относится к тому что, что-то может быть настроено не корректно с его стороны.
Из программных проблем есть только дедлоки примерно 15-20 раз в день. Могут ли они послужить причиной падения rphost?