One more question: will the same thing happen if I switch to leveldb?

2015-02-28 22:53 GMT+08:00 Rural Hunter <ruralhun...@gmail.com>:

> 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.
>>
>>
>

Reply via email to