I'm sorry I made a mistake. My storage is kahadb. We switched from leveldb to kahadb a while ago and I forgot that. Thanks for the links. Now understand what happened!
2015-02-28 19:03 GMT+08:00 Tim Robbins <tim.robb...@outlook.com>: > 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. > >
