我们使用WSO2 DAS 3.1.0从WSO2 API-管理器接收事件并发送到数据库。
如果我们在4-5小时内每秒向DAS发送70-100个事件，性能会慢慢恶化，并开始"滞后"。起初，我们怀疑将生成的事件推送到数据库时出现了问题(我们有一个事件接收器、一个执行计划(每秒总结事件)和一个发布者到数据库)，但现在我们得出结论，这不是问题，数据库完全可以跟上负载。
为了隔离我们已经解决的问题，例如，在文件中添加了一个事件发布者与传入事件接收器(在我们执行计划中进行任何处理之前)，我们可以看到，当DAS性能恶化几秒钟时，该发布者也没有输出；因此，问题在于处理传入事件(我们还在将事件推送到数据库之间添加了一个队列，以确保没有背压传播到传入事件的处理中)。
然而，真正奇怪的是，当这种行为发生时(DAS中处理传入事件的性能恶化)，除了重新启动整个服务器之外，没有办法摆脱它(然后它开始重新工作，几个小时都没有问题)。即使我们停止向服务器发送事件几天，当我们开始向服务器发送1-2个事件时，处理所有事件之间也需要几秒钟的时间(因此直接"滞后"于传入事件)。在我们重新启动DAS之前，处理传入事件的性能似乎呈指数级下降。
如果有任何关于在哪里进行更改以避免此行为发生的潜在线索，我将非常高兴(清除内部事件也没有效果)。
经过大量调试，我们终于找到了原因。
在我们的Siddhi语句中，我们使用了带有动态变化时间戳的"group-by"，事实证明，正如这个bug所描述的那样，这种处理效率极低：https://github.com/wso2/siddhi/issues/431.
在修补指定的类后，问题消失了(但目前仍然存在一个漏洞，该产品会出现OOM，因为它没有发布动态的"group-by"信息)。