Page History

...

Regardless of which rebalance mode is used `SYNC` or ` SYNC or ASYNC`  (defined in `CacheRebalanceMode` enum CacheRebalanceMode enum), the Apache Ignite rebalance implementation has a number of limitations caused by a memory-centric desing architecture:

• Although all cache data is sent between peer's in batches (`GridDhtPartitionSupplyMessage` usedGridDhtPartitionSupplyMessage used) it still processes entries one by one. Such approach have the low impact with a pure in-memory Apache Ignite use case but it leads to additional fsync's and logging WAL records with the native persistence enabled. 
  
  By default,  `setRebalanceThreadPoolSize` is setRebalanceThreadPoolSize is set to `1` and `setRebalanceBatchSize` to `512K` which 1 and setRebalanceBatchSize to 512K which means that thousands of key-value pairs will be processed single-thread and individually. In addition, this also impacts on: 
  • Extra chages of Ignite node datastructure. Adding each entry record into `CacheDataStore` will CacheDataStore will traverse and modify each index tree N-times. We will allocate space N-times within `FreeList` and FreeList and have to additionally store WAL page delta records ~ O(N*log(N)) ;
  • For instance, batch with N-entries will produce N WAL reocrds which might end up with N fsyncs (fsync-wal configuration);
    
    
• Rebalancing procedure doesn't utilize network and storage device throughput to full extent.

...