WSO2 DAS 性能缓慢恶化答案

【问题标题】：WSO2 DAS performance slowly deterioratesWSO2 DAS 性能缓慢恶化
【发布时间】：2017-03-18 00:17:54
【问题描述】：

我们将 DAS 3.1.0 与我们发送事件的 API Manager 1.10.0 一起运行。事件在 DAS 的接收器中接收，发送到流，然后由执行计划处理，结果发送到两个发布者，将数据发送到 RDBMS。 DAS 的事件数约为 30-40 个事件/秒。

首次启动时，DAS 能够实时向 RDBMS 输出事件，但我们可以注意到它开始“落后”的速度非常缓慢。一个小时左右后，“滞后”可能是 15-30 秒，几个小时后，“滞后”大约落后 20 分钟，4-5 小时后，不再处理任何事件（我们可以看到它没有此时将所有数据存储在其传入事件数据库中）。

DAS 仍在运行，最终没有任何错误日志——但我们显然希望它保持实时输出数据，而不是指数“退避”乘数，这似乎是案例。

在设置方面有什么补救措施吗？它会以某种方式累积记忆问题吗？（附上一些内存使用的输出）。我们可以看到随着时间的推移内存开始积累，因此我们尝试更改 JVM 设置以进行优化：

-Xms3072m -Xmx3072m -XX:MaxPermSize=1024m -XX:NewSize=256m -XX:MaxNewSize=614m -XX:SurvivorRatio=10 -XX:-DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+AggressiveOpts -XX:+UseStringCache -XX:+OptimizeStringConcat

我们还尝试更改一些性能设置，使其至少“持续更长时间”，但结果仍然相同：

数据桥配置.xml：

<workerThreads>3</workerThreads>

<maxEventBufferCapacity>1</maxEventBufferCapacity>

<eventBufferSize>2000</eventBufferSize>

<clientTimeoutMin>30</clientTimeoutMin>

数据代理配置.xml：

<QueueSize>1024</QueueSize>
<BatchSize>100</BatchSize>
<CorePoolSize>2</CorePoolSize>
<SocketTimeoutMS>30000</SocketTimeoutMS>
<MaxPoolSize>2</MaxPoolSize>
<KeepAliveTimeInPool>20</KeepAliveTimeInPool>
<ReconnectionInterval>30</ReconnectionInterval>
<MaxTransportPoolSize>250</MaxTransportPoolSize>
<MaxIdleConnections>250</MaxIdleConnections>
<EvictionTimePeriod>5500</EvictionTimePeriod>
<MinIdleTimeInPool>5000</MinIdleTimeInPool>
<SecureMaxTransportPoolSize>250</SecureMaxTransportPoolSize>
<SecureMaxIdleConnections>250</SecureMaxIdleConnections>
<SecureEvictionTimePeriod>5500</SecureEvictionTimePeriod>
<SecureMinIdleTimeInPool>5000</SecureMinIdleTimeInPool>

Analytics-event-sink-config.xml：

<QueueSize>1024</QueueSize>

<maxQueueCapacity>1</maxQueueCapacity>

<maxBatchSize>128</maxBatchSize>

<WorkerPoolSize>5</WorkerPoolSize>

遗憾的是，这并没有帮助。非常感谢任何提示或提示。

内存使用情况。服务器在下午 3 点、晚上 8 点和早上 7 点 40 分重新启动，因为它太落后了。

【问题讨论】：

标签： wso2 wso2-das

【解决方案1】：

看起来您的设置与 DAS 的建议有些不同。请关注DAS performance tuning guide，看看您是否有任何改进。

【讨论】：

您好，感谢您的回复。我们在性能调优指南中尝试了不同的选项，遗憾的是，它们的行为都没有任何变化。如前所述，当我们调整上述选项时，我们至少“持续”了更长的时间——但仍然是相同的长期行为。

【解决方案2】：

在这种情况下，请检查数据库写入性能。例如，在某些数据库服务器中，当记录具有 blob 字段时，当记录数增加时，插入速度会变慢（DAS 分析表使用 blob 字段来编码和存储字段值）。所以最好对数据库操作进行分析，看看它们是否真的很慢。在那之后，您可能想要进行特定于 DBMS 的优化，以提高博客存储的性能。

干杯，安佳娜。

【讨论】：

一些进一步的信息。我们已经测试并得出结论，问题在于处理传入事件。当问题开始时，事件不会出现在我们的 DAS 的接收器中（没有很大的延迟）。此外，当性能恶化时，如果不重新启动它，就无法从中“恢复”。无论它是否处理一天的任何事件，并且我们清除 DAS 数据库中的所有事件，在传入事件显示为已接收事件之前仍然存在巨大延迟。这是否提供了进一步的线索？