IBM BPM ненормальный промежуток времени между сохранением изменений и доступностью этих изменений

Question

Наша среда IBM BPM DEV столкнулась с некоторыми проблемами, которые мы не можем понять и решить в течение недели. Не могли бы вы посмотреть и проконсультироваться со мной по этим вопросам?

1. Необычный временной промежуток между сохранением изменений в Process Applications / их потоках процессов / службах в Process Center и доступностью этих изменений в Портал процесса обнаружен. Он варьируется, но может быть до 40 минут, прежде чем сохраненные изменения будут доставлены в Портал процессов. Пока этого не произойдет, пользователи (разработчики, тестировщики) продолжают работать со старыми тренерами, сервисами, процессами и т. Д. c. во время работы с версией Tip приложения / процесса. Как будто разработчик вообще ничего не изменил, что делает процесс разработки / технического тестирования очень неэффективным и разочаровывающим.

2. Панели мониторинга и формы задач из версий Tip занимают значительно больше времени загрузить с 13 января, чем раньше. Мы сталкиваемся с этой проблемой при работе с версиями Tip, при работе с версиями моментальных снимков проблем не возникает.

Я подозреваю, что это может быть как-то связано с внутренним использованием БД IBM BPM, но наши администраторы не видят каких-либо критических изменений / проблем с производительностью на стороне базы данных. Таким образом, я не знаю, как решить вышеупомянутые проблемы.

Our configuration:
BPM: 8.6.0.201803
Server: 2 CPU, 16GB RAM
$ df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   90G   61G   26G  71% /
devtmpfs               7.8G     0  7.8G   0% /dev
tmpfs                  7.8G   84K  7.8G   1% /dev/shm
tmpfs                  7.8G  8.9M  7.8G   1% /run
tmpfs                  7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1              488M  185M  268M  41% /boot
tmpfs                  1.6G   16K  1.6G   1% /run/user/42
tmpfs                  1.6G     0  1.6G   0% /run/user/0
tmpfs                  1.6G     0  1.6G   0% /run/user/1006
tmpfs                  1.6G     0  1.6G   0% /run/user/1008
tmpfs                  1.6G     0  1.6G   0% /run/user/1007
tmpfs                  1.6G     0  1.6G   0% /run/user/1005

DB: Oracle, run in a supercluster.

Заранее спасибо за помощь!

Answer 1

В настоящее время я поддерживаю систему IBM BPM в нескольких средах, и через определенный промежуток времени я видел такое снижение производительности. В большинстве случаев это происходит потому, что система BPM накапливает много данных с течением времени, и они не очищаются регулярно. Я не могу быть уверен, что проблемы с производительностью в вашем случае вызваны той же причиной, но я все же рекомендую начинать отсюда.

Эта статья IBM developerWorks является хорошей отправной точкой для этого действия: Очистка данных в IBM Business Process Manager .

В вашей среде разработки у вас будет Process Center. Процессный центр в основном накапливает снимки приложений. Именованные моментальные снимки - это одно, но Process Center также сохраняет дельта-тип моментального снимка при каждом сохранении приложения процесса (из Web Process Designer). Их называют безымянными снимками, и они могут быстро накапливаться в чрезвычайно больших количествах.

Подход к очистке, который я использую для Process Center, заключается в следующем. Сначала я удаляю все экземпляры процесса. Затем я удаляю безымянные снимки сверх определенного количества (100, чтобы быть определенным c). Затем я удаляю именованные снимки, которые архивируются. Эта задача написана по сценарию, и я выполняю ее еженедельно.

Я уже сообщил о последствиях этих действий моей команде разработчиков. Они знают, что потеряют экземпляры процессов, но ценность этих экземпляров уже ограничена в экземпляре Process Center. Я периодически напоминаю им архивировать старые именованные снимки, чтобы они также были очищены.

Я бы также порекомендовал вам изучить использование диска в вашей системе. IBM BPM в первую очередь записывает все свои данные в свою базу данных, поэтому на самом деле нет причин для значительного роста файловой системы. Если ваш экземпляр BPM имеет тенденцию к взлому sh, то вы, вероятно, найдете несколько файлов дампа (дамп ядра / дамп кучи / дамп потока) в каталоге вашего профиля. Вы можете удалить эти файлы дампа, чтобы освободить место, но вы должны решить проблему, которая в первую очередь вызывает cra sh.

Если вы обнаружите доказательства сбоя, я рекомендую взглянуть на ваши размеры кучи а также кэши веток и снимков в BPM. По сути, это кеш, который загружает в память самые последние версии ваших приложений процессов и их снимки, чтобы разработчики могли работать над ними быстрее. Хотя теоретически это звучит нормально, по умолчанию размер этих кэшей составляет 64 - 64 ветви и 64 снимка на ветку. Это потенциально 4096 моментальных снимков процесса, загруженных в память одновременно, что может легко вызвать исключение OutOfMemoryException и cra sh.

. Вы можете настроить размер этого кэша, используя файл 100Custom. xml. Дополнительную информацию смотрите в этой статье: Настройка размеров ветки и кэша моментальных снимков в IBM Business Process Manager . Уменьшение размера кэша позволит вам сэкономить на памяти и избежать сбоев. Компромисс заключается в том, что в случае пропадания кэша потребуется больше обращений к базе данных.

Надеемся, эта информация поможет вам сузить проблемы с вашим IBM BPM Process Center и восстановить прежние уровни производительности. Удачи!