Доброго времени суток, коллеги.
Слегка модифицирую поведение комплексной автоматизации с помощью расширений и раздражает задержка в случае заимствования процедуры в новый модуль. Причем, неважно чего: глобальный, формы, менеджера. При сохранении конфигурации все подвисает на этапе "проверка корректности метаданных" на 5-15 минут. Если же править текст уже существующего в расширении модуля, задержка в пару секунд. Пробовал ту же конфигурацию "снять с замков" и править по-старому, все достаточно быстро сохраняет. Такое поведение нормально или что-то криво настроено (ОС, SQL, кластер 1С и т.д.)?

PS платформа 8.3.14.1779/8.3.13.1690, win server 2012; sql server 2008 (10.0.2531). Расширение одно.

Имхо, это норма

(1) на более низких версиях платформы такой дичи не было

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

Я бы первым делом проверил на какие-то хитрые блокировки, которые вынужден ставить конфигуратор в режиме проверки корректности метаданных.

(0) У вас же сервер, на котором выполняешь разработку - это тот же самый, на котором все пользователи работают или отдельный сервер, где ты находишься в абсолютной изоляции от всех вероятных сеансов и других баз? Файловый режим в этом смысле дает тебе супер-монопольный доступ к конфигурациям, а на скл нужно обеспечивать изоляцию дополнительными усилиями - имхо!

(1) Подтверждаю, ибо пока решения не нашел. Та же история КА2.4 и несколько расширений.

+(4) пробовал на файловой, на виртуальном сервере с диким количеством оперативки и на SSD, на физике с таким же диким количеством оперативки на SSD.

(3) "где-то криво" - интуиция подсказывает то же самое.. но вопрос: где..

Это у тебя карма такая - за неумение ясно изъясняться, например. Радуйся, ибо у тебя есть шанс все исправить в этой жизни)

(5) Конфигуратору по*ую на оперативку при манипуляциях с конфигурацией, ЦП всегда узкое место при наличии ССД

(7) и чего не хватает в плане ЦП?

(8) Одного-двух гигагерц сверху обычно бывает достаточно для двукратного ускорения

(9) Попробую. Пока в сервак напихали только 5 процов по 4 ядра на 3GHz.

(10) В облаке бесплатно на денек возьми какой-нибудь от 3.5 ГГц хотя бы и разница должна сразу стать заметна

(3) Пробовал и на боевом и на резервном кластере, ситуация одинаковая. Скуль, правда, один и тот же.
Сейчас попробовал на файловом варианте на ССД. Время существенно сократилось, теперь надпись про проверку метаданных я вижу от силы пару минут. Против 10-15 на клиент-серверном варианте - это прогресс. Но какие блокировки могли быть в кластере, где одна база, один активный пользователь и одно расширение?

(12) ну если уж добить эту проверку до конца, то попробуй установить что-то такое
---
С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит  подбирать индивидуально под каждую конфигурацию сервера.
---
это отсюда http://catalog.mista.ru/public/626919/

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

(12) Почитал статью про оптимизацию. Все (ну практически все) это уже настроено. Но вот по процессу на каждую базу - это надо попробовать. Спасибо за наводку.

(12) = (13), конечно же :)

(12) мне так кажется что это обычное поведение системы, а 10-15 минут это ограничения процессора и файловой системы, у меня на ут 11 на файловой с ссд идёт полминуты, а в серверной на ловольно стареньком одну-полторы
Но на более ранней платформе эти же операции с расширениями были буквально несколько секунд, найдя схожие проблемы здесь, решил что это штатное поведение связанное с развитием функционала расширений

Поставил по рабочему процессу на одну ИБ. Вылезло ожидаемо три процесса: рабочая, разработка и дополнительная для внешних пользователей. Разбросало за сутки даже корректно, каждый процесс занимался своей базой. Разницы не заметил, как тупило, так и продолжает. Увы.
Да и если бы это и помогло, близится сентябрь и отсутствие лицензии КОРП вынудит поставить дефолтные 8/128.

Обычное поведение. У меня тоже самое на БП 3. Что в серверном, что в файловом варианте.

Канечно не 5-10 минут, минуты три наверно, но все равно ощутимо долго.

недавно ваял расширение для БП3 на 8.3.12....
не заметил проблем от слова вообще

(11) Где в облаке можно на денек взять Windows + 1C с моей конфигурацией? И чтобы лицензии были. А то обрадовался появлению сервиса на яндексе, а попробовать 1с не могу.

(17) "отсутствие лицензии КОРП вынудит поставить дефолтные 8/128" // К КОРПу относится только первый параметр (кол-во ИБ на процесс). Соединениями можно играться и без КОРПа.

(21) Надо искать, всякие промо-предложения (тест-драйв типа) постоянно меняются. Насчет лицензий и 1С не уверен, что они там будут, а зачем тебе они, не хочешь ломанную сам ставить? Почему?

(22) Играться соединениями на процесс не очень на 32-битном.. тут или вылетает по нехватке памяти, или тупит с инициализацией рабочих процессов и жрёт память сервера кэшем метаданных каждого рпхоста.. Вообще конечно они нехорошо поступили, что базовый параметр "количество иб на процесс" объявили корпоративным.. это для мелких контор более актуально, чем для корпораций, на которых 64-битный сервер.

(24) 32 выкидывай к херам из-за ограничений по памяти

А вообще, для 64 бит количество ИБ на процесс все равно критично для 1С уже не из-за расхода памяти, а из-за использования разделяемых блокировок. Далеко не всегда поведение оказывается предсказуемым и установка изоляции вида <<одна ИБ на один процесс>> хоть и увеличивает общий расход памяти на серверной машине, но очень хорошо выручает, когда уже не знаешь где искать висящие хвосты.

(25) Да вообще, по-моему, по умолчанию так и должно быть - 1 база на рпхост. Непонятно почему в 1с такие заоблачные цифры поставили, 8 баз редко где есть.

(24) "Играться соединениями на процесс не очень на 32-битном" // Как раз-таки очень - на 32б увеличение кол-ва рабочих процессов считай что бест практис рекомендуемый 1С

(27) Подключение к свежесозданному рпхосту намного тормознее, чем к тому на котором уже есть соединения.

(28) Отчасти поэтому бест практис по умолчанию для 64б - не множить рабочие процессы. Ибо памяти под процесс ОС уже хватает. В случае с 32б наоборот - размножение помогает не упереться в лимит 3 Гб.

Вот так все и ведутся на биты и гигагецы…
Берем типовую УТ 11.4.8.84, создаем расширение с одной галкой "активно" и режимом совместимости 8.3.12 как предлагается по умолчанию.
Добавляем в него одну форму обработки, например, ПодборТоваровВДокументПродажи
Больше ничего не делаем, сохраняем и запускаем проверку конфигурации расширения:
Получаем 57 ошибок на неразрешимые ссылки https://cdn1.savepice.ru/uploads/2019/7/10/bb3751674e68e449c8ba1eee130e8d45-full.png
и тормоза при сохранении.

Если при создании расширения в нем указать режимом совместимости 8.3.10, добавить туже форму и запустить проверку конфигурации - ошибок нет и отсутствуют тормоза при работе с расширением.

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

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

(29) помогает или нет, но дефолтно установленная 1с использует параметр один и тот же, что для 32 бит, что для 64 бит. Если нужно будет его  изменить, то будешь нарушать КОРП лицензию в той версии, которая нам сейчас известна.

(31) "дефолтно установленная 1с использует параметр один и тот же, что для 32 бит, что для 64 бит" // Выбрали то что более распространено и более отвечает промышленному подходу. 32б - песочница.

(32) когда "выбрали" ? еще в 2004 году?

(33) В 2012-2013 вроде 8.3 зарелизилась. До 8.3 количеством рабочих процессов рулил человек-администратор кластера (в консоли ММС)

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

(35) Ну так на денек же, для проверки. И железо хочешь в аренду забесплатно, и лицензии на 1С тоже? :)

(36) Всё нужно считать. Если максимальная мощность нужна допустим раз в сутки, остальное время можно спать. Дешевле ли это, если купить железо. ;)
Применительно к теме топика. Может быть админы-программисты будут практиковать такое. Зачем мучатся ждать на своём 20-ти процессорном сервере, если можно по быстрому в облаке сделать на одном 5Ггц CPU и быстром SSD. Правда 5Ггц никто не даёт пока.

(34) До определенного времени 32-битного сервера хватало, 4 гига адресного пространства редко какая конфигурация съедала. А потом да, как БСП и управляемые формы появилась, конфигурации резко разжирели.. Теперь в любом случае надо покупать сервер 64-бита, без исключений..