Зависшие соединения в кластере 1С

16.05.2017 41 Comments

Администрирование, Администрирование данных 1С

Не адекватное поведение рабочего процесса в кластере 1С

Конфигурация: клиент-сервер

Server SQL 2008 r2

MS Server 2012

Версия 1С 8.3.4.389

Столкнулся с проблемой:

Бухгалтерия 3.0

Все началось с того, что бухгалтер запускает оборотку и никак не может дождаться её формирования. Отображается процесс формирования отчета… и все. Результат нет ни через пять минут, ни через час.

Поначалу думал, проблема в пользователе, но зайдя под своим акком увидел аналогичную картину. Ну думаю, счас архивчик сделаю, да натравлю на базу тестирование и исправление. Но при попытке создать архив получаю отлуп с сообщением о существующих подключениях в трех лицах! Я же только что посмотрел список активных пользователей и там никого не было! Фантомы, не иначе!

Дальнейшие события переносятся на сервер…

Смотрю список сеансов базы — только админ из конфигуратора и ни одного клиентского подключения, смотрю соединения… упс, вот они! Висят как приклеенные и из возможностей, только обновить картинку списка. Пошел в скл менеджмент студио… там тоже ничего нет! Ни одного подключения! В рабочих процессах отображается один процесс. Мало того, в остальных базах появились такие же фантомы соединений (не путать с сеансами). Такое соединение легко опознать по установленному признаку сеанса относящегося к данному соединению. Также сеанс не указывается для фоновых задач (это норма). Еще наблюдались не малые тормоза при работе с базами.

Не буду вещать обо всех своих мытарствах, если будет интересно, напишу.

РЕШЕНИЕ:

  1. Запускаем диспетчер задач
  2. Находим процессы с именами rmngr и rphost. В моем случае у меня был один процесс менеджера (как и должно быть) и ЧЕТЫРЕ рабочих процесса.
  3. Один из процессов не подавал признаков жизни вообще, т.е. не использовал времени процессоров и не менял объем используемой памяти. Контролируется это визуально и на приличном интервале времени… минут 10 — 15 хватит, чтобы увидеть зависший процесс.
  4. Как только убедились в неработоспособности процесса ПКМ на нем и килл.

Как только я это сделал (вальнул процесс), сразу сервер пересоздал его (процесс) и остальные процессы заработали пошустрее. В консоли управления ВСЕ фантомы исчезли. Рабочих процессов в кластере стало 4 (как и положено). По PID процесс невозможно было отследить, т.к. показывался всего один (рабочий, который тянул всех как мог).

В рестарте агента необходимость отпала. Все пришло в норму.

Какие есть соображения на этот счет? Может кто сталкивался с таким? 

Очень хотелось услышать мнение разработчиков ядра.

Related Posts

41 Comments

  1. DERL

    так что же это получается, что даже в версии 8.3 этот глюк не исправили?

    сейчас пока на 8.2.13 и периодически (пару раз в месяц) бывает виснет сервер 1С и ни один отчет на СКД не формируется (висит бесконечно значок формирования), в таких случаях я просто перезапускаю кластер серверов (Остановка сервера 1С — Запуск сервера 1С)

    Сервер Windows 2008 R2, SQL SERVER 2008 R2

    или может это вовсе не глюк 1С?

    Reply ↓
  2. juker

    (1) DERL, В том то и дело что Вы весь кластер перезапускаете, а мне надо поднимать кластер без его перезапуска.

    Да и кластер не корректно перезапуститься с подвисшим процессом (столкнулся с этим).

    А 1С разрабы наверное тут только руками разведут и никак не прокомментирую.

    Reply ↓
  3. juker

    (1) DERL, И валится именно один процесс из нескольких (как в статье описал). Это не может быть глюком системы ибо менеджер и рабочие процессы это составляющие единого целого, а не каждый сам по себе со связью многие (рабочий процесс) к одному (менеджер)

    Reply ↓
  4. asved.ru

    1) В свойствах процесса отображается его PID. Если процесс rphost с неким PID отсутствует в консоли — его надо валить, и нечего за ним смотреть.

    2) Включайте ТЖ. Хотя бы минимальный. Возможно, Вам удастся поймать причину. Пример:

    <?xml version=»1.0″ encoding=»UTF-8″?>

    <config xmlns=»http://v8.1c.ru/v8/tech-log»>

    <dump create=»false»/>

    <log location=»C:1c echlogexcp» history=»168″>

    <event>

    <eq property=»name» value=»excp»/>

    </event>

    <event>

    <eq property=»name» value=»excpcntx»/>

    </event>

    <property name=»all»/>

    </log>

    </config>

    3) Перед тем, как убивать повисший процесс, сделайте его дамп и отправьте в техподдержку. Не так давно об этом шла речь на партнерском форуме.

    В некоторых случаях помогает явное указание loopback-IPv4-адреса хоста для его имени в hosts. Пример:

    Имя компьютера: mycomp

    запись в hosts: 127.0.0.1 mycomp

    Reply ↓
  5. Vladimir_Konyrev

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

    Reply ↓
  6. juker

    (4) asved.ru, В консоли отображались процессы с точностью до наоборот.

    1. В консоли один процесс, причем, при получении информации о свойствах процесса возвращает пустоту на форме статистики процесса. Поле PIDa тоже пустое. В консоли отсутствовали те процессы, которые работали.

    2. В диспетчере задач 4 (четыре) процесса.

    Поэтому и пришлось заниматься наблюдением за повелением процессов в диспетчере задач. А вот за дамп… не знал о возможности/необходимости передачи дампа техподдержке. Если доведется (тьфу-тьфу), обязательно свяжусь с поддержкой.

    По поводу петли (127.0.0.1)… В каких конкретно случаях это помогает? Есть пример?

    P.S. При явном указании имени сервера на 127.0.0.1 для локальных служб сервера, ничего плохого в этом нет, т.е. хуже не будет. На своем сервере я сделал именно так, после Вашей подсказки. Включил ведение ТЖ. Посмотрим, может это как раз мой случай.

    Есть схожая темя http://infostart.ru/public/274466/ но в её случае там все видно, мой случай более тяжелый.

    Reply ↓
  7. juker

    (5) Vladimir_Konyrev, Вам очень повезло.

    Это второй такой случай у меня и в первом варианте было совсем все плохо.

    При рестарте службы, она перешла в состояние «Останавливается» без какой либо интерактивной возможности вмешательства средствами mmc (консоль служб) и все…. стоп процесса rmngr и всех rphost не помог, служба так и висела в состоянии останавливается. В итоге — рестарт сервака (жуть).

    Второй раз не хотел наступать на грабли и … результат Вы читали.

    Reply ↓
  8. Evmil

    Слава википедии, показала, что такое ПКМ — первый раз вижу сокращение в этом контексте, честное слово.

    Reply ↓
  9. juker

    (8) Evmil, Улыбнуло. 🙂

    Reply ↓
  10. hopter

    Поставил 8.3.5.1146

    Ситуация обратная — есть зависшие сеансы, а соединений к ним нет.

    Причем пока сеанс не удалишь из консоли даже перезагрузка сервера не помогает.

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

    Reply ↓
  11. necropunk

    А что мешает обработкой перебрать сеансы или процессы и грохнуть? Как визуально ты определяешь мертв процесс или жив? Перебрать процессы, посмотреть свойство MemorySize 10 мин. не меняется — грохать? Просто сейчас столкнулся с похожим, обработку накатал, перебираю файлы, сеансы, но не знаю как именно определить степень «мертвости» процесса 🙂

    (10) hopter, а это не могут быть регламентные или фоновые какие-нибудь вещи?

    Reply ↓
  12. hopter

    (11) не могут, т.к. висит сеанс толстого клиента без информации о соединении

    а само соединение разорвано пользователем и благополучно закрылось при его штатном выходе из 1с

    перед этим стояла 8.3.4.437, таких проблем не было

    и похоже не мигрируют сеансы при перезапуске рабочего процесса, пользователю выдается сообщение о принудительном разрыве соединения хостом

    пока убрал перезапуск рабочих процессов совсем, посмотрю несколько дней

    Reply ↓
  13. necropunk

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

    Reply ↓
  14. DJDUH

    Есть такое, что кильнул, а сессии зависли в SQL и все действия — с 1С-манагером бессмысленны! Только ребут SQL-сервера и браузера!

    Reply ↓
  15. juker

    (14) DJDUH, 1с манагер не помогает. Диспетчер задач и PID процесса в руки. Проблема реально решается без перезагрузки 1С сервера и тем паче скуля. А вот с зависшими скульными сессиями постоянно борюсь. Кстати касается не только 1С 8, еще и семерошную сессию скуль не завершает при некорректном выходе пользователя. В этом случае мне в помощь только Activity monitor — ПКМ на сессии, kill и все ).

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

    Reply ↓
  16. DJDUH

    (15) например у меня в скуле в диспетчере процессов завершаю зависшое соединение к базе,,, а в 1С манагере оно висит и не киляется — но, как только ребутаю Службу SQL-server и SQL-brouser — всё очищается!

    Reply ↓
  17. djam_arttek

    на версиях от 8.3.4 до 8.3.6 проблема не только существует но и прекрасно живет.

    Reply ↓
  18. DJDUH

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

    Reply ↓
  19. juker

    (17) djam_arttek, Проблему решил настройкой ограничений аппетитов процессов по памяти и времени существования процесса. Есть небольшое замедление в работе клиентской части, но отловить его можно только при замере производительности. Пользователю не видно изменений.

    В результате зависания и как следствие, тормоза, прекратились.

    Reply ↓
  20. djam_arttek

    (18) DJDUH, фоновые задания не имеют каких-либо ограничений, как и пользователи по дефолту имеют полныеправа… Это проблема не прав, а самой платформы.

    Reply ↓
  21. djam_arttek

    (19) можешь подсказать в какую сторону копать?

    К примеру проставил время жизни отключенного процесса 600 сек, однако эта настройка не работает.

    Reply ↓
  22. juker

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

    Вот мои настройки:

    http://slava.salincorp.com/wp-content/uploads/2015/05/Process_settings.jpg

    Reply ↓
  23. AlexAuto

    (22) С заполненными параметрами не работает, для применения параметров надо перезапускать сервер 1с?

    Reply ↓
  24. Гость

    У меня получается что если пользователь — сначала выключает 1с и потом уже терминал то все норм — а те кто сразу терминал закрывают вот только они и остаются подвешенными. — может кто подскажет как с таким бороться?

    Reply ↓
  25. juker

    (23) AlexAuto, Сорри за поздний ответ, который наверняка уже не актуален 🙂

    Да, конечно, службу следует рестартануть.

    Reply ↓
  26. Ujine1313

    у меня то же появились фантомные соединения. Но фишка в том что процесс висит в консоли 1С а вот в диспетчере задач винды его нету. и как удалить его не понятно(

    Reply ↓
  27. ArchanGelosZP

    (26) Ujine1313, Такая же ситуация, Рабочих процессов больше чем rphost ов

    Часть рабочих процессов в поле «Включен» стоит «Нет»

    и как убрать эти процессы непонятно

    Reply ↓
  28. ArchanGelosZP

    скрин

    Reply ↓
  29. ArchanGelosZP

    пока решил из*бистым методом

    — отсоединяю базу в скл

    — удаляю базу на 1с сервере

    — переименовываю файл и базу в скл

    — создаю новую базу на 1с сервере

    Reply ↓
  30. fuser

    платформа 8.3.6.2449 (x64) — проблема такая же

    Reply ↓
  31. gralex

    (29) ArchanGelosZP, Спасибо, помогло на 8.3.6.2449, правда админы поленились переименовывать базу в скл, заработало и так, после создания новой базы на 1с-сервере.

    Reply ↓
  32. dkonakov

    с недавних пор тоже самое началось, хоть толком ничего не менялось, добавились 2 новых юзера в УТ 10.3, платформа 8.3.6.2449

    Reply ↓
  33. MikeLetto

    Для отрубания сеансов в SQL может быть полезно:

    Отключение сеанса с перводом в offline. Offline можно не использовать.

    DECLARE @DatabaseName nvarchar(50)
SET @DatabaseName = N’MyBaseName’

DECLARE @SQL varchar(max)
SET @SQL = »

sel ect @SQL = @SQL + ‘Kill ‘ + Convert(varchar, spid) + ‘;’
fr om master.dbo.sysprocesses
where dbid = DB_ID(@DatabaseName)
—where spid in (select blocked fr om master.dbo.sysprocesses wh ere blocked <> 0) and blocked = 0
exec(@SQL)
print @SQL

set @SQL = ‘USE master
ALT ER   DATABASE ‘+@DatabaseName+’
SET OFFLINE WITH ROLLBACK IMMEDIATE’
exec(@SQL)
—print @SQL

    Показать

    Reply ↓
  34. juker

    (28) ArchanGelosZP, В версии ядра 8.2 существует возможность удалить/добавить рабочий процесс вручную.

    Используйте для этого ветку «Рабочие серверы» — «ИмяСервера» — «Рабочие процессы».

    В меню по ПКМ на «РАбочие процессы» можно создать процесс, а на самом процессе его можно удалить..

    Reply ↓
  35. juker

    (33) MikeLetto, Офлайнить базу — грубо и бессмысленно, если там 50+ пользователей и зависшие сеансы не мешают работе. Кстати, перевод базы в офф автоматом киляет все подключения к ней (при установке флага), там все отвалятся 🙂

    Помимо этого существуют контекстные блокировки (одна запись в таблице для SQL или один объект для 1С), когда открыт, например, элемент справочника номенклатуры и это нормальная работа подключения к SQL. В Вашем скрипте идет анализ количество блокировок не равное 0, что в корне неправильно. Поэтому автоматизировать убивание подключений у которых есть открытые блокировки в корне неправильно. Для этого существует и используется мной два инструмента, консоль управления 1С и SQLMS + Монитор активности. Причем указал в какой последовательности я использую эти инструменты.

    Reply ↓
  36. TVA_11

    2. Находим процессы с именами rmngr и rphost.

    Это помогло, но лишь до записи документа.

    В общем все похоже, а причина оказалась в падении Журналов. И процессы вешались когда ОБмен писал в журнал.

    Reply ↓
  37. Дмитрий74Чел

    (25) а вот и нет, перезапуск службы не требуется. Для проверки можете поставить интервал перезапуска любой (если был 0) — и увидите как начнут завершаться rphost`ы и создаваться новые. Вижу на 8.3.9, так было и на 8.3.8, и на сколько помню на 8.3.6

    Reply ↓
  38. juker

    (37) В обсуждении ядро 8.2.х.х уж не помню какое, но точно не 8.3. Когда производил настройку, предполагал автоматическое принятие изменений текущими процессами, но после долгого времени ожидания и нулевого результата произвел перезапуск.

    Reply ↓
  39. DiademGuards

    Также была проблема с зависшим рабочим процессом. Удаление процесса rphost из Диспетчера задач по номеру PID не помогло, в Консоли кластера процесс так и остался. Перезагрузка службы сервера не помогла.

    Решение:

    — посмотреть порт зависшего процесса

    — в диспетчере задач если не включена колонка CommandLine

    — найти процесс rmngr с нужным портом и завершить дерево процессов

    После данных действий зависший рабочий процесс с консоли ушёл

    Reply ↓
  40. juker

    (36)

    писал в журнал.

    Хорошее замечание!

    Журнал SQLite использует и при его большом объёме вполне возможны такие варианты развития событий.

    Длительность зависания смотрели?

    Reply ↓
  41. TVA_11

    (40)

    Насколько помню, висел неограниченно.

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *