wso2 bps OutOfMemoryError — неэффективный список событий

Имея WSO2 BPS 3.6.0, мы время от времени сталкивались с OutOfMemoryError, и сервер останавливался. После анализа кучи мы подозреваем:

У нас есть несколько процессов, которые периодически просматривают некоторую информацию (используя веб-службу) до тех пор, пока состояние бизнес-элемента не изменится. Через некоторое время у некоторых экземпляров процесса может быть МНОЖЕСТВО событий (тысячи, некоторые 10k). При попытке просмотреть информацию об экземпляре в углеродной консоли загруженные данные (действия экземпляра) могут вызвать en OutOfMemoryError и отключить сервер (имеющий 6 ГБ ОЗУ) :(

Как обходной путь - используем поиск по БД:

select ode_event.event_id, ode_event.detail, ode_event.tstamp, ode_event.type,
ode_event.instance_id, ode_event.process_id,
ode_scope.scope_name
from ode_event, ode_scope where ode_event.instance_id=18204 and 
(ode_event.scope_id = ode_scope.scope_id);

хотя мы считаем, что идея разрешить любым бизнес-пользователям (даже владельцам процессов) прямой доступ к базе данных очень плоха.

Есть ли (лучший) способ/запрос, чтобы увидеть действия? Какой правильный проект github для размещения улучшения/функции (для загрузки действий с разбивкой на страницы)?

Редактировать:

видя исходный код, это «поведение» унаследовано от реализации Apache-ODE (жадно загружая весь список областей и событий в память)


wso2 wso2bps apache-ode
person gusto2    schedule 16.12.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это текущее поведение. Мы можем улучшить его, добавив нумерацию страниц. Но это причина, которая не является приоритетной.

Если вы проверите размеры отдельных таблиц БД, вы увидите, что таблица событий заняла большую часть места. Это связано с тем, что события уровня отладки процесса включены по умолчанию и генерируют множество событий. Эти события будут полезны во время разработки, но когда дело доходит до производства, их необходимо отключить. В противном случае вы тратите впустую производственные ресурсы (CPS, память, пространство БД). Это повлияет на производительность всего двигателя BPS.

Вот несколько общих рекомендаций.

Если у вас есть более крупный и продолжительный процесс, рекомендуется включать событие только для выбранных областей, которые необходимо отслеживать. (Даже лучше, если у вас их не будет. :))

Кроме того, вам нужно будет постоянно удалять старые данные из базы данных. (Просто погуглите документацию по BPS для скриптов). В противном случае ваш администратор баз данных будет жаловаться на то, что в БД недостаточно места для запуска в ближайшем будущем. :)

События не требуются для выполнения процесса. Таким образом, вы можете очистить его. В вашем сценарии можно ли очистить СТАРЫЕ события активного процесса BPEL? Например: очистить события старше 1/2/7.. дней. ?. Это решит вашу проблему на некоторое время.

person Hasitha Aravinda    schedule 17.12.2016
comment
Спасибо за ответ. ИМХО, контрольный журнал — одна из самых ценных функций в области BPM. Видимо придётся реализовывать аудит/упрощённую историю событий отдельно от таблицы событий :( По крайней мере полезно знать ограничения - person gusto2; 17.12.2016