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

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

Все файловые что-ли?

(2) из поста видно, что они на SQL крутятся.

(3) но пока никто не знает что за СУБД

(1) Базы хранятся на сасовском 10 рейде.
(4) MSSQL 2008 TempDB + темп пользователя службы вынесены на рамдиск
Доступ из терминальника, сервера на гигабите.

(5) а зачем доступ из терминальника?

Изменить расписание фоновых заданий. Через консоль заданий часть поотключать (при чем тут конфигуратор?). Часть - сделать раз в час (день), а не каждый 60 секунд (например, полнотекстовый индекс).
Настроить ночной авторестарт сервера предприятия с удалением cntx файлов.
Слияние баз - это скорее организационный процесс, нежели IT. Стоит это кучу денег и бешеные риски. Зачем оно тебе?
ПЫСЫ: На сервере 150 баз 1С, около 700 онлайн сеансов пользователей. Ничего не виснет.

у меня 10 баз по умолчанию сетевой трафик в 2 МБ/с генерировали.
Настрой нормально задания

(7) Опередил :)

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

(7) Слияние баз буду делать я. Все конфигурации одинаковые, то есть при помощи конвертации данных это довольно таки быстрый процесс (есть опыт).
(9) Работает все время одинаково.

Спасибо, попробую перенастроить.

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

Конвертация - это 10-15% от всего объема выполненных работ при слиянии.

(11) Ничего из выше перечисленного не используется. Управленческого учета нет.
Контрагентов и номенклатуру сливать буду, подготавливать к слиянию не я :)

(12) наше дело предупредить, а выбор за тобой)

(0) у нас ситуация похожая с ИБ. работает и работает.

(7) "с удалением cntx файлов" - а что это дает?

(14) Это сведения о соединениях. Сохранение файлов позволяет безнаказанно рестартовать сервер - при таком сценарии клиент вообще не замечает, что сервер рестартован.
Убиение cntx полностью сбрасывает все сеансы. Нам помогало при непропорциональном росте нагрузки на сервер (уже при 200 соединениях менеджер кластера съедал 1-2 проца) и при подвисании неубиваемых фоновых заданий.

(0) Предлагаю порезать сервер приложений на несколько кластеров: http://i46.fastpic.ru/big/2013/0527/19/4bc253935f69b4a7305175286405d919.png
и распределить базы так, чтобы равномерно загрузить все кластеры. Не нужно переводить базы в файловый режим.

(15) а рестарт сервера 1С, не убивает полностью все сеансы?

(16) Каждый кластер - отдельный сервер?

заняться оптимизацией

(17) Если конфы на УФ, то нет

(20) неожиданно :) думал, что все убивается.

(20) у нас и на обычном приложении не убивает сеансы, хотя на 8.1 всех замечательно выгоняло

(15) спасибо за информацию

(12) >> Контрагентов и номенклатуру...

Это самая простая часть задачи.

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

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

(18) Нет конечно. Все в пределах одного сервера приложений, я же написал.

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

О каком доступе из терминальника идёт речь в (5)?
У вас там часом терминальный сервер развернут не на одном физическом сервере вместе с СУБД и 1С?

(12)"Контрагентов и номенклатуру сливать буду, подготавливать к слиянию не я :)"
"Наивный чукотский юноша" (с) не помню кто.
Вопрос в случае проблем, а проблемы при таком подходе будут - 2000%, даже адекватным куроводством будет поставлен примерно так:
1) Кто рекомендовал слияние БД вопреки тому, что бухи говорили о потенциальных проблемах? Ляпкин-Тяпкин?
2) Кто производил процесс собственно слияния БД? Ляпкин-Тяпкин?
3) Кто не продумал процесс выявления ошибок тех, кто готовил БД к слиянию? Ляпкин-Тяпкин?
"А подать сюда Ляпкина-Тяпкина!!!"
Ну, уж если ты желаешь получить опыт лично сам, то никто из нас тебе помешать не сможет. Получай.
Более того, ты "вспашешь ниву" для кого-то из профессионалов и хорошо обоснуешь его ценник на восстановление после твоих действий :)
Меня терзают смутные сомненья - а бэкапы у вас в фирме делаются? :)

(0) если бухгалтерия говорит, что им будет неудобна единая база, то какого рожна ты им это впариваешь ?

Я добавлю к коллегам свои 5 копеек: слияние +100500 баз в одну, на практике, решаются через какую-то вспомогательную базу НСИ, в которой методично прорабатываются все вопросы синхронизации, и вся инфа вводится только в нее, а из оной по обменам НСИ разливается по всем остальным получателям. Аналогично в другую сторону - в консолидацию, или куда-то в консолидированную базу: сначала ручейки сливаются в одну воронку, там находятся четкие сопоставления, а только потом, один фильтрованный поток заливает консолидирующую базу. Такие консолидаторы НСИ давно продаются. А попытки слепить в одной базе все, кроме как гемора ничего обычно не дают.

Если в дальнейшем не придется строить отчеты между Компаниями , то

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

(26) Да, на одном хосте (Hyper-V).
(27) Учись читать, умник.
(30) Не придется.

(32) Ты Админ что ли? Это они виртуалки любят. Обычные 1с-ники знают что 1С не любит виртуальное железо. К тому же сдается мне что тупо всё упирается в очередь диска

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

+(34) Только сразу ограничить пользователей запуском _только_ 1С + максимум Офис, а то могут сторонним софтом чупакабру устроить.

+(35) Или вообще через RemoteApp опубликовать. Оно и по ресурсам менее накладно.

(34) Если сервер "достаточно мощный", то смысл в прокладке, которая отъедает часть ресурса сервера. К тому же какой бы "достаточно мощный" сервер не был, что делать с дисковой подсистемой?

(37) Я среди вводных упомянул отдельное скоростное хранилище для данных, ОС можно на отдельном SSD для пущей радости развернуть. А терминальные пользователи по большому счету жрут только оперативную память (которая стоит рубль за пучок), вычислительных же мощностей одной головы Xeon E5 4650 хватит за глаза на полста юзеров, как показывает практика. Главное, правильно распихать приоритеты и affinity по процессам.

(37) А о какой прокладке речь идет? Терминальный сервер - это ж не только "прокладка".

(39) о виртуалке (Hyper-V)

(40) Аа, это да, согласен, оно нафиг не надо.

(33) Я не админ, но в курсе дела :) Производительность виртуалки хромает по дискам, это да. Но в виртуалках много преимуществ и здесь я не могу спорить с админами + оперативность восстановления.

Для примера: на SQL висит центральная база фронтов, сделал тестовый запрос к таблице продаж (1 млн. записей) две группировки не по индексу и три суммы с условием (результат 2000 строк) по времени 12 секунд...

Параметры хоста:
Supermicro
Intel Xeon E5 2620 2.0 GHz 2 проца (2 по 6 ядер 24 банки)
32 Gb RAM
Модель дисков сейчас не могу посмотреть, он показывает собранный рейд. Загрузка проца как и должно максимум 10%.
За пять минут просмотра монитора ресурсов максимальный скачек обращения к диску 10 Мбит/сек.

(42)  Причём тут скачёк. и один запрос? Нужно как минимум очередь к диску смотреть

(42) Так и должно быть - сейчас вся база скеширована в память, запрос на чтение отработает очень быстро. А вот на запись...

(44) Запрос был первый. Кешированный 2 секунды.
Сейчас попробую скопировать всю таблицу в тестовую базу.

34 секунды. Запись длилась около десяти секунд.
Второй раз такой же инсерт в базу на рамдиске - 5 секунд.
Удаление строк из тестовой базы на диске 42 секунды.
Повторная вставка строк в тестовую базу на диске 5 секунд наверное просто скопировал блок из TempDB.

(46) Ну тады расписание фоновых задач ковырять. Возможно, тормоза из-за блокировок уже.

После отключения проверки электронных сообщений и переключения обновления полнотекстового индекса со 150 сек на 7200 сек результат: без перезапуска службы предприятия толстые клиенты стартуют в раз 5 быстрей...
Особенно удивил список регламентных заданий документооборота.

ПЫСЫ
Кто-нибудь переносил логи SQL баз на рамдиск или лучше для этого выделить быстрый диск или вообще ssd с учетом один на год?

(48) Я так понимаю, ты все же нашел волшебную консоль заданий и решил отрегулировать рег задания? Первоначальный вопрос более не актуален?

(49) Да на диске с ИТС. Вроде как отпустило, спасибо :) 40 баз оказывается... На ночь сделаю рестарт службы предприятия с удалением snccntx*.dat.