Перешли на новую платформу на выходных.

8.3.15.1700
лицензия ПРОФ
кластер из 2х центральных серверов и сервера лицензирования

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

В понедельник, когда пользователей стало много, заметил, что по сравнению с предыдущей версией платформы стало гораздо больше рабочих процессов (15-30). При этом они все маленькие - максимум по 1-2 Гб, тогда как раньше было несколько больших процессов по 10-20 Гб. Уведомления о недоступности порта 1560 продолжают сыпаться: до доступен, то опять недоступен (в среднем по 5-7 мин). Проверяю telnet - порт действительно не отвечает.

И мне вот непонятно в чём проблема? В обновлении кривизна какая-то засела. Или это так совпало, что в сети проблемы появились? Ещё до кучи в процессе обновления был добавлен сервер лицензирования (раньше лицензии были на одном из центральных серверов), что тоже добавляет переменных в уравнение.

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

Помогите чем сможете, плиз!

Зачем перешли знаете?

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

(2) Зря решили.Я бы откатился бы до 8.3.14.

(0) Соберите ТЖ.
Если есть типовые, то  8.3.15  может сыпаться при регламентном пересчете агрегатов.

(2) пускай те кто решил и разгребают
Не знаю как с 8.3.15 но на 8.3.13 проблема перезапуска рпхоста была в связи с внешней компонентой печати шк, которую тех поддержка сказала обновить из новой бпо

А с чего ты взял что 1560 должен быть доступен?

(4) подскажите, пожалуйста, какие события собирать?

(5) у нас такое по идее не используется, торговли нет

Пока настроил так, посмотрю что поймает:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
<dump create="true" location="F:\Logs\Dumps" type="3" prntscrn="true"/>
<log location="F:\Logs\" history="1">
  <event>
   <eq property="name" value="proc"/>
  </event>
  <property name="all">
   <event>
    <eq property="name" value="proc"/>
   </event>
  </property>
</log>
</config>

Поймал дамп аварийно завершённого процесса. А в ТЖ записи только такие:

48:50.099000-0,PROC,0,process=rphost,OSThread=9116,Txt=Process terminated. Stopped on error (working)
48:51.052001-0,PROC,0,process=rphost,OSThread=6996,Txt=Process terminated. Stopped on error (working)

Ничего непонятно, наверное, надо в ТП 1С обращаться...

(8) Ну а excp где?

Причину падения рпхоста невозможно установить по ТЖ. Нужно отправлять дамп в 1с

(11) Можно, Миша, можно.

(10) excp поставил, дождался пока будет пойман дамп аварийно завершённого rphost, но инфа в ТЖ мне ни о чём не говорит. Либо какие-то несущественные исключения, либо что-то непонятное, а потом раз и рабочий процесс завершён. Как бы ничего не предвещает. Конечно, надо бы чтобы 1С-ники посмотрели дамп. Буду им писать...

Тоже наблюдаем похожее. 8.3.15.1700.
длинный колл с большим мемори пик, потом вылет
08:25.746002-2624990,CALL,2,process=rphost,p:processName=BaseTest,OSThread=11200,t:clientID=7,t:applicationName=Designer,t:computerName=Komp1,callWait=0,Interface=ef207edb-9db6-4e8e-ad4b-d20992a2853a,IName=IServerInfoBase,Method=1,CallID=30710,MName=connect,Memory=58735937,MemoryPeak=119171987,InBytes=12008165,OutBytes=17747017,CpuTime=2500000
08:25.746006-1,SCALL,3,process=rphost,p:processName=BaseTest,OSThread=11200,t:clientID=7,t:applicationName=Designer,t:computerName=Komp1,t:connectID=9656,ClientID=1,Interface=0459eaa0-589f-4a6d-9eed-c1a7461c8e3f,IName=IClusterRegistry,Method=27,CallID=28609,MName=getRegistryVersion,DstClientID=30973
08:25.762011-0,EXCP,3,process=rphost,p:processName=BaseTest,OSThread=11200,t:clientID=7,t:applicationName=Designer,t:computerName=Komp1,t:connectID=9656,SessionID=86,Usr=Usr1,AppID=Designer,Exception=e0417abc-63b4-461b-b1b6-01d2d2b0cca5,Descr='src\SrvrInfoBaseImpl.cpp(9344):
e0417abc-63b4-461b-b1b6-01d2d2b0cca5: На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто'
08:25.762013-1,SCALL,3,process=rphost,p:processName=BaseTest,OSThread=11200,t:clientID=7,t:applicationName=Designer,t:computerName=Komp1,t:connectID=9656,SessionID=86,Usr=Usr1,AppID=Designer,ClientID=1,Interface=90b77326-8e4a-4195-b980-d758277d1f03,IName=ISeanceContextStorage,Method=8,CallID=28613,MName=detachSeanceIB,DstClientID=30973
08:25.762014-11,CALL,2,process=rphost,p:processName=BaseTest,OSThread=11200,t:clientID=7,t:applicationName=Designer,t:computerName=Komp1,t:connectID=9656,callWait=0,Usr=Usr1,SessionID=86,Interface=ef207edb-9db6-4e8e-ad4b-d20992a2853a,IName=IServerInfoBase,Method=42,CallID=30725,MName=attachServerSeance,RetExcp=На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто,Memory=33905,MemoryPeak=46389,InBytes=0,OutBytes=0,CpuTime=0

(14) Одни designer в списке. Форму штоле открываете в конфигураторе?

(15) да, сервер разработки. в том то и дело что не форму. ошибка проявляется даже если разработчик ничего не делает с базой
симптомы 1в1 как тут https://partners.v8.1c.ru/forum/topic/1862616
только нам обновление компоненты не помогает

(16) не видать....

(16) вот думаю попробовать обновить компоненту. Не подскажете как это делается?

качаете с юзерс библиотеку подключаемого оборудования ред 2.1.3, находите там компоненту 9.0.6.4, обновляете свою.

*компоненту печати штрихкодов.

(0) Так может zabbix и валит rphost своими домоганиями...

(19) Уже вышла версия 9.0.6.5. Тоже 83.1.5.1700 и тоже падения и тоже буду обновлять компоненту. :)

(16) Компонента несколько по-другому себя проявляет, потому и не помогает.

(23) а как устаревшая версия компоненты вообще может приводить к аварийному завершению rphost?

(24) Элементарные баги, это ж бинарник.

(24) Она исполняется в контексте rphost. Соответственно, если в ней возникает необработанное исключение - она валит rphost. Причем со времен 8.1 стойкость к нестабильным компонентам только снизилась.

(22) держите в курсе. мы пробуем 8.3.15.1747

(27) попробовали, платформа 15.1747 любой при пометке удаления  в предприятии спрашивает 2 раза(чтоо?), при изменении(любом) в панели разделов пропадает сама панель пропадает совсем из видимости(!) https://bugboard.v8.1c.ru/error/000060875
думаем про 14ю, есть у кого-нибудь информация про стабильный релиз?

(28) сидим на 8.3.15.1565. Вылетов при сохранении конфы нет.

(28) 16.1063 - прям конфетка по кол-ву исправления реальных проблем, если б не одна критическая для нас ошибка, она пока в статусе "Обработано", непонятно, будут ли в 1с реагировать на нее ....

(30) Принтеры починили?

(31) Частично :-)
Так, вроде, еще в .1048.
У меня тоже неразрешимая проблема с "принтерами", но со специфичными, этикеток.

(28) какая еще конфетка? 6 исправленных ошибок. Это не считая "еще не изведанных".
У меня вообще ощущение (не проверял еще) что с выходом нового релиза (3/14/15) 1С просто сбрасывает счетчик ошибок. Открываешь список ошибок в первом релизе версии - почти пусто, в следующем - 50 ошибок, в следующем - 100 и так далее.

(33) 6 - в самом последнем. А сколько еще было исправлено в пред.-х 6-ти релизах 16-й

(34) А уж сколько новых было добавлено :)

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

Короче, т.к. мы перешли с 14-й версии на 15-ю (а в ней исчезло несколько функций в настройках кластера), то могли залипнуть старые неактуальные параметры. Посоветовали либо кластер пересоздать, либо отредактировать файл настроек C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst

У нас было так:
{0,
{15030fd8-168f-4254-a02a-dc32fc85a6a8,"Рабочий 2019",1541,"SRV-S1CM5",0,1,0,0,0,0,1,

А надо так:
{0,
{15030fd8-168f-4254-a02a-dc32fc85a6a8,"Рабочий 2019",1541,"SRV-S1CM5",0,0,0,0,0,0,0,

Сегодня посмотрю поможет ли...

(36) это ж как раз закручивание гаек по КОРП

(36) не помогло.

Сначала казалось, что стало лучше, но в 10:30 примерно всё опять вернулось на круги своя... Хз, стоит ли пробовать пересоздать кластер...

(37) Не, это нововеедения 8.3.15, к КОРП не относящиеся - просто тупо убрали один из параметров кластера. Потом в финальном 8.3.15 вернули взад.

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

(40) Кластер пересоздавать не стали, просто откатились на предыдущую установленную версию платформы.

Я писал в начале, что мы вместе с обновлением ещё сервер лицензирования настроили, так вот, сейчас думаю, а не он ли это чудит. Вот, проверим. Если сегодня всё будет нормально, значит платформа. Если опять та же картина, значит сервер лицензирования...

(40) Скоро обед, пока полёт нормальный. Всю прошлую неделю к этому времени уже была жопушка: пользователей выкидывало постоянно, процессы на сервере плясали/перезапускались. Сейчас работает так же как и до обновления платформы, тьфу-тьфу.

(42) сейчас ограничения ИБ на процесс и ограничения по памяти стоят? какая в итоге платформа?

Платформа 8.3.14.1779, как и была до обновления. Все настройки по умолчанию, т.к. лицензия ПРОФ.

У нас постоянно падал рпхост начиная с 14 платформы при вызове метода сдвинуть на последний элемент объекта форматированный документ, при рассылке писем в конфигурации ут 11 + рарус срм.

(44) 1779 ?
А это видели:
Исправлено в .1854


Рабочие процессы кластера серверов
Код ошибки: 00112716
Код(ы) обращения: SW1348971
Статус: Исправлена в выпущенной версии Зарегистрирована: 24.12.2018
Исправлена: "Технологическая платформа", версия 8.3.14.1854

Описание:
В клиент-серверных информационных базах могут происходить аварийные завершения рабочих процессов кластера серверов.



Потеря соединения с СУБД
Код ошибки: 10204580
Код(ы) обращения: CSR-33373 CSR-33569 CSR-33859 CSR-34168
Статус: Исправлена в выпущенной версии Зарегистрирована: 07.12.2018
Исправлена: "Технологическая платформа", версия 8.3.14.1854

Описание:
В клиент-серверном варианте информационной базы при потере соединения с СУБД может происходить аварийное завершение работы рабочего процесса.




Клиентское приложение не получило клиентскую лицензию
Код ошибки: 10212277
Код(ы) обращения: CSR-33909 CSR-34222 HL-22668 HL-70443 HL-70482
Статус: Исправлена в выпущенной версии Зарегистрирована: 02.07.2019
Исправлена: "Технологическая платформа", версия 8.3.13.1926
Исправлена: "Технологическая платформа", версия 8.3.14.1854
Исправлена: "Технологическая платформа", версия 8.3.15.1534

Описание:
В клиент-серверном варианте информационной базы при попытке подсоединения к информационной базе толстого клиентского приложения или внешнего соединения (V83.COMConnector), не получившего клиентскую лицензию, может происходить аварийное завершение процесса менеджера кластера, если раздача клиентских лицензий сервером 1С:Предприятия запрещена.

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

Вот сейчас стоит вопрос на какую обновляться, т.к. обновляться всё равно надо. Вышел новый релиз конфигурации ЗУПа, и он хочет не меньше 8.3.14.1976...

(47) У самого подобные проблемы...
После 8.2 можно забыть, что такое стабильная работа, особенно не на совсем типовых....

Нашёл в багтрекере эту ошибку: https://bugboard.v8.1c.ru/error/000061978

Скоро предстоит обновляться на версию не ниже 8.3.15.1778 (долбаные обновления конфигураций бухгалтерии)... Будет весело, кажись.

а сколько у вас серверов в кластере?

(50) 2 центральных сервера и ещё сервер лицензирования.

Ответ техподдержки 1С после анализа дампа и ТЖ:

"В результате анализа стека установлено, что дампы являются дублем открытой ошибки 40000903.

Ошибка пока в стадии рассмотрения"

Думаю, потом посоветуют обновиться и всё =)

(52) открытой ошибки 40000903 - это та про которую вы пишете в (49)?

Нет. Я спросил об этом с след. письме в техподдержку и они ответили, что это другая ошибка...