Large db.data with ActiveMQ 5.13.1

[James Green <ja...@gmail.com>]

For a broker that should be holding almost nothing this looks very
suspicious:

total 779M
-rw-r--r-- 1 999 docker  32M Jul 11 06:51 db-3393.log
-rw-r--r-- 1 999 docker  32M Jul 11 09:21 db-3394.log
-rw-r--r-- 1 999 docker  32M Jul 14 09:26 db-3444.log
-rw-r--r-- 1 999 docker 684M Jul 14 09:26 db.data
-rw-r--r-- 1 999 docker 3.2M Jul 14 09:26 db.redo
-rw-r--r-- 1 999 docker    8 Jul  5 17:53 lock

I'm used to hunting down problems with reaping db index logs in the past,
but not with very large db.data files. Googling around doesn't reveal much,
either.

Can anyone advise on this? Another of our brokers:

total 647M
-rw-r--r-- 1 999 docker  32M Jul 14 09:30 db-2647.log
-rw-r--r-- 1 999 docker 635M Jul 14 09:30 db.data
-rw-r--r-- 1 999 docker 3.2M Jul 14 09:30 db.redo
-rw-r--r-- 1 999 docker    8 Jul  5 17:55 lock

Seems worryingly consistent. Unsure what I'm looking at.

Thanks,

James

Re: Large db.data with ActiveMQ 5.13.1

[Christopher Shannon <ch...@gmail.com>]

That is the KahaDB index file and it will grow to the size it needs as the
broker is running.  Based on the size it means that at one point you must
have had a lot of data in the broker and the index file so it grew to that
size.  Unfortunately, the file itself won't ever shrink in size after it
grows but it generally will get to a stable size relatively to the
allocated size of the store and the workload of the broker.  When items are
deleted out of the page file the space stays allocated.

If for some reason you want to forcefully shrink the size then you want to
have to shut down the broker, delete the file, and then on restart the
broker would replay the journal to rebuild it.  But if you do this then the
size would just grow again as soon as messages start flowing.

On Thu, Jul 14, 2016 at 4:31 AM, James Green <ja...@gmail.com>
wrote:

> For a broker that should be holding almost nothing this looks very
> suspicious:
>
> total 779M
> -rw-r--r-- 1 999 docker  32M Jul 11 06:51 db-3393.log
> -rw-r--r-- 1 999 docker  32M Jul 11 09:21 db-3394.log
> -rw-r--r-- 1 999 docker  32M Jul 14 09:26 db-3444.log
> -rw-r--r-- 1 999 docker 684M Jul 14 09:26 db.data
> -rw-r--r-- 1 999 docker 3.2M Jul 14 09:26 db.redo
> -rw-r--r-- 1 999 docker    8 Jul  5 17:53 lock
>
> I'm used to hunting down problems with reaping db index logs in the past,
> but not with very large db.data files. Googling around doesn't reveal much,
> either.
>
> Can anyone advise on this? Another of our brokers:
>
> total 647M
> -rw-r--r-- 1 999 docker  32M Jul 14 09:30 db-2647.log
> -rw-r--r-- 1 999 docker 635M Jul 14 09:30 db.data
> -rw-r--r-- 1 999 docker 3.2M Jul 14 09:30 db.redo
> -rw-r--r-- 1 999 docker    8 Jul  5 17:55 lock
>
> Seems worryingly consistent. Unsure what I'm looking at.
>
> Thanks,
>
> James
>