Camunda DeploymentCache管理

Question

我们在Spring应用程序的内存方面遇到了问题。堆转储显示其主要部分由camunda组件org.camunda.bpm.engine.impl.persistence.deploy.cache.DeploymentCache - 69消耗，占的47%。在org.camunda.bpm.engine.impl.persistence.deploy.cache.BpmnModelInstanceCache中占主导地位的对象是deploymentCache - 69，03%。

最后，Camunda从DB表开始加载所有已部署的过程定义、用例定义、决策定义。我们有成千上万的过程定义。为了解决内存问题，我们使用了org.camunda.bpm.engine.RepositoryService#deleteDeployment(java.lang.String，boolean)方法，它从DB中的camunda系统表中删除数据。

        List<Deployment> oldDeployments = repositoryService.createDeploymentQuery()
                .deploymentBefore(date)
                .listPage(0, maxResult);
        boolean cascade = true;

        for (Deployment deployment : oldDeployments) {
            repositoryService.deleteDeployment(deployment.getId(), cascade);
        }

但是，使用这种方法，我们对删除过程没有太多的控制。这是很重要的，因为我们有一些支付逻辑很重的过程。如果发生事故，处理所需的时间可能比预期的要长得多。我们不能删除这些进程，但这是一种排斥

那么，还有另外一种方法，对删除过程/部署缓存添加更多的控制吗？比如：

• 添加处理程序。它使用业务数据从表中查询其他数据，以决定是否应该删除它。
• 添加到排除某些架构名称。
• 自定义DeploymentCache，使其仅在启动时加载指定期间的部署和按需加载其他部署。或指定deploymentCache限制

Camunda版本: 7.13.0

Answer 1

我不会把注意力集中在症状上，比如通过部署缓存级别来解决它，而是尝试清理(定期)环境，并在将来避免根本原因。

建立 清理 战略

• 了解使用报告已经可以清除的内容。
• 确保historyTimeToLive (ttl)是通过座舱或API接口在您的流程定义上设置的
• 如果需要，通过驾驶舱或API接口设置已在运行时中的流程定义上的ttl
• 如果需要的话，历史实例上的设定去除时间 (例如过去的绝对值)
• 为要删除的历史实例运行清理
• 考虑使用流程实例迁移将实例从低实例编号的部署转移到更新版本。

因此，许多部署都应该有0个流程实例(它们已经清理过，也形成了历史记录，或者在运行时迁移了)。

删除具有来自DB的0个进程实例的部署

1. 获取部署列表：https://docs.camunda.org/manual/7.18/reference/rest/deployment/get-query/
2. 计算部署所具有的流程实例：https://docs.camunda.org/manual/7.18/reference/rest/process-instance/get-query-count/
3. 删除部署：https://docs.camunda.org/manual/7.18/reference/rest/deployment/delete-deployment/

步骤1-3也可以通过卡蒙达驾驶舱中的部署屏幕获得。

识别的根本原因

几百-好的。成千上万-也许吧。数以万计的震级似乎太高了。在没有模型更改的情况下，您是否可能部署副本？您是否可能为每个模型创建一个部署，而不是将它们捆绑在一个部署中？您是否可能以编程的方式执行一些执行小更改的操作，从而创建大量的部署？

。

。

。

关于版本升级的附加说明

Camunda版本7.13.0 ~2.5岁，未修补。在这些版本中有重要的安全相关修复。即使您无法访问Community上的修补程序版本，升级到7.18.0也会给您带来很多补丁(以及一些特性)。

升级您的Camunda版本也将允许您升级到更新的支持弹簧启动版本，这将再次为您提供大量的安全性和其他修复。

例如，您正在运行的版本将容易受到臭名昭著的log4shell漏洞的攻击。