Websphere IBM BPM保存更改和这些更改的可用性之间的异常时间间隔

我们的IBM BPM开发环境已经面临一些我们无法理解和解决的问题大约一周了。你能看一下并就这些问题咨询我吗

在Process Center中保存对流程应用程序/其流程流/服务的更改与Process Portal中这些更改的可用性之间检测到异常时间间隔。它会有所不同，但在将保存的更改传递到流程门户之前可能长达40分钟。在此之前，用户（开发人员、测试人员）在使用应用程序/流程的Tip版本的同时，继续使用旧的指导、服务、流程等。这就像开发人员根本没有改变任何东西一样，这使得开发/技术测试过程非常低效和令人沮丧

自1月13日以来，Tip版本中的仪表盘和任务表单的加载时间比以前要长得多。我们在使用Tip版本时会遇到这个问题，使用快照版本时不会出现任何问题

我怀疑这可能与IBM BPM对DB的内部使用有关，但我们的DBA没有发现DB方面的任何关键更改/性能问题。因此，我不知道如何解决上述问题

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.

---

提前感谢您的帮助

我目前正在跨多个环境维护一个IBM BPM系统，在一段时间后，我看到了这种类型的性能下降。在大多数情况下，这是因为BPM系统随着时间积累了大量数据，而这些数据没有定期清理。我不能确定您的案例中的性能问题是出于相同的原因，但我仍然建议从这里开始

这篇IBM developerWorks文章是此活动的良好起点：

在您的开发环境中，您将拥有一个Process Center。Process Center主要累积应用程序的快照。命名快照是一回事，但Process Center在每次保存流程应用程序时（从Web Process Designer）都会保留一个增量类型的快照。这些快照称为未命名快照，它们可以快速累积到非常大的数量

我对Process Center使用的清理方法如下所示。我首先删除所有流程实例。然后，我删除超过一定数量（具体为100）的未命名快照。然后，删除已存档的命名快照。这个任务是脚本化的，我每周运行一次

我已经向我的开发团队传达了这些行动的效果。他们知道他们将丢失流程实例，但这些实例的价值在process Center实例上已经受到限制。我会定期提醒他们归档旧的命名快照，以便将它们也清理干净

我还建议您调查系统上的磁盘使用情况。IBM BPM主要将其所有数据写入其数据库，因此文件系统没有明显增长的理由。如果您的BPM实例有崩溃的趋势，那么您可能会在概要文件目录下找到大量转储文件（核心转储/堆转储/线程转储）。您可以删除这些转储文件以恢复空间，但首先应该解决导致崩溃的问题

如果确实发现崩溃的迹象，我建议查看堆大小以及BPM中的分支和快照缓存。基本上，这是一个缓存，用于将流程应用程序的最新版本及其快照加载到内存中，以便开发人员能够更快地处理它们。虽然这在理论上听起来不错，但这些缓存的默认大小是64-64个分支，每个分支有64个快照。这意味着可能会有4096个进程快照一次加载到内存中，这很容易导致OutOfMemoryException和崩溃

您可以使用100Custom.xml文件调整此缓存的大小。有关更多详细信息，请参阅本文：。减少缓存大小可以节省内存并避免崩溃。折衷的办法是，如果缓存未命中，将需要更多的数据库调用

---

希望这些信息能够帮助您缩小IBM BPM Process Center的问题范围，并恢复早期的性能水平。祝你好运

我们最近遇到了同样的情况，原因有两个。1-我们有太多工具箱和流程应用程序的快照+100，因为我们已经工作了几个月没有清理，如果不需要，您需要开始存档和删除这些快照。2-由于一些错误，我们的核心转储目录已满，我看不出您的问题所在。您好，代码向导！1.关于归档流程应用程序和工具包的快照，我得出了相同的结论。2.为了确保我们在同一页上，请指定BPM核心转储目录的路径（可能是相对路径）好吗？服务器仍然有一些空闲磁盘空间，但是最好监视您提到的目录，以避免将来磁盘空间不足。当我完成对旧快照的归档后，我将更新这篇文章，介绍我希望实现的性能提升的结果。谢谢在我们的开发服务器上，它位于/IBM/BPM86PS/profiles/BPMSrv01/上，是一个.dmp文件。在我们的案例中，有一点是12Gbs，我们不知道是什么导致了这样的事情。