Infinispan 6.0 SingleFileStore cleanup and defragmentation

[rajeshjangam]

Hello All,

We are testing the latest Infinispan 6.0 SingleFileStore version for our application.

We tend to create a lot of entries in the store and remove/evict them when not required.

However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed.

This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.

Is there a mechanism that periodically reclaims the space or defragments the store file?

Today, the file sizes go into GBs where as the actual data in the file is only a handful entries.

Thanks,

Rajesh

[rajeshjangam]

We have a proposed enhancement (in the SingleFileStore) that optimizes space usage and attempts to reclaim it whenever possible.

It is two fold:

1. Truncates the file if there are free fileentries at the end of the data file.

2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases.

Attached is the modified extended version of the source. We would like to get it reviewed from the relevant authors.

We have tested this internally and it seems to be helping with space usage.

Thanks,
Rajesh

[mircea.markus]

The file store should compact space, unless the size of the entries you add is constantly increasing. Do you produce a test that reproduces this behaviour?

[rajeshjangam]

Hi Mircea,

Yes, we have two usecases:

1. A persistent queue where entries get created and removed very fast. The size of data in this case is random.

    In our environment, the sizes of such files grow to around ~700 MB before the file stops growing.

    With our proposed fix (ISPN-3877), the size stays very much within control ~5-6 MB

2. A result repository for a certain tasks. As each task progresses, it updates the result in the repository (against its id as key).

   Each time, the result size grows. So, new results always get appended towards end of the file (and earlier entry in the cache gets added to freelist).

   These smaller entries are then useless for allocating the larger objects. Coalescing smaller free entries into bigger ones makes this possible.

   ISPN-3894 is created to track this.

I have created two issues and two pull requests:

Issue: https://issues.jboss.org/browse/ISPN-3877

corresponding pull request: https://github.com/infinispan/infinispan/pull/2335

Issue: https://issues.jboss.org/browse/ISPN-3894

corresponding pull request: https://github.com/infinispan/infinispan/pull/2336

Thanks,
Rajesh

[mircea.markus]

Thanks for taking it so far, looking into this..

[rajeshjangam]

Thanks Mircea, the two issues also have tests to reproduce.