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 <james.mk.gr...@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 >
