Page History

...

• Although all cache data is sent between peer's in batches (GridDhtPartitionSupplyMessage 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 the Apache Ignite native persistence enabled. 
  
  By default, setRebalanceThreadPoolSize is set to 1 and setRebalanceBatchSize to 512K which means that thousands of key-value pairs will be processed single-thread and individually. In addition, this also Such approach impacts on: 
  • Extra The extra unnecessary chages changes to keep of Ignite a node data structures up to date. Adding each entry record into CacheDataStore will traverse and modify each index tree N-times. We It will allocate the space N-times within FreeList and  structure and have to additionally store WAL page delta records ~ with approximate complexity ~ O(N*log(N));
  • Batch with N-entries will produce N-records in WAL reocrds which might end up with N fsyncs (assume fsync -wal WAL mode configuration enabled);
  • Increased the chance of huge JVM pauses. The more attendant objects we produces by applying changes, the more GC happens and the greater chance of JVM pauses we have;
    
    
• Rebalancing procedure doesn't utilize the network and storage device throughput to full extent even with sufficiently large values of setRebalanceThreadPoolSize parameter.

...