Nikita-tech-writer commented on a change in pull request #9216: URL: https://github.com/apache/ignite/pull/9216#discussion_r662964780
########## File path: docs/_docs/memory-configuration/replacement-policies.adoc ########## @@ -0,0 +1,96 @@ +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. += Replacement Policies + +When link:persistence/native-persistence[Native Persistence] is on and Ignite stores on disk more data than off-heap memory allocated for the data region, to preload some page from the disk to the completely full off-heap memory another page should be evicted from the off-heap to the disk. This process is called _page rotation_ or _page replacement_. + +When Native Persistence is off _eviction_ is used instead of _page replacement_. See link:memory-configuration/eviction-policies[Eviction Policies] page for more information. + +Page replacement is implemented as follows. + +When Ignite requires some page, it tries to find this page in the off-heap memory, if the page currently not in the off-heap memory (page fault occurs), this page is preloaded from the disk, but if off-heap memory already full some another page should be chosen to be replaced (stored to the disk and evicted). + +Ignite supports three algorithms to find pages to replace: + +* Random-LRU algorithm; +* Segmented-LRU algorithm; +* CLOCK algorithm. + +Page replacement algorithm can be configured by `PageReplacementMode` property of `DataRegionConfiguration`. By default, CLOCK algorithm is used. + +[tabs] +-- +tab:XML[] +[source,xml] +---- +<bean class="org.apache.ignite.configuration.IgniteConfiguration"> + <!-- Memory configuration. --> + <property name="dataStorageConfiguration"> + <bean class="org.apache.ignite.configuration.DataStorageConfiguration"> + <property name="dataRegionConfigurations"> + <list> + <!-- + Defining a persistent data region with Segmented LRU page replacement mode. + --> + <bean class="org.apache.ignite.configuration.DataRegionConfiguration"> + <!-- Data region name. --> + <property name="name" value="persistent_data_region"/> + + <!-- Enable persistence. --> + <property name="persistenceEnabled" value="true"/> + + <!-- 20 GB maximum size (RAM). --> + <property name="maxSize" value="#{20L * 1024 * 1024 * 1024}"/> + + <!-- Enabling SEGMENTED_LRU page replacement for this region. --> + <property name="pageReplacementMode" value="SEGMENTED_LRU"/> + </bean> + </list> + </property> + </bean> + </property> + + <!-- The rest of the configuration. --> +</bean> +---- +tab:Java[] +[source,java] +---- +include::{javaCodeDir}/ReplacementPolicies.java[tag=segmentedLRU,indent=0] +---- +tab:C#/.NET[unsupported] +---- +tab:C++[unsupported] +-- + +The choice of the algorithm depends on your workload. For most cases, CLOCK (default) is a good candidate, but on some workloads other algorithms can perform better. + +== Random-LRU algorithm + +Every time page is accessed, its timestamp gets updated. When a page fault occurs and it's required to replace some pages, the algorithm randomly chooses 5 pages from the page memory and evicts a page with the latest timestamp. + +This algorithm has zero maintenance cost, but not very effective in terms of finding the next page to replace. Recommended to use in environments, where there are no page replacements (large enough data region to store all amount of data) or page replacements are rare. + +== Segmented-LRU algorithm + +Segmented-LRU algorithm is a scan-resistant variation of the Least Recently Used (LRU) algorithm. Segmented-LRU pages list is divided into two segments, a probationary segment, and a protected segment. Pages in each segment are ordered from the least to the most recently accessed. New pages are added to the most recently accessed end (tail) of the probationary segment. Existing pages are removed from wherever they currently reside and added to the most recently accessed end of the protected segment. Pages in the protected segment have thus been accessed at least twice. The protected segment is finite, so migration of a page from the probationary segment to the protected segment may force the migration of the LRU page in the protected segment to the most recently used end of the probationary segment, giving this page another chance to be accessed before being replaced. Page to replace is polled from the least recently accessed end (head) of the probationary segment. + +This algorithm requires additional memory to store pages list and need to update this list on each page access, but have near to optimal page to replace selection policy. So, there can be a little performance drop for environments without page replacement (compared to random-LRU and CLOCK), but for environments with a high rate of page replacement and a large amount of one-time scans segmented-LRU can outperform random-LRU and CLOCK. Review comment: ```suggestion This algorithm requires additional memory to store pages list that also needs to be updated on each page access. At the same time, the algorithm has a near-optimal page to replace selection policy. So, there can be a little performance drop for environments without page replacement (compared to random-LRU and CLOCK), but for environments with a high rate of page replacement and a large amount of one-time scans segmented-LRU can outperform random-LRU and CLOCK. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
