Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Зависание отдельных серверов приложений SD

Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Страницы: 1
Зависание отдельных серверов приложений SD
Добрый день. С недавнего времени стал подвисать один из серверов приложений. В логах не особо много информации, сразу после перезапуска сервиса, выдаётся следующая ошибка (но это, я так понимаю, оттого, что клиенты пытаются соединиться заново под старыми сессиями):

Вт, 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)

Кто-нибудь в курсе, почему происходят такие вещи?
Сколько памяти в момент зависания использует служба?
Цитата
Григорий Ненашев пишет:
Сколько памяти в момент зависания использует служба?

Около гигабайта.
Есть три варианта.
1. Увеличить память на службу
2. Автоматически каждую ночь перезапускать службу
3. Поднять еще один APP сервер
Цитата
Григорий Ненашев пишет:
Есть три варианта.

1. Увеличить память на службу

2. Автоматически каждую ночь перезапускать службу

3. Поднять еще один APP сервер


1. Вроде ява в 32-х разрядной системе больше гигабайта выжрать и не сможет
2. Перезапускается автоматически в 7 утра
3. Вариант, да. Но их уже 8 (по 2 на каждом физическом сервере). Да и отложенных заданий приходится на каждый не более 2000.
Когда у меня была такая проблема, я частично перевел правила с Scheduled Tasks на JOB. Переписал полностью все правила DB на более оптимальные. Удалил 80% правил UL и перевел их на работу через бизнес логику системы.
Одно правило UL заменило % 60 правил на ограничение, в замен, того что было. Также оптимизировал базу для поиска, например если в поисковой форме где номер указывается в промежутке поиск работал, скажем сек 6 теперь 1 сек. Т.е стал работать как я бы искал через расширенную форму поиска с однозначным условием.
Для всех представлений как системных так и пользовательских на кастумные поля добавил индексов. (часто используемые в представлениях) Тогда представление у пользователей грузиться мгновенно,
Зависание app серверов происходит крайне редко. – Что не может не радовать, я их даже не перезапускаю автоматически. По прикладам это 6 серверов для работы с пользователями и 2 для почты.
Мне кажется, что зависание происходят из-за DB правил, простой пример, хотим видеть всех активных специалистов в онлайне по группе: В карточку заносим поле типа персонал, пишем правило на внесение в это поле сотрудника который изменил форму, и DB правилом уже пишем дату изменения в карточку пользователя. Вот теперь если специалист будет групповой правкой в объектах что-то править, то мы вызываем чумовую нагрузку на данное правило… может привести к зависанию сервиса. (проверял, работает).. «Есть свои нюансы».
Цитата
Григорий Ненашев пишет:
Когда у меня была такая проблема, я частично перевел правила с Scheduled Tasks на JOB. Переписал полностью все правила DB на более оптимальные. Удалил 80% правил UL и перевел их на работу через бизнес логику системы.

Одно правило UL заменило % 60 правил на ограничение, в замен, того что было. Также оптимизировал базу для поиска, например если в поисковой форме где номер указывается в промежутке поиск работал, скажем сек 6 теперь 1 сек. Т.е стал работать как я бы искал через расширенную форму поиска с однозначным условием.

Для всех представлений как системных так и пользовательских на кастумные поля добавил индексов. (часто используемые в представлениях) Тогда представление у пользователей грузиться мгновенно,

Зависание app серверов происходит крайне редко. – Что не может не радовать, я их даже не перезапускаю автоматически. По прикладам это 6 серверов для работы с пользователями и 2 для почты.

Мне кажется, что зависание происходят из-за DB правил, простой пример, хотим видеть всех активных специалистов в онлайне по группе: В карточку заносим поле типа персонал, пишем правило на внесение в это поле сотрудника который изменил форму, и DB правилом уже пишем дату изменения в карточку пользователя. Вот теперь если специалист будет групповой правкой в объектах что-то править, то мы вызываем чумовую нагрузку на данное правило… может привести к зависанию сервиса. (проверял, работает).. «Есть свои нюансы».

Спасибо. Давно хотел уже заменить кучу правил интерфейса каким-нибудь одним-двумя стандартными, теперь будет повод smile:)
Коллеги,
только что подвис один из двух app серверов. Вылечилось перезапуском первого сервиса. Вот что пишут логи на момент зависания:

Пн, 26/03/2012 12:29:04 <Data Access> : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:04 <Data Access> : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:04 <Data Access> : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:04 <Data Access> : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:43 <Data Access> : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:43 <Data Access> : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:43 <Data Access> : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:43 <Data Access> : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:30:02 <Data Access> : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:30:02 <Data Access> : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000

Чем может быть вызвано зависание? И могут ли профилактические работы, описанные выше, помочь в ее устранении?
Цитата
Артем Калихов пишет:
Коллеги,
только что подвис один из двух app серверов. Вылечилось перезапуском первого сервиса. Вот что пишут логи на момент зависания:
Пн, 26/03/2012 12:29:04 : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:04 : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:04 : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:04 : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:43 : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:43 : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:29:43 : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:29:43 : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000
Пн, 26/03/2012 12:30:02 : [SD-DB\SD]Changed database context to 'sdDB'., SQL state: 01000
Пн, 26/03/2012 12:30:02 : [SD-DB\SD]Changed language setting to us_english., SQL state: 01000

Чем может быть вызвано зависание? И могут ли профилактические работы, описанные выше, помочь в ее устранении?


Конечно же, что-то сказать не зная всех параметров довольно сложно. (поможет или нет) Нужно учитывать размер базы, на чем база, апп сервера, кол. правил, сколько пользователей в онлайне, кол. транзакций в сек. Сколько памяти на серверах как app так и db, какая БД. Проводятся ли работы над базой? Какой SP используется.. и.т.п

Нужно смотреть факторы которые могли вызвать зависание, может это правила. Может это память на апплике превысила свой предел.
Как вариант предлагаю создать новую тему и в ней описать все, что только можно. со всеми показателями. Тогда и выводы можно будет строить.
Страницы: 1

Сегодня были (гостей: 4, пользователей: 0, из них скрытых: 0)