Официально HP рекомендует 70 пользователей на один APP. Можно еще один сервис поднять на APP, но тогда приодеться сломать таблицу сервера, (уникальность сервера убрать нужно будет.). Тогда встанет второй вопрос, Как себя начнут вести шедулы.. имя же одно будет.
Пользователь
Поиск по сайту
Реклама
Опрос
Погода
Замедление работы системы.
| |||||||||||||||||||||
|
|
Замедление работы системы.
|
31.01.2012 15:58:12
|
|
|
|
|
|
17.02.2012 15:59:27
Коллеги, подскажите пожалуйста в каком документе упоминаются официальные рекомендации. Бегло просмотрел sd45_AG,sd45_IG, sd45_SP_20_ADD - не нашел. |
|||
|
|
|
|
17.02.2012 16:24:35
Нашел но там фигурирует значение 50.
Installation_Guide стр. 69 By itself, the JVM used by the Service Desk application server is not optimized for running large applications. Consequently, some adjustments are needed when running more than approximately 50 users on a single application server. |
|
|
|
|
|
17.02.2012 16:36:29
Григорий, спасибо.
Но это не совсем то, т.к. На стр. 69 Installation_Guide речь идет о необходимости настройки параметров памяти JVM. Интересует именно рекомендация по установке дополнительного APP-сервера (выделение дополнительных мощностей нужно как-то обосновать. Аргумент "тормозит" не подходит.) |
|
|
|
|
|
17.02.2012 16:51:12
да уж, "тормозит" - это диагноз, а доп сервер - это таблетка.
|
|
|
|
|
|
17.02.2012 17:08:47
В общем, это тоже является поводом для увеличения серверов. На самом деле где-то мы обсуждали этот вопрос.
Кто-то поступает иначе, поднимает на одном APP сервере еще один, но при этом придется сломать одну табличку, чтобы сервесы запустились. Кстати, а в чем заключается торможение? Можно привести статистику нагрузки на APP на SQL, На диски, и т.д. Причиной торможения не обязательно будет APP сервер. Вот, например, простой пример, когда пора добавлять сервер: Запустили групповою правку на изменения поле статус, а в системе есть DB правило которое следит за этим полем и делает какие-то действия. По факту поле изменилось, а правило не отработало. При этом, нужно учитывать сколько было подключено пользователей к данному app серверу. В общем, чем чаше повисают службы в момент явной (высокой) нагрузки тем больше вероятность дать больному пилюлю. 
Но также нужно и учитывать нагрузку на базу. Если нагрузка большая, и системе дать еще одну кобылку, то тут встанет вопрос, а почему нагрузка на базу большая? Так что, для начала советую взглянуть на производительность. |
|
|
|
|
|
18.02.2012 16:50:14
Клиент СД зависает намертво при использовании вида "События на группу table" (сущность События сегодня (Service Today). Отображаются все элементы SC,INC,CHG,PRB,WO назначенные на рабочую группу сотрудника. Условие: Назначение;Статус назначения (Assigment;Assigment status) <> 'Готов' ). В момент зависания к одному единственному APP серверу было подключено 160 клиентов. Поднятие второго APP-сервера значительно улучшило ситуацию (зависать клиенты стали значительно реже), но не решило ее окончательно. На даном форуме прочитал рекомендацию в 50 клиентских соединений на сервер, поэтому и хотел получить ссылку на официальный документ. СУБД - Oracle 9.2, Service Pages, Ovportal практически не используются.
Дополнительный сервис для меня будет поднять сложнее, т.к. он будет использовать не стандартный TCP-порт (30999),а межсетевые экраны между нашими площадками разрешают для СД только этот порт. Да и APP-сервер имеет 3 ГБ ОЗУ. Вообще думаю решение проблемы лежит в том числе и в оптимизации таблиц СУБД - скорее придется создавать дополнительные индексы. |
|
|
|
|
|
18.02.2012 21:58:09
50 было, но это всё же некоторое время назад, по этому 70 норма , т.к. хард поднялся с тех времён.
Так вот чтоб найти "узкое место" в твоей системе надо назначить несколько мониторинговых процессов: первый на бд, второй на оп систему бд, третий на сам СД, четвёртый на оп систему апп сервера. Вот когда будет зависание, тогда и смотри, точнее это называется "замерзание" процесса. Вполне может оказаться, что это совсем иная система подвешивает твой запрос от СД, например система создания отчёта. Но это лишь пример, так что начинай с мониторинга. |
|
|
|
|
|
20.02.2012 14:56:28
|
|
|
|
|
|
20.02.2012 15:02:46
Дмитрий, 20453 - это оооочень много!, нормальный показатель меньше 2к.
Тут явно проблема между Апплик и БД, посмотрите JDBC драйвер, скорее всего он не соответствует версии пака или скул загружен процессами , так что нет времени а обработку запросов от апплик сервера. |
||||
|
|
|
|||
Сегодня были (гостей: 1, пользователей: 0, из них скрытых: 0)