Hi, Two suggestions for you:
1. Try decreasing the logSize parameter for LevelDB. You’ve have a greater number of smaller log files, and a greater chance of each log file being garbage-collected. 2. With KahaDB, it’s possible to configure multiple KahaDB stores, and to put your dead-letter type messages into a different store than everything else to reduce overhead: http://blog.garytully.com/2011/11/activemq-multiple-kahadb-instances.html <http://blog.garytully.com/2011/11/activemq-multiple-kahadb-instances.html> Unfortunately it doesn’t appear that this applies to LevelDB yet! Regards, Tim > On 28 Feb 2015, at 7:27 pm, Rural Hunter <ruralhun...@gmail.com> wrote: > > Hi, > > Activemq version 5.10.2, storage: leveldb. > > I have a queue which serves similiar function as dead letter queue. My > application process messages from another queue and if the processing > fails, it put the message into this queue. The messages are persistent and > average several KBs in size. My application processes many messages but the > failed message count is very small, less than 100 a day. I noticed after > the application running for several days, my activemq storage becomes > almost full. I configured the storage to 30G. I checked the normal queues > and topics and there is no queue with large count of message. Most of them > are empty and some have only several messages. Only the failure message > queue I metioned above has a few hundred messages(about 500) which are > accumulated in several days. > > I have no idea what takes so much storage. I checked the storage files and > found there are many db-xxxx.log with timestamp almost through the several > days. They are not consequent though. Some of the db-xxx.log files are not > there. So the file list is like this: > db-1000.log > db-1001.log > db-1003.log > db-1004.log > db-1005.log > db-1008.log > ... > I suspect the failed messages are in those db-xxx.log files so I just tried > to clear the failed message queue. Right after that I found those old > db-xxx.log disappeared and the storage usage went back to 2%. So it seems > clear that the about 500 failed messages took around 30G storage. But how > can it be? Those messages are very small in size and the total size of the > messsage should be no more than a few MBs.
