ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Page eviction for in-memory mode with enabled MVCC
Date Thu, 13 Dec 2018 14:19:22 GMT
Andrey,

We will not be able to cache the whole data set locally, as it potentially
lead to OOME. We will have this only as an option and only for non-SQL
updates. Thus, similar semantics is not possible.

On Thu, Dec 13, 2018 at 4:56 PM Andrey Mashenkov <andrey.mashenkov@gmail.com>
wrote:

> Roman,
>
> We have a ticket to improve repeatable_read mode [1] via caching entries
> locally.
> This should make mvcc transaction repeatable_read semantic similar to
> non-mvcc Txs
> and allow us to implement eviction in correct way.
>
> Another way is to introduce mvcc shared (read) entry locks and evict only
> entries if no one hold any lock on it,
> but this looks tricky and error prone as your first one as it may lead to
> eviction policy unexpected behavior,
> e.g some versions can be visible while others - no (evicted).
>
> [1] https://issues.apache.org/jira/browse/IGNITE-7371
>
> On Thu, Dec 13, 2018 at 4:34 PM Ilya Kasnacheev <ilya.kasnacheev@gmail.com
> >
> wrote:
>
> > Hello!
> >
> > Is it possible to 'touch' entries read by MVCC transactions to ensure
> that
> > they are considered recent and therefore are almost never targeted by
> > eviction?
> >
> > This is 1) with benefits.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 13 дек. 2018 г. в 16:22, Roman Kondakov <kondakov87@mail.ru.invalid
> >:
> >
> > > Hi igniters,
> > >
> > > I need your advice with the following issue. When in-memory cache
> > > reaches it's memory limit, some data may be purged to avoid OOM error.
> > > This process is described in [1]. For MVCC caches this eviction may
> > > break repeatable read semantics. For example, if transaction reads key
> > > before eviction, this key is visible for it. But if key is evicted some
> > > time later, this key become invisible to anyone, including our
> > > transaction, which means broken repeatable read semantics.
> > >
> > > Now we see the following solutions of this problem:
> > >
> > > 1. Ignore broken repeatable read semantics. If cache is set to allow
> > > data eviction, it may lose it's data. This means that there is no
> > > valuable information stored in cache and occasional repeatable read
> > > violations can be tolerated.
> > >
> > > 2. Prohibit eviction of MVCC caches at all. For example, stop writing
> to
> > > caches and throw an appropriate exception in the case when there is no
> > > free space in page memory. Before this exception Ignite should do it's
> > > best to avoid this situation, for example, evict all non-mvcc caches
> and
> > > run full vacuum to free as much space as possible.
> > >
> > > First approach is bad because it leads to cache consistency violation.
> > > Second approach is bad because it's behavior may be unexpected to user
> > > if he has set an eviction policy for cache, but instead of eviction
> > > Ignite trying to avoid it as much as possible.
> > >
> > > IMO first approach looks better - it is much simpler to implement and
> > > met user expectations in all points except possible repeatable read
> > > violations.
> > >
> > > What do you think?
> > >
> > >
> > > [1] https://apacheignite.readme.io/docs/evictions
> > >
> > > --
> > > Kind Regards
> > > Roman Kondakov
> > >
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message