Расчет ресурсов для терминального сервера : Супермаг Плюс (Супермаг 2000)

Не забываем отписываться здесь, а сейчас у меня другой вопрос, кто и как расчитывает количество памяти и ядер для терминальника под Супермаг? У меня пока получается, что рекомендуемое - 2Гб на пользователя и 1 ядро на троих. Так? Т.е. 10 пользователей - это 25Гб и 4 ядра (системе еще). 100 пользователей - 250/40.
Да, поскольку винда убогая не может делить память, то терминальников должно быть максимально много, т.е. дробиться должны, чтобы юзер, выжирающий память, валил минимальное количество других юзеров. Возможно, что это надо решать виртуалкой.

Что-то многовато.

У меня сейчас от 5 до 10 одновременно пользуются терминалкой, Sm.Main.exe занимает 80-150 Мб памяти. Они еще и 1С запускают частенько, та от 200 до гига доходит.

На сервере 12 ГБ оперативки, свободно 3-7. На нем СГО УКМ еще половину отъедает.

Картинка на 08:30 утра.

Миниатюры

 

У меня процесс занимает от 80 до 200 мб примерно на пользователя, в зависимости от выполняемых функций. Сама винда под системные нужды отбирает порядка 15МБ. На двух ядерном процессоре и 2ГБ памяти спокойно работают 10 пользователей без тормозов. На всякий случай, не Супермаг, функционал достаточно большой (300 таблиц, 1000+ диалоговых окон и т.п.).

Многое зависит от приложения. В частности, если приложение состоит из небольшого exe и набора dll, то dll загружаются в память один раз для всех пользователей. Если используется sql, то он должен быть на выделенном сервере. Если прямая работа с базой данных, то лучше наоборот. Конечно, будет сильно влиять еще размер базы данных. Если обращения к базе не помещаются в оперативной памяти, то использование sata дало хороший результат для actian zen.

Еще Руссинович, кажется, призывал не пользоваться таскменеджером, особенно в терминалке... Врет он... Лучше какой-нибудь perfmon запускать, смотреть за свопами и побольше датчиков натыкать, чтобы понять, плохо ли системе на самом деле или нет. Конкретный пример, может, просто он именно течет памятью, но перерасчет остатков в инвентаризации в 20 Супермагов терминалку повалил. Точное значение памяти и что там в тот момент было не знаю, это не мое дело, но десятки гигабайт. Просто, как факт...
Да никогда она столько не отбирала... Один терминальный сервер только сожрет втрое больше минимум.
Без обид, но это вообще не сервер и 10 пользователей, видимо, не знают, что такое "без тормозов". Или винда какая-то старая, вроде 2003.

Я смотрел, когда реально плохо было. 10+ пользователей, у всех СуперМаг, у нескольких 1С до 1 Гб (по данным диспетчера). Вот тогда в своп ушел. Это было пару раз в год.

В остальном, повторяю 12 Гб общая память, половина занята под УКМ, остается 6 гиг на 10-20 пользователей. Хватает. Серваку лет 8 не меньше, винда 2003 сервер.

1. Если пользователей догуя >100, то обязательно разбивать сервера. попытка впихнуть их всех в один сервер приведет к полной гуйне.
Лучше купить 10 дешевых чем один дорогущий.

2. лицензии пер девайс или перюзер будут стоит +\- одинаково что на один сервак с охулярдом пользователей что на 10 по 10 пользователей.

3. увеличивается маштабируемость.

4. увеличивается отказоустойчивость.

5. Ухудшается управляемость но с учетом того что все это как правило вгонятся в домен... пох...

ну и esxi наше все...

Да, сервак там 2003. И на нужды терминального сеанса там отбиралось именно 15 мб. Это известная цифра и неоднократно публиковалась. По более поздним версиям сервера не смотрел. Вполне возможно, что выросло, общая тенденция такая. На 2008 сервере работа 20 пользователей нареканий не вызывала, но там и ядер, и памяти побольше было, меньше просто уже не ставят.

Без тормозов, это когда кликнул и через несколько секунд получил отчет. А на вводе мгновенно. Разумеется, все зависит еще от режима работы. Особенно, когда запросы к базе не помещаются в кэше в оперативной памяти, надо принимать меры. У нас движек базы на том же сервере (не sql).

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