Имя: Пароль:
1C
1С v8
Распределение ресурсов между пользователями на сервере 1С
, , ,
0 Иванов Иван Иваныч
 
09.12.21
14:42
Подскажите кто шарит, думаю распределить ресурсы сервака между пользователями (например, сумма ресурсов делится на 4 пользователя в равных долях), т.к. при захвате большого кол-ва ресурсов одним пользователем 1С начинает отлетать у других юзеров. Или лучше сделать ограничение потребляемых ресурсов одним пользователем (например, юзеру нельзя занимать более 50% ресурсов сервера)? Хотелось бы услышать советы бывалых как будет лучше поступить. И самое главное как это сделать?)
Заранее спасибо.
1 H A D G E H O G s
 
09.12.21
14:44
Потребляемые ресурсы сервера - это хлебушек из мозгов админов.
Что конкретно вешать в граммах?
2 acht
 
09.12.21
14:45
(0) Ну, то есть вопроса "можно ли это сделать" не стоит?
4 Иванов Иван Иваныч
 
09.12.21
14:51
(2) правильно сказать: есть желание, а понимания как сделать нету
5 Иванов Иван Иваныч
 
09.12.21
14:52
(3) спасибо не нужно)
9 Иванов Иван Иваныч
 
09.12.21
14:54
(6) ну и техподдержка по совместительству)
просто надоели юзеры у которых частенько отлетают сеансы из-за скульника
10 Пулья в зубах
 
09.12.21
14:55
(9) ага, а скульник-то при чем здесь?
12 mistеr
 
09.12.21
15:04
(0) Нужно разобраться настроить/доработать систему так, чтобы ничего не "отлетало".

Мы еще не достигли сингулярности, когда можно нажимать на кнопку "Сделать за...ь", а мозги не включать.
13 Мультук
 
гуру
09.12.21
15:21
(0)

Ответ - никак.
Можно только надавать по руками и запретить делать "это".
Но сначала нужно выяснить что за "это" он делает.

P.S.

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

Спрашиваю не для себя, друг попросил спросить здесь.
14 fisher
 
09.12.21
15:37
(0) Ты бы сначала диагноз нормально поставил, а не сразу кричал "дайте мне самый мощный антибиотик от всех болячек". Нету такого.
15 Иванов Иван Иваныч
 
10.12.21
07:07
(14) суть в следующем, при выполнении громоздких операций (например, формирование ебейшего отчета, с огромной выборкой) у части пользователей слетают сеансы по причине блокировки транзакций у скульника, у остальных начинает виснуть 1С
ну и мозг то парят мне, а не хотелось бы
16 Ёпрст
 
10.12.21
07:10
(15) отчет ником боком не может установить никакие блокировки.
17 Иванов Иван Иваныч
 
10.12.21
07:10
(14) никто и не кричит, я спрашиваю совета, куда копать и как будет лучше
18 Обработка
 
10.12.21
07:11
(0) Не в ту сторону копаешь.
Всегда искали как вообще бороться с тормозами а не распределять нагрузку между юзерами.
Ни разу такой задачи не слышал. Обычно админы юзерам могут только квоту дать по памяти и все.
Все остальное решает кластера итп.
19 Иванов Иван Иваныч
 
10.12.21
07:12
(16) возможно и может, суммарное кол-во пользователей ~500 чел, отследить кто и чем конкретно повесил сервак физически практически невозможно
также бывает, когда пачку док-тов с большим кол-вом номенклатуры проводят, также вешается всё
20 Ёпрст
 
10.12.21
07:15
(19) 4 уже в 500 превратилось?
>>>Отследить кто и чем...невозможно
Че правда? Прям никак?)))
21 Обработка
 
10.12.21
07:15
Прежде чем распрашивать хоть обрисовал бы свою инфраструктуру.
Сервер. Характеристики. БАзы. Объем базы. Юзеры. ИТп
22 Обработка
 
10.12.21
07:16
(20) Он сказал "к примеру".
Хотя мог бы сказать хотя бы "к примеру 400" )))
23 kauksi
 
10.12.21
07:20
Поставь nvme диск на сервер, раздай достаточно ядер, памяти, и тогда вопросов возникать не будет. Даже 50 юзеров даже на десктопном 6-8ми ядерном проце вполне уживутся.
ну и вот это прочитай http://www.gilev.ru/dfss/
24 Иванов Иван Иваныч
 
10.12.21
07:21
(20) 4 я для примера привел, чтобы понятно объяснить о своих мыслях на этот счет. Что касаемо отслеживания, то даже через журнал это проблемно, т.к. доки фигачат как вне себя
оптимизировать конфу нереально, слишком много изменений
сервак: ксеон 5218R, 128 озу, ~500 пользователей (возможно немного больше), базы по объему не могу сказать, но в архиве, гигов на 11 тянут, суммарно баз 30 шт, активно используется 3 шт, основной нагруз на них
25 kauksi
 
10.12.21
07:21
и вот это https://infostart.ru/1c/articles/349049/
Для решения задачи используем WSRM - Windows System Resource Manager
26 Иванов Иван Иваныч
 
10.12.21
07:23
(21) ах да, ~25 пользователей подрубаются через клиент 1С-ки, остальные по РДП подключаются
27 Иванов Иван Иваныч
 
10.12.21
07:23
(25) сейчас ознакомлюсь
28 Ёпрст
 
10.12.21
07:29
(24) все базы, 30 шт,  11 гигов в архиве..у вас 7.7 ?
29 Ёпрст
 
10.12.21
07:35
(24) через какой журнал вы собирались отслеживать? Регистрации что ли?
))
30 Обработка
 
10.12.21
07:38
+ 1 (28) надо клещами вытаскивать у автора.  (0) Что за базы?
31 Иванов Иван Иваныч
 
10.12.21
07:45
(30) 30 8.2, 1 8.3
по размерам каждую не могу сказать точно, у админа спрошу
32 Иванов Иван Иваныч
 
10.12.21
07:46
(29) вообще думал да, судя по саркастичному комментарию, есть и другие методы, о которых я не знаю)
33 Обработка
 
10.12.21
08:10
(31) "30 8.2, 1 8.3" Что это такое? Обычно так пишут на 1сники...
Можешь по человечески писать?
Пример:
БП3 30 человек УТ 11 50 человек база примерно 150 ГБ или 250ГБ
34 Мультук
 
гуру
10.12.21
08:11
(32)

Методов ровно два
1) Учиться
https://xn----1-bedvffifm4g.xn--p1ai/1c-v8/optimization/
http://www.gilev.ru/

2) Сменить работу

Главное, перестать верить в то, что на форуме тебе скажут:
- ну тут все просто. Нажми на синюю кнопку, вторую слева и все будет хорошо.
35 SunFox
 
10.12.21
08:22
Зоопарк из баз, что тормозит не понятно, но ресурсы хочет распределять по 1С, сервер оказывается ещё и rdp, что на нём пользователи запускают кроме 1с не известно, сервер этот может быть и ad с файловыми базами и вообще не известно с что и с чем, а ещё может и вертуалка ... Что тут можно сказать по делу? - ни чего.
36 fisher
 
10.12.21
10:16
(15) Начни с мониторинга производительности дисковой подсистемы. Похоже на то, что она проседает. Если таки да - смотри, какой процесс ее топит. Если таки скуль, то в скуле можно настроить отбой "ебейшего отчета", только вряд ли это решение устроит бизнес. Тут думать придется. Если дело в одном отчете - так проще всего отчет переписать и данные под него оптимизировать. Если в куче отчетов с которыми система не справляется и отчеты в принципе норм - значит достигли предела масштабируемости и нужны инфраструктурные изменения. Либо сервак прокачивать (может решит памяти досыпать или темпы в оперативку вынести), либо реплику для отчетов поднимать в другом месте.
37 fisher
 
10.12.21
10:18
Сеанс-виновник (если дело в скуле) можешь попробовать выцепить в консоли сервера 1С, отсортировав по времени текущего обращения к БД.
38 fisher
 
10.12.21
10:35
Еще очень плохо держать сервер приложений 1С в одном дисковом пространстве с сиквелом. Это значительно ухудшает масштабируемость. Оба могут создавать значительную дисковую нагрузку на тяжелых отчетах, а сервер приложений 1С еще и очень плохо переживает дисковую деградацию, вплоть до stop the world.
Программист всегда исправляет последнюю ошибку.