Почему Direct ByteBuffer постоянно растет на сервере HornetQ, ведущем к OOM?

Question

Конфигурация

У меня есть установка автономной HornetQ (2.4.7-Final) кластера на Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-29-родовой x86_64). Экземпляр имеет 16 ГБ оперативной памяти с 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 других очередей, связанные с адресом по умолчанию, заданный групповой символ.

Проблема

В течение периода времени, память с прямым ByteBuffer постепенно увеличивается в размерах и даже занимает пространство подкачки в конечном итоге метание OutOfMemoryError («Прямой буфер памяти»).

Я пробовал много настроек JVM и JMS, но напрасно. Даже задание -XX: MaxDirectMemorySize = 4G для JVM привело к раннему OOME по той же причине. Кажется, что ByteBuffer не читается, или GC не требует памяти без ссылок.

Неужели кто-то сталкивался с тем же вопросом раньше?

Любые предложения приветствуются и благодарим заранее.

Answer 1

Я ничего о внутренних hornetq не знаю, так что этот ответ охватывает только DBBs в целом:

• сво обычную утечку, то DBB объекты просто по-прежнему доступны, и, таким образом, не освобождается. Это может быть связано либо с ошибкой, либо с неправильным использованием приложения.
  Обычный подход заключается в том, чтобы взять кучу кучи и определить, что сохраняет объекты в живых.

• Буферы становятся недоступными, но сборщик мусора выполняет старую коллекцию генераторов так редко, что требуется длительное время, пока они не будут собраны, а собственная память освободится. Если сервер работает с -XX:+DisableExplicitGC, который также подавляет последнюю попытку полного GC, когда достигнут предел MaxDirectMemorySize.
  Настройка GC для более частого запуска, чтобы обеспечить своевременное освобождение DBB, может решить этот случай.