Количество баз на сервере около 120. Все типовые БУ, ЗУП, КА. очень высокая загрузка процессора под 100% при этом в базах никого нет. во основном нагрузку создают рег. задания. Отключение Обновление индекса ППД благотворно влияет на производительность. Но во всех базах его отключать наверное не выход... кто как решает подобные задачи с таким количеством баз?

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

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

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

(2) *проце=ядре

(0) Запуск первого сеанса на пустой базе регламентным заданием - очень ресурсоемкое занятие.

На ИС была статья исследование на эту тему.

Там итог статьи в общем - само поднятие 1го сеанса и есть проблема

Что делать:
1) Ждать, когда вендор обратит на эту проблему внимания
2) В типовых очень много рег заданий с интервалом 10-60 секунд, взять тот же ДО. Увеличивать интервал запуска до раз в час\день.

http://catalog.mista.ru/public/996126/

(8) Изучил это какая то багофича начальной загрузки данных в память процесса при холодном старте.
Для случая около 120 баз это лютый ахтунг.

Интересно поможет ли создание в каждой базе пустого фонового задания которое постоянно выполняется но не нагружает сервер.

"что есть регламентное задание? некая процедура написанная на языке 1С Предприятия и размешенная в общем модуле. сервер 1С по расписанию запускает регламентное задание, а чтобы его запустить, необходимо загрузить конфигурацию ИБ и обработать указанный общий модуль препроцессором, скомпилировать в байт-код, а это все процессорное время даже без выполнения задания.
а когда существует активный сеанс к ИБ, то контекст на сервере уже подгружен, но это уже размышления на заданную тему, может оно и не так ) может и фантазирую."

И еще в комментариях
"А нельзя запустить постоянно работающее регламентное (фоновое) задание? Ну задержка в цикле там или еще чего. Цель - постоянно держать соединение.
И пусть оно крутится на каждой из баз. "

(9) Задержка в цикле - проц грузит же.
Можно взять ВК от ЦУП, там есть слип, и им уже держать соединение

Чисто теоретически - должно помочь.
но как будет на практике - не знаю

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

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

Всяческие там новости, проверка обновление и прочие встроенные в типовые сервисы типа спарк-риски и прочее.
Отрубить их нафуй чтобы не выполнялись при старте.

(12) Эти все перделки включаются в модуле управляемого приложения и при регламентном задании не влияют никак

(13) Не факт что они тоже не запускаются даже при серверном/служебном сеансе первом.

И еще может быть банальная проблема нехватки оперативки на каждый такой сеанс.
Надо чтобы для одновременного холодного старта было >4 гигов на каждый из сколько их там из 120.

(14) Факт, в При начале работы системы и перед началом работы системы кодом явно вызываются.
В регламентном задании модуль управляемого приложения не компилируется и не запускается

https://yadi.sk/i/kX_deHR8zh5y8A Вот же они.

Проверить просто - воткни запись в ЖР в этих событиях и все вопросы сразу отпадут.

А проверка/защита лицензионности и поиск ключей не может быть долгим?

(14) Откуда инфа про 4 гига? Даже при многопользовательской работе ЕРП не жрет более 4 гигов на старте, плавно разрастаясь до 8-10 через пару десятков минут работы пользователей. А в топике конфы раза в два меньше чем ЕРП.

(19) Одна база.
А у ТС их 120, в каждой конфа в память грузится блин и требует свои 4 гига на старте, дальше спокойно юзеров пускает.

Вряд ли сервер 1С такой вумный что идентичные конфы грузит только один раз и совместно использует.

Как думаем почему по фреше 1С разных клиентов в одной базе реальной держит со своей доработкой с префиксами и http://v8.1c.ru/overview/Term_000000788.htm
Думаю и конфа там одна на всех.

Короче пусть ТС сливает базы и не страдает.

Или лучше купит фреш и внедрит, если это чужие базы а он просто сервер сдает в ними сторонним клиентам.
https://habr.com/ru/company/knopka/blog/324662/

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

(20) "120, в каждой конфа в память грузится блин и требует свои 4 гига на старте" // Ничо там не требуется в таких объемах. Это ты где-то такое наблюдал?

(24) Плиз пруф можно про разные базы для каждого клиента?
В ссылке (23) написано что база одна.

(25) Попробуй одновременно 10 файловых баз локально запустить и засечь время.
А затем их же но по очереди.

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

(26) "Количество областей в одной базе это компромисс, который обусловлен многими факторами, оно может быть очень разным, мы для себя выбрали 200. Сам кластер должен состоять из менеджера сервиса, агента сервиса и нод (серверы БД, серверы приложений, web-сервис), когда количество областей становится более двухсот, разворачивается следующая нода"

(27) Какие файловые, какая нагрузка на систему? Я про 4 гига спросил, речь-то вроде о сервере 1С и потреблении памяти оным. Ты вроде писал про какие-то 4 гига, мне и интересно, откуда там столько.

(29) Это из рекомендаций для файловой базы локальной в 8 гигов (УФ) и вычел рекомендацию 4 гига для клиента если база серверная.
Итого 4 гига на базу на сервере, даже если всего один сеанс, но при увеличении кол-ва сеансов для одной базы нет такого дикого роста.

Конечно думаю все не так просто в реальности и еще много чего не учитываю.

(29) Я же написал что это просто аналогия.
Ну возьми два компа (или виртуалку) разверни сервер 1С и попробуй смоделировать ситуацию ТС, следя сколько используется оперативки.

Просто я очень сомневаюсь что код "сервера" для файловой и sql-серверной базы сильно очень отличается.
Т.е. оно конечно отличается но думаю все равно в основе файловой некий sql движок и та же трансляция запросов по загруженной в оперативку конфе.
Но сервер использует одну копию загруженной конфы для базы на несколько сеансов.

(30) Так это ты с учетом клиента, ясно

(32) "Но сервер использует одну копию загруженной конфы для базы на несколько сеансов."
Не сервер, а рпхост

Получается выход один разделение данных?

(35) Нет ну конечно есть еще вариант - сделать кластер и вынести регламентные и фоновые на отделенную машину, но поможет ли это - я не знаю.

(35)
Тут видимо можно провести интересную исследовательскую работу.
Попробуй сначала способом из (10)
То есть у тебя в каждой базе всегда должен быть запущен как минимум один фоновый сеанс на сервере.
В таком случае для каждой базы всегда будет загруженный в памяти контекст, что значительно снизит затраты на старт фоновых заданий в случае, когда в базе нет ни одного сеанса.

Реализовать это - раз плюнуть.
Сделай плиз, отпиши сюда. Страсть как интересно.

(7) А можно просто в каждую базу зайти дефолтным юзером ;)

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

Если устраивают реактуальные ппд то пусть они и будут не актуальными. Забить на них и все

(36)
Это даст только то, что забьется под 100% сервер с регламентными заданиями. Ну если конечно он не на 120 ядер)

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

(42) 1. Аппаратный ключ позволяет с 1 компа запустить все 120 баз на 1 лицензии ;)
2. Пинг не ICMP, а от клиента к кластеру.