Hi Guys, I agree with both Val and Dmitriy. Dmitriy is technically correct, but Val is also right that we should clean up the language.
Here’s what I mean by "cleaning up the language": unless I’m missing something, eviction policy has no effect when Ignite persistence is enabled, because Ignite will adaptively page-in and page-out memory to disk in a fashion very similar to how modern operating systems handle virtual memory. Using an explicitly configured eviction policy really only matters if you’re using 3rd party persistence (such as write-behind to an RDBMS). So basically, there are two different use cases: Case #1: Native Persistence is On: eviction policy is meaningless because paging is handled automatically by Ignite. The actual algorithm used by Ignite doesn’t matter—so long as it works—because in this case Ignite is a magical black box that handles paging for you and you can’t configure it. Case #2: Native Persistence is Off: in this case, users have to decide how to deal with out-of-memory situations by specifying their own eviction policy. Ignite will not magically page to disk and so users need to configure eviction. When configuring eviction, they have several configuration options. So, in my mind, that documentation page needs to have a very clear sentence in its first paragraph that says something like “look, all of the stuff on this page only matters if you don’t have persistence enabled.” Just my two cents… Take care, Lucas -- Lucas BEELER Technical Consultant, Professional Services GridGain Systems www.gridgain.com > On Feb 2, 2018, at 4:01 AM, Dmitry Pavlov <dpavlov....@gmail.com> wrote: > > Hi Val, > > I think it is quite accurate because eviction in case PDS enabled or not > has quite different purposes. > > 1. Let us consider PDS enabled and page eviction occurs. First of all it is > page based eviction, but not entry-based. Actually data is not removed, but > only written to disk. We can address this page later by ID. > PDS eviction is primarily the replacement of pages from memory to page on > disk. This eviction policy should ensure the maximum performance of the > solution in the future. There is no data removal from grid in this case. > And Ignite does not allow users to configure the policy. If benchmarks show > that a change in policy results in increased performance, then we can > switch policy. > > 2. Entry-based eviction (if there is no persistence is available) is > slithly different. User will need to reload data into grid in case entry is > evicted but required in cache. In that case Ignite provides selection of > policies. > > Sincerely, > Dmirtiy Pavlov > > > > чт, 1 февр. 2018 г. в 22:24, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> Guys, >> >> Thanks for responses. But I still fail to understand how it affects a user. >> >> Are you saying that with persistence enabled Random-LRU is always used >> regardless of what is specified in pageEvictionMode, while in in-memory >> only scenario we can also utilize Random-2-LRU for eviction? Is this >> accurate? Are there any other differences? >> >> -Val >> >> On Thu, Feb 1, 2018 at 5:01 AM, Dmitry Pavlov <dpavlov....@gmail.com> >> wrote: >> >>> Hi Vyacheslav, >>> >>> Yes, this is right, but for now PDS page based eviction uses Random-LRU, >>> not Random-2-LRU. Something may be changed in future Ignite releases, but >>> now Random-LRU is used. I am going to research if there is some room for >>> improvements in this aspect (e.g. IGNITE-7507 recenly found). >>> >>> If clean page is evicted, nothing really happends. If dirty page is >> evicted >>> from region during checkpointing process run, page is stored in file >> before >>> eviction >>> >>> Some info about this can be found in >>> https://cwiki.apache.org/confluence/display/IGNITE/ >>> Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory- >>> underthehood-Pagebasedeviction >>> >>> Sincerely, >>> Dmitriy Pavlov >>> >>> чт, 1 февр. 2018 г. в 9:53, Vyacheslav Daradur <daradu...@gmail.com>: >>> >>>> Hi Valentin, >>>> >>>> As far as I know, when persistence is enabled and Ignite can't >>>> allocate new page-memory in the memory segment, then Ignite >>>> automatically evict some data from RAM to PDS using Random-2-LRU >>>> eviction algorithm. And there are no mechanisms to evict entries out >>>> when PDS is enabled. >>>> >>>> I'll be glad if I am not right and someone will correct me because, as >>>> Ignite user, I can't use PDS only as RAM disk replication for the use >>>> case in my project. >>>> >>>> >>>> On Thu, Feb 1, 2018 at 3:53 AM, Valentin Kulichenko >>>> <valentin.kuliche...@gmail.com> wrote: >>>>> Folks, >>>>> >>>>> On "Eviction Policies" documentation page [1] we have the following >>>> callout: >>>>> >>>>>> Configured eviction policy has no effect if Ignite persistence is >>>> enabled >>>>>> Note that if Ignite Persistence is enabled, then the page-based >>>> evictions >>>>> have no effect because the oldest pages will be purged from memory >>>>> automatically. >>>>> >>>>> This really confuses me. Why is there a difference in how data is >>> evicted >>>>> from memory depending on having disk enabled or not? And how does >>>> eviction >>>>> work with persistence enabled then? >>>>> >>>>> Does anyone can clarify? >>>>> >>>>> [1] https://apacheignite.readme.io/docs/evictions >>>>> >>>>> -Val >>>> >>>> >>>> >>>> -- >>>> Best Regards, Vyacheslav D. >>>> >>> >>
