Всем привет. Как улучшить работу 1С, когда много файловых баз 1С и к каждой подключаются 1-2 пользователя.
Что имеем:
1) 40 шт. файловых баз 1С (Зарплата и кадры государственного учреждения ред. 3)
2) 40 шт. файловых баз 1С (Бухгалтерия государственного учреждения ред. 2)
3) Все базы 1С лежат на сервере просто, и к ним открыт доступ по "шаре"
4) Клиенты подключаются через Толстого клиента 1С к шаре.
5) Сеть 1 Гбит.
------------------------
Серверная машина:
Intel Xeon E2236 (6 ядер / 12 потоков)
DDR4 - 90 Gb
Raid 1 - SSD
------------------------
Судя по ответам в интернете, ставить SQL нет смысла, т.к. к одной базе подключается всего 1-2 пользователя.
Ставить веб сервер если, то 40 пользователей столкнется с однопоточностью 1С.

Обьединить все в одну базу БГУ и одну ЗиКГУ. Перейти на клиент-сервер

что Вы имеете - понятно.
А смысла поста - нет. Вас в школе и воспитатели не научили вопросы задавать ?

(2) Как улучшить работу пользователям, чтоб быстрее работала 1С.

имхо, при обращении к разным базам будут разные потоки. Но если не прав, то не судите строго.

А вообще, при таком способе работы с данными, нужен терминальный комп, а лучше сервер. И пусть юзеры цепляются все к нему. тогда и тормозов не будет, если серваку оперативы поставить например 32 гиг.

Но никто там для БГУ и ЗиКГУ лицензии на терминал не купит.

но вижу в топике, кто 90 гб оперативы уже есть на нем.

(2) терминал , RemoteApp , 10-100gb, если тонкий клиент - веб-сервер.

(0) Есть у меня такой знакомый, с аналогичным случаем.
У него терминалка на Linux, с NX4 клиент/сервером (из-за печати), т.к. XRDP проброс принтера не умеет.
Да я и сам такое использую, правда в значительно меньших масштабах.
А по "шаре" это все слишком медленно работает...
Ну да, Linux, но "волков бояться - в лес не ходить", но ничего там особенно сложного сейчас нет, гайдов просто завались, особенно про юбунту.

(0) >> ставить SQL нет смысла, т.к. к одной базе подключается всего 1-2 пользователя.

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

Если все конфигурации одинаковых версий и на управляемых формах, то можно вообще развернуть у себя облачную подсистему Фреш.
https://its.1c.ru/db/freshpub#content:2:hdoc .
Будет две базы. 1 - ЗикГУ, 2 - БГУ. Прям ка на картинке (только там БП и УНФ) https://its.1c.ru/db/freshpub#content:10:hdoc .

Но, ИМХО, даже в обычном клиент-серверном варианте (где все 80 баз будут отдельными, а не слиты в две единые базы ЗиКГУ и БГУ), работать должно быстрее чем текущий файловый вариант с сотней подключений.

(0) переходить на клиент-сервер

(9) Файловый клиент-сервер разве улучшит ситуёвину?

(0)
если
"4) Клиенты подключаются через Толстого клиента 1С к шаре."
То характеристики сервера в твоем случае вообще практически не при делах. Поскольку тупо не используются (ну, за исключением дисковой подсистемы). Мог бы и не озвучивать. У тебя Каждая база обрабатывается своим клиентом на своем компе, со своим быстродействием. Сервер у тебя используется только в качестве файлопомойки. В твоем случае любое телодвижение будет улучшением. :)))


PS: а так то да, для терминалки твой сервер самый раз.

(0) Как уже сказали, либо клиент-сервер, либо RDP/RemoteApp.
С учетом наличия памяти и SSD я все же склоняюсь к RDP.

А сколько всего пользователей работают во всех базах? Они их откывают по нескольку одновременно или по очереди?

(8) Они наступят на обычные грабли сетевой шары на виндусовой самбе.

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

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

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

(13) Я тоже много раз слышал байку про "тайминги", но пруфов пока не видел. Может, у тебя есть?

(13) может поможет только если к каждой базе (к каждой мелкой шаре) будет цепляться по 1 юзеру. А если к мелкой шаре подцепится второй, то все так и будет точно как ты рассказал для общей шары.
Но смысла все равно нет.
ибо вангую 40 клиентов на celeronах 15-ти летней давности :))) Смысла даже в самой распрекрасной  файлопомойке для них нету никакого.

автору в принципе надо уходить от работы с базой на клиенте.
А объединение баз в одну влечет за собой переход на БГУ КОРП и ЗИКГУ КОРП. (иначе он не получит требуемого функционала, кроме как в КОРП)

нужно просто посчитать, что ему выгоднее - приобрести обе версии КОРП, сервер 1С, (и стоимость SQL) или - стоимость терминальных лицензий?

(15) согласен.

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

(14) это обсасывалось еще ммм... дай бог памяти..  pit'ом (ака у лю 427) еще на территории 1С еще для 7.7 еще четверть века назад.
тогда же было признано, что лучшей файлопомойкой всех времен и народов была (да теперь уже наверно и останется) Nowell NetWare.

(17) Четверть века назад это в Windows 95, получается?

И с тех пор программисты Microsoft хранят эти тайминги как зеницу ока и бережно переносят из версии в версию.
2022 год на дворе, по RDP летают видео и игры, по SMB3 можно даже скульную базу подцепить, а тайминги все те же.

Стабильность, ё...

(18) увы, это история еще раньше началась.
Там корни протокола еще в ламповом юникс были установлены.
Если память не подводит, то упоминался 1987 год.

еще тогда при первом появлении винды, начались крики "винда маст дай", потому что винда сперла все идеи у юникса :-)

(18) не-не-не.  ты не путай. семейства Windows 9x и Windows NT - это РАЗНЫЕ семейства Windows :)

и да, первая коммерческая версия NT вышла еще в 1993 году. так что насчет стабильности ты прав :)))

(11)
Да. Сервер вообще не загружен. Железо простаивает.
Клиенты имеют у себя компьютеры нормальные, в основном это пентиумы/i3, ssd, 8 gb/ win 10
Без дополнительных вложений нет решений?) публикация на веб тоже все загнётся?)

(4)
А точно будут разные потоки? Говорят библиотека 1С не многопоточная)

Ну а если поднять на серваке 40-80 автономных веб-серверов, разнести их по портам и пусть пользователи стучатся? С подключениями надо будет попыхтеть... Хотя может брежу после короны - ети её

(22) >Сервер вообще не загружен.

проц случаем не на ~18% загружен?
в файловой базе в расшаренной папке 6-ти ядерный проц больше 16.6 % под 1С и может утилизировать

(25) 1C на клиентах, на сервере только винда.

(25) Чем? Чем даже теоретически может быть загружен проц на файлопомойке? Считать данные с диска и отдать их в сетевую карточку и обратно?

О какой 1С на сервере применительно к расшаренной папке ты говоришь? Если на этом, с позволения сказать, сервере, 1С даже не установлена?
Расшаренная папка с "сервера" светит в сеть, в лучшем случае на клиенте монтируется, как типа диск S, в худшем просто идет обращение по сетевому пути типа "\\server1c\1CBase\Stateaccounting", какие 16.6% на сервере под 1С, ты о чем?

(24) а зачем 80 вэбсерверов?

(0) Ну тут уже сказали (по трудоемкости от меньшего к большему):
1) Терминал
2) Кучу веб серверов по портам + возможно отдельным платформам (ну или возможно как то по потокам разделить)
3) Скуль с вебом.

я бы сделал терминал (ну или удалённою публикацию)

(22) (23) Насчет многопоточности - ты путаешь "много баз" и "много пользователей на одну базу".
Если хочешь ставить web-сервер, то для файлового варианта, как у тебя, действительно, к одной базе web-сервер выстраивает очередь пользователей,и еслим пользователей к базе много, то да, притормаживает,  но у тебя всего-то 1-2 пользователя на каждую базу, так что е тебе бояться "отсутствия многопоточности" :) ?

А вот "много баз" в том же IIS решается элементарно, добавлением пула приложений. В идеале, на каждую базу - свой пул приложений. Тогда для каждой базы  базы будет создан свой собственный процесс w3wp, а уж для него обслужить 1-2 пользователя - тьфу.
так что тебе web-сервер IIS один-единственный, но в нем много пулов приложений.


ps: а вот насчет апача ничего  не скажу - но тут советуют 80 вэбсерверов:)))) афигеть. :)

ну и эта..
80 баз..
чисто по-дружески советую - 1С Обновлятор у Милькина прикупи :) не пожалеешь.

(0) Мини сервер 1С  вполне помог бы. Затраты минимальные. Остальное-плюсы

(15)
>А объединение баз в одну влечет за собой переход на БГУ КОРП и ЗИКГУ КОРП. (иначе он не получит требуемого функционала, кроме как в КОРП)
Не проще создать 2 базы (если конфигурации едины): БГУ и ЗиКГУ с разделением по областям данных и повесить все на сервер 1С? КОРП не нужна, должно быть быстрее. Бардак внутри каждой области свой.

(32) сервер МИНИ только до 5-ти одновременных сеансов во всех базах,
что-то сомневаюсь, что при 80-ти базах ТС этого хватит

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

(34) Сомневаться можно до тех пор, пока ТС не озвучит реальное количество лицензий, которые у него есть и количество пользователей.А также как он подключается в реале через "шару".

Ну и,кто тут про сеть рассуждает - mtu не сильно поменялся за время перехода с 10 мегабит на 20 гигабит,как ни странно.

(37) а разве тут есть кто-то. кто рассуждает про сеть?

(36) реальное количество лицензий чего? 1с или CAL , без которых работа с таким числом пользователей в локальной сети тоже нарушает лиц-соглашения Win ?

(29)
>я бы сделал терминал (ну или удалённою публикацию)
Терминал в топку, сношаться с проброской принтеров (которые не заточены под rdp с подменой драйверов от старших аналогов) и кассового оборудования то еще удовольствие.

(40) +ТСД для инвентаризации ОС/МЗ, да в принципе все оборудование

(39) Я пока только про 1С...Лучше потряси ТС о подробностях )

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

(35) >для диска,который расшарен,выключается кеширование как только подключается первый пользователь

Еще одна городская легенда. Пруфы будут?

>на клменте файл перестает кешироваться как только к нему обратится второй пользователь

И еще. Тему можно переименовать в "Легенды и мифы древней Windows".
При совместном доступе кэширование работает немного по-другому, но не отключается.

кэширование, шары, лицензии на windows, CAL и т.д. - это хорошо, но уходит от  сути вопроса. Так можно до бесконечности телепатировать - а лицензионный ли у него офис, а антивирус, а домен у него или не домен.. etc.

человек по-русски сказал в (22) - без дополнительных вложений.
Без дополнительных вложений - ему на таком железе одного IIS хватит за глаза.
Все остальное - от лукавого.


(0) ">> Ставить веб сервер если, то 40 пользователей столкнется с однопоточностью 1С."
Забей, по твоим же словам, у тебя такого НЕТ - 40 пользователей в одной базе.

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

(0)посмотри в сторону fresh

(46) кстати, тоже вариант,
у меня централизованная бухгалтерия с несколькими десятками баз в рамках подписки ИТС ЦГУ переехала во фреш - и они довольны и на ЛК количество звонков в несколько раз сократилось

так... некоторые пользователи начинают тут попытки срача, как я посмотрю.

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