Page History

Motivation

...

PageIdTable manages mapping from Page ID to relative pointer map (rowAddr) within unsafe segment chunk.

Page based eviction

If durable memory operates with disk (native peristence is covered in Ignite Persistent Store - under the hood) then PageIdTable table is also used to check if a page is actually available in memory or has to be loaded from disk. As a result, even SQL queries can be fully utilized from Ignite applications when only a subset of pages is in memory. In this case required pages will be taken from disk during query execution. 

...

Let's suppose RAM memory is fully filled with pages, and it is required to allocate new. It is required to evict some page from memory

Image RemovedImage Added

Ignite uses Eviction Policy to determine which page to select to be evicted.

 Simplest algorithm would be selected for eviction is LRU, but it requires double linked list. It is not simple to implement such structure in off heap.

Algorithm used instead is Random-LRU (most recent access timestamp is stored for a data page). This algorihtm is used always if Persistent Data store mode enabled.

Eviction is started only if memory segment is full and it is impossible to allocate page in segment chunk. During first page eviction warning message is printed to logs

Page evictions started, this will affect storage performance (consider increasing MemoryConfiguration#setPageCacheSize).

If this message appeared in log it means segment is full and for allocation of new page it is required to purge some other page. Eviction may have negative influence to performance because in some cases it is possible that ignite continiously evicts page from RAM and some steps later reqiures this page data. In this case it is required to re-read data from disc.

Entry eviction

Eviction is used not only in Ignite Persistent Store - mode. Same technique is required if Ignite is used as fast access cache with 3rd party DB as persistence.

...