Доброго времени суток уважаемые эксперты! Нужна ваша подсказка: До 2022 была УТ10.3, перешли на КА 2.4.6.231 с 2022. Базы дописанные -и в расширение конфигурации и самой конфе. При динамическом обновление конфы, начинаются тормоза и 1ска виснит у всех у всех юзеров в течение минут 15. В компании работает в КА около 60 человек. В УТ10.3 небыло тормозов при динамических обновлениях, в КА появились. Изменения вносим целый день.

Подскажите у кого нибудь начинаются лаги после Динамического обновления изменений в конфу (не РК)?
Куда копать в данном случае?

У всех. Не обновляй динамически.

"Изменения вносим целый день." Чего вы там делаете?

(0) фантастика.....
это, видимо, способ такой поскорее свернуть бизнес в ноль....

А почему не тормозило на обычных формах при динамических обновлениях?

как бы странно...

На кой ляд у вас перешли на такой релиз конфы, если работаете с текущего года?! Релиз сабжа еще от февраля 19-го года.

Получается предполагаемая картинка, что конфу перепахали вдоль и поперек, чего-то там расспалось с нее куда-попало.
Обновлять ее просто не реально. Да и не нужно никому.

Кто с таким отношением к переходу заставлял в нее лезть... Лучше бы тогда на УТ 11 взяли.

Как она вообще работает после этого - вообще чудо.

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

(5) я согласен во многом с Вами Фрэнк. На то были причины. Но вопрос в том - у всех ли лагает при Динамическом обновление на управляемых формах?

(0) То, что само по себе динамическое обновление работает у вас на продуктиве, уже чудо и фантастическое везение. Тем более, что вы ещё и  делаете его по несколько раз в день.
Делать динамическое обновление и даже просто подключать расширения (что по сути тоже является неявным динамическим обновлением) в продуктиве нельзя.
Можно 1000 раз успешно обновиться динамически, а на 1001-м обновлении словить баг.

Мы когда-то тоже активно этим баловались. Пока пару раз на разных релизах платформы в разных базах не словили глюк. Обошлось всё лёгким испугом, но только благодаря тому, что оба раза нам быстро сообщили пользователи (кому-то понадобилось выйти из базы и зайти заново, а при входе выскакивала ошибка формата потока), и сработало стандартное лечение в виде чистки таблиц конфигурации в скуле.
После этого все обновления и расширения ставим/подключаем только вечером в период технологического окна, когда в базе никого нет, с установкой блокировки соединений (в монопольном режиме).
Всех пользователей, ноющих о срочном и незамедлительном накатывании исправления/обновления, отправляем к руководству. Почему-то сразу выясняется, что проблема установки патча вполне может подождать до завтра и к начальству никто не идёт. Кроме совсем уж крайних случаев, когда выгоняем всех из базы в середине рабочего дня и накатываем обновление на продуктив (опять таки - монопольно, без динамических обновлений).
Простой базы в случае глюков динамического обновления - слишком дорогое удовольствие. Даже в самом лёгком варианте. А потенциальные риски, если вдруг потребуется откатить пару часов работы пользователей (с момента установки динамического обновления до момента выявления проблемы), вообще безумных денег.

(6) Нет.
На нормальных релизах платформы от динамического обновления вред не накапливается.

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

Другое дело, что нет никаких четких гарантий, на каком релизе словишь "ошибку потока". И в какой момент.

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

Не готов перечислять по номерам, но в некоторых релизах и с расширениями вообще возникали проблемы, а не только с каким-то там динамическим обновлением.

И кстати сказать, есть такая политика у тру-админов :-) чтобы автопатчи от 1С в базах не разрешать. Категорически! Ну есть такое, распространенное это мнение.

(7)[просто подключать расширения в продуктиве нельзя]
бред

(0) Странный способ разработки. Сразу вспоминается:"А стоя в гамаке не пробовали?"

(6) нет, всё норм. Демоническое обновление не оказывает никакого влияния на работу базы.

(7) Редкостный бред.

(7) а что в нём не так ? У нас делается.. постоянно, и по несколько раз в день. Всем пользователям вырублено сообщение о необходимости перезахода.

На всякий, висит триггер на сохранение конфиг, но за несколько лет ни разу не пригодился.

Демоническое обновление отличный способ убить базу,не на 10 раз,так на 20.Не верю что все нужно так срочно,что тех.окна подождать нельзя

(13) А зачем? Так быстро пишите? Или косячите? :-)

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

(15) брехня, на 8.3 давно уже ничего не убивается

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

(18) Раз в неделю действительно как-то немного.

А как с метаданными? Как писать доработки без изменения структуры данных?

(9) (12) (13) Можете что угодно считать. Ваше дело.
Я пишу о том, что есть. Динамическое обновление и подключение расширений к продуктиву при работающих пользователях - это лотерея. Вы можете никогда не столкнуться с проблемой. Я сталкивался по меньшей мере 4 раза в разные периоды времени, на разных версиях платформы и разных конфигурациях (и обычные формы, и управляемые). Три раза - на динамическом обновлении, один раз - после установки расширения (самое обычное, без расширения данных).
Простой поиск по форумам показывает, что не я один такой "везучий". Более того, не всем и не всегда помогает стандартный метод лечения проблемы с очисткой ConfigSave. Мне везло.
Убить совсем базу динамическим обновлением,  действительно вряд ли получится. Но отхватить геморроя - легко.

(15) >> на 8.3 давно уже ничего не убивается.

Может конечно за последние годы в этом вопросе 1С какого-то прорыва добилась, а я об этом не знаю... Возможно. Уже несколько лет как не пробовал и нет особого желания возвращаться к этой практике. Тем более, что в 99.9% случаев оно никому не нужно, и вполне себе может дождаться технологического окна. Для установки обновления без реструктуризации более чем достаточно пяти минут. Не так уж часто встречаются такие базы, где невозможно выделить такое окно хотя бы раз в сутки или двое.

(19) меняется в основном, программный код или форма.
Сами метаданные (новые объекты) довольно редко.

(14) поделись триггером, плз, чтоб лисапед не шизобретать...

(22) на нимфостарте валяется готовый

(19) со структурой там как раз нормально сделано в новых платформах. Задается вопрос "Завершить сеансы пользователей"? И пользователи автоматом выкидиваются.

(21) Понятно.

(23) ага, нашел, спасибо!

(26) https://infostart.ru/1c/articles/327674/

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

(24) не всегда.
Вообще единственный минус при демоническом - не всегда корректно пофигуратор определяет, могёт ли он изменения демонически обновить или нужна реструктуризация.
Иногда спасает возврат к конфе иб и по-новой накат изменений с cf, иначе говорит - болт тебе , а не динамика.
А иногда, даже при такой схеме, грит хочу реструктуризацию..хоть тресни, хотя метаданные не затрагиваются. Закономерности не понял. Скорее всего есть какое-то критическое число изменений в коде/форме/объектах, которые "потрогал" , при которых динамику не даёт.

Но вот, поломки пока еще ни разу не было.
Да были там траблы с кешем пользователей, но это мелочи.

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

(29) ну, так и штатно, пока пользователь не перезайдёт в 1с, у него будет старый алгоритм..За это время конфа может раз 5 поменяться.
Если алгоритмы не критические, на это забиваешь. Если критичные для всех - всем сообщение через повершел на всех серверах и со спокойной совестью изгнание из 1с-ины

Раньше, им фоновое писало, что дескать конфа поменялась, перезайдите.
Товарищи это игнорили, а потом и нытью - что часто выскакивает.
Отрубили к едрени фени, чтоб не буйствовали.
:)

(28) всегда происходит. Я чтобы выгнать пользователей просто добавляю реквизит в небольшой справочник, например, Бригады. Всегда выходит сообщение "Завершить сеансы пользователей".

(30) в том и дело, что перезаходили. Есть два юзверя, работающих с данным модулем.  Изменения динамические. Перезашли оба юзверя и заказчик. заказчик проверяет - все нормально. Дает отмашку. наутро под одним юзверем по новому алгоритму, у второго - по старому.. выходят два других на смену - у них обоих работает по старому... Вылечилось только нормальным "монопольным" сохранением конфиги...

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

(33) такое ловили, да.. кешу приходилось у пользака чистить

(30) Это кстати ещё один довод против динамического обновления и подключения расширений при живых подключенных пользователях.
Каждый не перезашедший живёт в своей версии конфигурации. И версий таких может быть несколько. А если какой-нибудь особо талантливы пользователь любит одновременно открыть несколько окон (соединений) с базой и в каждом из них работать с одними и теми же объектами, последствия вообще трудно предсказуемы, если в каждом таком окне окажется своя версия конфы.
Про то как работает пользовательский кеш уже притчи можно слагать. А правило "В любой непонятной ситуации начинай с чистки кэша везде и всюду" уже становится золотым стандартом работы 1С-ника. Увы.

(34) так оно и не выходит. это на уровне платформы, если структура не изменилась, появляется кнопка "Обновить динамически".

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

В КА2/ERP есть восстановление последовательности, его нужно делать? А то выбираю Проведение документов, а вкладка Восстановление последовательностей недоступно!? Может в настройках нужно что-то включить, что?

(39) а зачем ? У вас чего, партионка ?

(40) Партионка осталась только в Альфа-Авто. Далее документы переносим в УПП, где она заменена РАУЗ, но бухгалтер говорит: правильно НДС рассчитать нужно ГП Расчеты по реализации организации восстановить. Переходим на КА2/ERP, там надо ГП восстанавливать?

(41) и вы в ерп учетную политику по фифо ведёте, или рауз в затратах?

(42) От учетной политики зависит? Как настроить? В демо-базе вкладка Восстановление последовательностей тоже недоступна.

(43) хз как там в ерп слепили, в упп был отдельный РС

(44) В ранних версиях до 2.4 пробовал проводить регламентные работы по закрытию месяца. Вроде среди них было восстановление ГП. А теперь ненужно как в УПП после отмены партионного учета, а КА2/ERP всего остального.

Даже в конфигураторе общей формы ПроведениеДокументов нет!? Есть обработка Проведение документов по видам учета, но в ней нет Восстановление последовательностей. Может не нужна теперь?