【发布时间】:2015-03-09 03:38:59
【问题描述】:
将 WSO2ESB 与 Websphere MQ JMS 传输结合使用,出于性能原因,我们不得不在一天内增加并发队列侦听器的数量。但是这样的改变导致了内存消耗的问题,出乎意料地似乎非常依赖于并发 JMS 线程的数量。
下面是 jvisualvm 图表,显示了在处理相同的大消息(最大 100M)时堆的状态,唯一的区别在于侦听器的数量:第一种情况下为 1,第二种情况下为 32。
任何提示将不胜感激。
【问题讨论】:
将 WSO2ESB 与 Websphere MQ JMS 传输结合使用,出于性能原因,我们不得不在一天内增加并发队列侦听器的数量。但是这样的改变导致了内存消耗的问题,出乎意料地似乎非常依赖于并发 JMS 线程的数量。
下面是 jvisualvm 图表,显示了在处理相同的大消息(最大 100M)时堆的状态,唯一的区别在于侦听器的数量:第一种情况下为 1,第二种情况下为 32。
任何提示将不胜感激。
【问题讨论】:
必须为每个客户端预先分配接收缓冲区。它也可能有一个预先分配的发送缓冲区,我不确定。我正在讨论 MQ 原则,而不是我不太了解的这个实现。无论如何,我认为这就是您在这里看到的主要内容。您也许可以改变缓冲区大小来解决这个问题。请注意,这与消息大小不同。这是总队列大小。即使将一些消息循环到磁盘,任何 MQ 都必须有一个大缓冲区。
您可能还会发现一些 ram 分配是用于工作单元的喋喋不休,以及由多个客户端产生的其他内务处理。
谈到 UoW,我当然希望您已经将异步问题考虑在内,以解决您的多客户端解决方案中可能涉及的任何事务。在我的书中最有效的答案是一个糟糕的答案。您应该努力证明您的异步解决方案不会崩溃。因为在 6 个月内,如果它发生故障,您将有一个地狱般的时间来记住在您的架构中的这个小地方是可能的。您放入队列以保持同步。你正在做的可能是在玩火。小心点。
【讨论】: