Как удалить зависшие сеансы 1с в клиент серверной версии

Как удалить зависшие сеансы 1с в клиент серверной версии

Доброго времени суток.
База 1С на 8.2 + SQL Server.
Недавно компьютер завершился аварийно.
После включения обнаружил что на сервере 1С Предприятия завис сеанс одного из пользователей.

При попытке удаления выдает следующее:
» ошибка удаления сеанса:
Ошибка информационной базы
Неверный формат хранилища данных ‘file://C:/Program Files (x86)/1cv82/srvinfo/reg_1541/snccntx/002.dat’ «

Лечится перезапуском сервера SQL и 1С.
Но после перезагрузки компьютера этот же сеанс снова появляется. Причем время начала сеанса не меняется (как будто сеанс не удалялся).
Сталкивался кто-нибудь с такой проблемой? Как лечится?

Зависшие сеансы в 1С 8.3.5

После перехода с платформы 8.2 на платформу 8.3 многие программисты и системные администраторы недоумевают, видя в консоли огромное количество зависших сеансов пользователей. Но не так страшен черт, как его малюют. Давайте попробуем разобраться.

Итак, картина выглядит примерно следующим образом:

Как мы видим, у сеансов отсутствует активное соединение и рабочий процесс. На каждого пользователя может быть запущено сразу несколько сеансов, но только один из них активный. Сеансы висят сутками и многих это пугает. Администраторы начинают принудительно их завершать. Но, на самом деле, страшного в этом ничего нет. Не многие двигают полосу прокрутки в списке сеансов вправо, где можно найти интересную колонку под названием «Спящий».

Так что же такое «спящий сеанс»?

Для повышения устойчивости работы клиентских приложений, в версии 8.3.5 реализовано удержание сеанса при оставлении программы без работы. Теперь, при длительной не активности или при засыпании клиентского компьютера, сеанс не завершается, а переходит в «спящий режим». При появлении активности, сеанс возобновляется.

Сеанс переходит в спящий режим в двух случаях:

1. При нештатном разрыве соединения, назначенного сеансу (для толстого клиента, внешнего соединения, тонкого клиента при прямом соединении с сервером). При физическом отключении сети сервер обнаруживает разрыв соединения с клиентским приложением в течение 2-3 минуты.
2. По истечении интервала времени, в течение которого клиентское приложение, использующее сеанс, не проявляется активности (для веб-клиента и тонкого клиента при подключении через веб-сервер). Если компьютер клиента не находится в режиме энергосбережения, и клиентское приложение бездействует (не выполняет никаких действий пользователя), то оно периодически вызывает сервер «1С:Предприятия» с интервалом 5-10 минут для поддержания активности сеанса. Поэтому не рекомендуется устанавливать время засыпания сеанса меньше 10 минут.

Любая активность приводит к пробуждению сеанса.

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

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

Подробнее на сайте 1С:ИТС : Сеансы и соединения


Можно ли изменить настройки?

Настройки времени засыпания сеанса и времени завершения спящего сеанса доступны в настройках ИБ (в конфигураторе меню: Администрирование — параметры информационной базы) .

По умолчанию время засыпания пассивного сеанса равно 20 минут, время завершения спящего сеанса — 24 часа.

Как удалить зависшие сеансы 1с в клиент серверной версии

Доброго дня
Подскажите, можно ли получить доступ к сеансам пользователей на сервере (с целью удаления неактивных) Без КОМконнектора? По выбранному варианту реализации нужно проверить при входе в базу наличие сеансов для текущего пользователя текущей базы и удалить те, что были подняты раньше. Такой вариант подразумевает безусловный подъем коннектора, что занимает время, чего не хотелось бы.

платформа 8.2.19
(0) А как вы предлагаете удалять сеансы без коннектора?
(2) я и не предлагаю, а спрашиваю, есть ли варианты)

(3) имхо придется все равно цепляться к кластеру по ком и управлять сеансами. По поводу активный/не активный сеанс вы вряд ли легко определите. Человек может отойти на несколько часов от компа с открытой 1ски, а сеанс его будет активным, так как 1ска оперативно отвечает на запросы кластера.

https://its.1c.ru/db/v8322doc#bookmark:cs:TI000000257
АдминистрированиеСеанс (AdministrationSession).
ЗавершитьСеанс (TerminateSession).
Синтаксис:
ЗавершитьСеанс()
Параметры:
(необязательный).
Тип: Строка.
Сообщение для пользователя, которое содержит причину завершения сеанса.
Описание:
Удаляет сеанс. Попытка обращения к кластеру серверов от имени удаленного сеанса вызывает исключение.
Доступность: Тонкий клиент, сервер, толстый клиент, интеграция.
Использование в версии: Доступен, начиная с версии 8.3.14.

(4) или так: для начала понять, есть ли то, что удалять, чтобы без КОМа, и если есть то только потом его поднимать. условия необходимости удаления сеанса тут я упрощаю, есть набор условий (именно активность — согласен, косвенный признак)

(5) «Использование в версии: Доступен, начиная с версии 8.3.14. «-> (1) платформа 8.2.19
(5) да видел, но с 8.3.14, прогресс в этом направлении радует конечно, но не всегда

(5) интересно.. если из базы на 8.2 через сервис отдать данные запускаемого сеанса в базу на 8.3 (сервер приложения есть обоих версий) и там анализировать и удалять.. взлетит? в (5) это быстро работает? имею ввиду, не поднимается ли там тот же ком, только скрыто/неявно, сервером приложения?

(9) А вы видите в данном методе возможность указать конкретный сеанс? Да даже если и была возможность, имхо не взлетело бы. Вы бы передали данные сеанса в другую базу, а ей потом что делать, когда у нее нет доступа в кластеру платформы 8.2?

(0) Установи консоль администрирования сразу же, чтобы не устанавливать по мере необходимости. На мой взгляд, остальное — не оптимально

(10) н да..
(11) чем поможет консоль, не понял, руками удалять?
(11) запускать ее батником с параметрами или что?

(12) если сеанс «завис» наглухо, то из консоли может не удаляться, так же как и «зависшие» фоновые задания.

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

+(14) это если консоль администрирования клистера 1С не помогает, а агента сервера 1С нельзя ребутать, ибо работают люди.

(14) (15) Ага, только на этом рпхосте могут быть еще Nое количество работающих юзверов))

(12) Конечно, руками. Я не представляю ситуацию, когда процесс убивания настолько часто нужен, чтобы этот процесс автоматизировать.

(17) Встречал на одном оптовом предприятии следующую реализацию: каждую ночь убивались все сеансы и перезагружалась служба 1с, вроде еще кэш чистили и все это по крону отрабатывало. На утро никаких зависших сеансов, все знают, что оставлять включенную 1ску не надо.

(18) в настройках раб.процессов можно настроить интервал перезапуска и ограничение по памяти, чтобы ребутался? тогда все активные сеансы мигрируют на другие менее загруженные рпхосты и чисто конкретный рпхост ребутается

(19) » тогда все активные сеансы мигрируют на другие менее загруженные рпхосты» — а вы даете 100% гарантию, что вводимые данные не пропадут у юзвера, когда ему рпхост грохнут и он успешно перекинется на новый рпхост?)

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

возможный вариант, как считаю: при входе в базу смотрим наличие сеансов от этого пользователя/компа в базе и если есть более «старшие» сеансы, то пробуем их удалить, с оповещением пользователя конечно, типа «у вас уже запущено, если хотите войти в этом окне, тогда другое будет закрыто автоматически, да?». Удаляем предыдущие. Да, могут быть глухие сеансы, но это уже другая часть вопроса, о которой можно так же админам кинуть на почту, что есть сеанс, который удалить не вышло, подумайте об этом. И они уже перегрузят Агента (если только кто нибудь не подскажет, что с такими сеансами кроме перегрузки службы можно еще сделать)

(17) у нас контроль запуска базы по несколько раз + попробовать не допустить зависших

(20) в общем я к тому, что лучше глянуть кто еще на этом рпхосте висит и предупредить этих юзверов, чтобы сохранили свои данные

(18)(19) у нас круглосуточная работа. грохать рпхост не вариант, да и потом — ни кто не гарантирует, что свежий сеанс не может повиснуть через 10 минут после начала

(23) А из-за чего у вас сеансы виснут? Сколько у вас пользователей одновременно работает?
(24) около 500, я думаю что скл косячит, админы так не считают
(25) У вас КОРП лицензия я надеюсь?)

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

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

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

(29) + то есть отдать на откуп пользователю

все это хорошо, напрягает только время подъема кома к агенту

(30) Вам бы по уму разобраться в причине зависания клиентов, а так это просто очередной костыль. Есть возможность протестировать работу на новой платформе? Может релиз глючный под такую нагрузку?

(31) хрен знает. вот ситуация: открываю док, меняю — «объект заблокирован, сеанс номер. пользователь..». Тут же + — понимаю, что внешняя софтина, которая грузит данные в базу напрямую ничего не грузит. Ковыряюсь что бы понять почему, ни виходит, ни панятна. Ладно, разберемся сначала с псевдосеансом. Открываю активных пользователей, там нет такого сеанса. Консоль, нашли, прибили — документ отпустило, софтина тоже заработала. То есть блокировка записей/таблиц скл, причем сеансом, который к таблицам внешней софтины отнощения не имеет. С ними собственно на запись только она и работает. Внимание, вопрос!?))

(32) Значит нужно с блокировками вопрос решать, у вас там управляемые блокировки?

дело в том, что этой проблеме с повисшими сеансами много лет, сколько помню всегда это было, то так виснут то так, то еще как то, разные варианты. Уже устойчивый стереотип, что связка сервер приложения + скл так и работает, это норма(с). Раньше были другие платформы, старшие, теперь эта, но проблемы идентичные. Хотя как вариант может предложить админам поставить посвежее 8.2. но сомнительно как то, что поможет.
пс. подписки/кривые коды вроде циклов без конца не рассматриваем — изучали, смотрели, криминала не найдено. При этом в момент висяка на скл (а бывает и такое, SDBL и остальное) админ присылает склный запрос и говорит — вот повесивший сервер запрос, смотрим — банальная выборка, простейший запрос. Да, данных в выборку попадает много, но с этим ничего не сделаешь, реальные данные, реальный «полезный» объем. А значит что? А значит производительность железа страдает. Админ отпирается, что на этом железе все должно летать, у вас код кривой. Даже как то предъявил, в контексте там тратата, спор да дело «ага, понятно — кривая реализация бегущей строки». Бегущей строки, Карл! кривая реализация млять. Криво нажали галку «БС» в свойствах надписи, ага. Ладно, лирика пошла.

(33) автоматический и управляемый

(34) «банальная выборка, простейший запрос» — выборка-то может быть банальная, только таблица в выборке уже залочена другим сеансом, который возможно что-то писал в эту таблицу через какое-нибудь ком соединение и повис. У вас вообще как с обменами через ком, популярная тема?

(35) это не про повисший сеанс, а про тормоза на скл. это приводит к «ошибка блокировки данных SDBL» на скл.
обмены идут, в основном сервисы, но есть некоторый функционал оставшийся на комах.

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

+ 36 да, ошибка блокировки может как следствие привести к потухшему сеансу, но если его не трогать(консоль, ctrl/alt/del на клиенте или еще как), то он отвиснет когда сервер просрется и выдаст результат. как мне кажется это только вопрос производительности сервера. нужен контроль количества сеансов от одного и того же пользователя ввиду подчистки предыдущих его сеансов (повисших и неповисших, нех одно и то же по несколько раз запускать), контроля использованных лицензий

(37) «то он отвиснет когда сервер просрется и выдаст результат» — не факт, может быть таймаут по истечению которого просто вывалится с ошибкой мол конфликт блокировок и ошибка скуля.

Как удалить зависшие сеансы 1с в клиент серверной версии

Полное или частичное копирование материалов возможно только с разрешения администратора сайта. © Softonit.ru

Иногда в процессе работы возникают случаи, когда зависают сеансы пользователей 1С(особенность платформы от компании 1С). Такое часто случается если завершать работу с базой неправильно (Нажать на крестик в правом верхнем углу программы). Возникает вопрос: «Как правильно закрывать программу 1с?». На рисунке ниже я показываю, более корректное закрытие окна программы 1С: Предприятие: в том же углу нажать на имя пользователя, а затем на гиперссылку «Завершить работу».

Что делать если сеансы все же зависли. При использовании клиент – серверного варианта работы, есть такое приложение как «Администрирование серверов 1С предприятие». Нужно открыть вашу Информационную базу (в примере это UT), по пути, указанном на рисунке ниже, и перейти в «Сеансы». В правой части окна мы увидим список всех сеансов пользователей, работающих с базой, выберем нужный, нажмем правой кнопкой мыши и нажмем «Удалить». Да совершенно верно- все так просто.

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