Windows 2008 R2 x64, кто-нибудь запускает ServiceDesk на таком
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
26.10.2012 13:13:40
Цитата
Алексей пишет:
Поставил на тестовом сервере. Работает.
Надо бы стресс-тесты устроить, чтобы избежать косяков.
По идее, теперь процессы в ограничения памяти не будут упираться?
Можно сервисы hp open view с огромными размерами делать?
типа такого: -XX:MaxNewSize=64M -XX:NewSize=64M -Xms200M -Xmx3500M ?
А Java для x64 или всё-таки x86?
Сабформы
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
28.11.2011 12:19:55
Цитата
Василий Каменев пишет:
ну это не значит что нельзя
мона, заведи техническое поле с 2-мя статусами -> show, hide и привяжи доп. формы к ним. Создай рул для FAQ чтоб управлял этими статусами.
Я об этом думал, но рассчитывал, что есть другое решение. Плохо, когда разработчики идут на усложнение жизни администраторам
Сабформы
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
28.11.2011 11:35:00
Цитата
Василий Каменев пишет:
ничего подобного, смысл заключается в том что:
1. определяется поле срабатывания "как всегда".
2. в действие рула добавляется ссылка на "линкер".
3. линкер связывает поле из п.1 с доп. формами.
по идее, начинают с п.3. и что в этом линкере будет описано на то ( в вашем случае на то состояние ) он и будет срабатывать.
По пункту 3, по старой версии правила (которое сейчас не срабатывает и выдаёт ошибку) в generic relation стоит следующая связка:
From Item - Status
To Item - Form
В правиле стоит срабатывание этой связки на изменение флага FAQ (добавляется ещё одно поле при статусах "Работы выполнены" и "Закрыта"). Что именно нужно поменять в правиле или generic relation не совсем понимаю - можно привести пример? P.S. выставить в generic relation зависимость сабформы от флага невозможно.
Изменено:
- 28.11.2011 11:36:30
Конфигурация системы под большое количество пользователей.
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
24.10.2012 12:28:25
Цитата
Григорий Ненашев пишет:
Тут вопрос встанет в производительность БД, и оптимизации запросов, расчет на 1 APP 70 сессий, Объем FTP рассчитать также можно, взять данные за неделю с разбивкой по дням и сделать средне значение + 30% на увеличение. При таких объемах, я бы в системе включил все возможные блокировки, ради уменьшения нагрузки на базу.
Блокировки в самой БД, как понимаю? А не будет ли это вызывать ошибок в клиенте или зависаний?
Конфигурация системы под большое количество пользователей.
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
23.10.2012 16:31:07
Здравствуйте. Давно я у вас не появлялся тут Руководство поставило задачу рассчитать необходимые ресурсы для расширения области применения SD.
Цифры меня несколько ужаснули - планируется, что будет дополнительно 120к заявок в месяц (текущий объём 30к) и около 200 Гб данных ежемесячно на фтп, а также около 1000 клиентских сессий одновременно.
На данный момент у меня в архитектуре 4 физических сервера, на которых подняты 8 серверов приложений (6 для толстого клиента, 2 под web-интерфейс) и 2 сервера БД в кластере (MS SQL 2008). Порядка 300 одновременных сессий (как раз по 50 на каждое приложение).
Собственно, вопрос: если я подниму дополнительно 20 серверов приложений на этих же физических серверах, этого хватит или нужно ещё какие-нибудь манипуляции проводить? Ну и в догонку - возможно ли работа SD (ftp) с несколькими дисковыми массивами?
Изменено:
- 23.10.2012 16:36:23
Проблема с Approval.jsp
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
27.03.2012 09:31:49
А не старовата ли версия томкэта для 37-го пака? Лично у нас на этом паке стоит 6-я версия и ява версии 1.6
Зависание отдельных серверов приложений SD
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
22.02.2012 12:23:43
Цитата
Григорий Ненашев пишет:
Когда у меня была такая проблема, я частично перевел правила с Scheduled Tasks на JOB. Переписал полностью все правила DB на более оптимальные. Удалил 80% правил UL и перевел их на работу через бизнес логику системы.
Одно правило UL заменило % 60 правил на ограничение, в замен, того что было. Также оптимизировал базу для поиска, например если в поисковой форме где номер указывается в промежутке поиск работал, скажем сек 6 теперь 1 сек. Т.е стал работать как я бы искал через расширенную форму поиска с однозначным условием.
Для всех представлений как системных так и пользовательских на кастумные поля добавил индексов. (часто используемые в представлениях) Тогда представление у пользователей грузиться мгновенно,
Зависание app серверов происходит крайне редко. – Что не может не радовать, я их даже не перезапускаю автоматически. По прикладам это 6 серверов для работы с пользователями и 2 для почты.
Мне кажется, что зависание происходят из-за DB правил, простой пример, хотим видеть всех активных специалистов в онлайне по группе: В карточку заносим поле типа персонал, пишем правило на внесение в это поле сотрудника который изменил форму, и DB правилом уже пишем дату изменения в карточку пользователя. Вот теперь если специалист будет групповой правкой в объектах что-то править, то мы вызываем чумовую нагрузку на данное правило… может привести к зависанию сервиса. (проверял, работает).. «Есть свои нюансы».
Спасибо. Давно хотел уже заменить кучу правил интерфейса каким-нибудь одним-двумя стандартными, теперь будет повод
Зависание отдельных серверов приложений SD
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
22.02.2012 10:37:56
Цитата
Григорий Ненашев пишет:
Есть три варианта.
1. Увеличить память на службу
2. Автоматически каждую ночь перезапускать службу
3. Поднять еще один APP сервер
1. Вроде ява в 32-х разрядной системе больше гигабайта выжрать и не сможет
2. Перезапускается автоматически в 7 утра
3. Вариант, да. Но их уже 8 (по 2 на каждом физическом сервере). Да и отложенных заданий приходится на каждый не более 2000.
Зависание отдельных серверов приложений SD
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
21.02.2012 12:12:32
Цитата
Григорий Ненашев пишет:
Сколько памяти в момент зависания использует служба?
Около гигабайта.
Зависание отдельных серверов приложений SD
Cообщений: 104Баллов: 85Регистрация: 16.05.2011
21.02.2012 10:23:10
Добрый день. С недавнего времени стал подвисать один из серверов приложений. В логах не особо много информации, сразу после перезапуска сервиса, выдаётся следующая ошибка (но это, я так понимаю, оттого, что клиенты пытаются соединиться заново под старыми сессиями):
Вт, 21/02/2012 09:52:37 <Data Access> JDBC error 547: []The INS ERT statement conflicted with the FOREIGN KEY constraint "SES_SVI_OID_FK". The conflict occurred in database "sdctdb", table "dbo.REP_SERVERS", column 'SVI_OID'., SQL state: 23000 for query: INS ERT INTO rep_sessions
( ses_oid
,ses_markedforremoval
,ses_svi_oid
,ses_client_ipport
,ses_server_ipport
,ses_client_ipaddress
,ses_isconcurrent
,ses_threadname
,ses_server_ipaddress
,ses_acc_oid
,ses_created
,ses_lockseq
) VAL UES ( ?
,?
,?
,?
,?
,NULL
,0
,?
,?
,?
, CONVERT(DATETIME,?,120)
,?)
Val ues:
?1601223823
Иногда перед зависанием в логах можно увидеть такую ошибку:
Вт, 21/02/2012 09:44:49 <ITP> IO Stream Exception: itp://хх.хх.хх.хх:1422
Вт, 21/02/2012 09:44:49 <Trace> ITPcom.hp.ifc.io.AppStreamException: Flush failed due to: Connection reset by peer: socket write error
at com.hp.ifc.io.AppDataStream.flushError(Unknown Source)
at com.hp.ifc.io.AppDataStream.flushBuffer(Unknown Source)
at com.hp.ifc.io.AppDataStream.write(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequestHandler.sendResult(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequestHandler.process(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpConnection.processRequest(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpThread.run(Unknown Source)
