java - 为什么 Direct ByteBuffer 在 HornetQ 服务器上不断增加导致 OOM？

Question

配置

我在 Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-29-generic x86_64) 上设置了一个独立的 HornetQ (2.4.7-Final) 集群。该实例有 16GB RAM 和 2 个内核，我已将 -Xms5G -Xmx10G 分配给 JVM。

HornetQ配置中的地址设置如下:

   <address-settings>
      <address-setting match="jms.queue.pollingQueue">
         <dead-letter-address>jms.queue.DLQ</dead-letter-address>
         <expiry-address>jms.queue.ExpiryQueue</expiry-address>
         <redelivery-delay>86400000</redelivery-delay>
         <max-delivery-attempts>10</max-delivery-attempts>
         <max-size-bytes>1048576000</max-size-bytes>
         <page-size-bytes>10485760</page-size-bytes>
         <address-full-policy>PAGE</address-full-policy>
         <message-counter-history-day-limit>10</message-counter-history-day-limit>
      </address-setting>
      <address-setting match="jms.queue.offerQueue">
         <dead-letter-address>jms.queue.DLQ</dead-letter-address>
         <expiry-address>jms.queue.ExpiryQueue</expiry-address>
         <redelivery-delay>3600000</redelivery-delay>
         <max-delivery-attempts>25</max-delivery-attempts>
         <max-size-bytes>1048576000</max-size-bytes>
         <page-size-bytes>10485760</page-size-bytes>
         <address-full-policy>PAGE</address-full-policy>
         <message-counter-history-day-limit>10</message-counter-history-day-limit>
      </address-setting>
      <address-setting match="jms.queue.smsQueue">
         <dead-letter-address>jms.queue.DLQ</dead-letter-address>
         <expiry-address>jms.queue.ExpiryQueue</expiry-address>
         <redelivery-delay>3600000</redelivery-delay>
         <max-delivery-attempts>25</max-delivery-attempts>
         <max-size-bytes>1048576000</max-size-bytes>
         <page-size-bytes>10485760</page-size-bytes>
         <address-full-policy>PAGE</address-full-policy>
         <message-counter-history-day-limit>10</message-counter-history-day-limit>
      </address-setting>
      <!--default for catch all-->
      <!-- delay redelivery of messages for 1hr -->
      <address-setting match="#">
         <dead-letter-address>jms.queue.DLQ</dead-letter-address>
         <expiry-address>jms.queue.ExpiryQueue</expiry-address>
         <redelivery-delay>3600000</redelivery-delay>
         <max-delivery-attempts>25</max-delivery-attempts>
         <max-size-bytes>1048576000</max-size-bytes>
         <page-size-bytes>10485760</page-size-bytes>
         <address-full-policy>PAGE</address-full-policy>
         <message-counter-history-day-limit>10</message-counter-history-day-limit>
      </address-setting>
   </address-settings>

还有10个其他队列绑定(bind)到通配符指定的默认地址。

问题

在一段时间内，Direct ByteBuffer 内存的大小逐渐增加，甚至占据交换空间，最终抛出 OutOfMemoryError(“直接缓冲内存”)。

我尝试了很多 JVM 和 JMS 调优，但都无济于事。出于同样的原因，甚至向 JVM 指定 -XX:MaxDirectMemorySize=4G 也会导致早期 OOME。似乎未读取 ByteBuffer 或 GC 未声明未引用的内存。

有没有人遇到过同样的问题？

欢迎提出任何建议，并提前致谢。

Answer 1

我对 hornetq 的内部结构一无所知，所以这个答案只涵盖一般的 DBB:

• 这是一个普通的泄漏，DBB 对象仍然可以访问，因此没有被释放。这可能是由应用程序中的错误或不正确的使用引起的。
  这里通常的方法是进行堆转储并确定是什么让对象保持 Activity 状态。

• 缓冲区变得不可访问，但垃圾收集器很少执行旧代收集，以至于需要很长时间才能真正收集它们并释放 native 内存。如果服务器以 -XX:+DisableExplicitGC 运行，那么在达到 MaxDirectMemorySize 限制时也会抑制最后一次 Full GC 尝试。
  调整 GC 以更频繁地运行以确保及时释放 DBB 可以解决这种情况。