ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seliverstov Igor <gvvinbl...@gmail.com>
Subject Re: Page eviction for in-memory mode with enabled MVCC
Date Fri, 14 Dec 2018 15:40:01 GMT
Roman,

I would prefer first option.

The fact user uses MVCC says he needs some more strict guaranties which
cannot meet in other modes.
I would rollback both txs in case we cannot provide such guaranties.

Regards,
Igor

пт, 14 дек. 2018 г. в 15:36, Roman Kondakov <kondakov87@mail.ru.invalid>:

> Vladimir,
>
> I was thinking about your proposal to not evict locked and recent (the
> transaction that created the record is still active) entries from the
> cache. Let's imagine next situation: we have almost full memory and two
> transactions:
>
> 1. txA: "SELECT * FOR UPDATE"
>
> 2. txB: "INSERT ...many keys here..."
>
> In this case txA locks all entries in the cache, and therefore we cannot
> evict any of them. If then txB is trying to add a lot of data, it lead
> us to the OOM situation, which user is trying to avoid using cache
> evictions.
>
> I see two ways how to deal with this issue:
>
> 1. Allow OOM in MVCC caches with configured evictions and warn user
> about it in the docs.
>
> 2. Give up with the repeatable read guaranties in case of evictions for
> MVCC caches and warn users about it in the documentation.
>
> Second variant looks better for me because user may not expect OOM when
> he has configured eviction policy for cache.
>
> What do you think?
>
>
> --
> Kind Regards
> Roman Kondakov
>
> On 13.12.2018 22:33, Vladimir Ozerov wrote:
> > It's hard to believe that entries are not locked on backups, because we
> > wrtite data right away. Even if it so, it should be very easy to fix -
> just
> > do not evict and entry if it was created or deleted by currently active
> > transaction.
> >
> > On Thu, Dec 13, 2018 at 10:28 PM Roman Kondakov
> <kondakov87@mail.ru.invalid>
> > wrote:
> >
> >> Vladimir,
> >>
> >> we do not lock entries on backups when MVCC is enabled and therefore we
> >> don't avoid entry eviction from backup by locking. So, your first
> >> scenario with primary stop is still relevant.
> >>
> >>
> >> --
> >> Kind Regards
> >> Roman Kondakov
> >>
> >> On 13.12.2018 22:14, Vladimir Ozerov wrote:
> >>> No, I mean that we should think about what kind of guarantees it
> >> possible.
> >>> My proposal was to prevent evictions of locked entries. This way we can
> >> say
> >>> users: "if you want true REPEATABLE_READ when evictions are enabled,
> then
> >>> make sure to lock entries on every access". This effectively means that
> >> all
> >>> SELECT's should be replaced with "SELECT FOR UPDATE".
> >>>
> >>> On Thu, Dec 13, 2018 at 10:09 PM Roman Kondakov
> >> <kondakov87@mail.ru.invalid>
> >>> wrote:
> >>>
> >>>> Vladimir,
> >>>>
> >>>> correct me please if i misunderstood your thought. So, if eviction is
> >>>> not about a consistency at all, we may evict keys in any way because
> >>>> broken repeatable read semantics is not the biggest problem here. But
> we
> >>>> should add some notes about it to user documentation. Right?
> >>>>
> >>>>
> >>>> --
> >>>> Kind Regards
> >>>> Roman Kondakov
> >>>>
> >>>> On 13.12.2018 17:45, Vladimir Ozerov wrote:
> >>>>> Roman,
> >>>>>
> >>>>> I would start with the fact that eviction can never be consistent
> >> unless
> >>>> it
> >>>>> utilizes atomic broadcast protocol, which is not the case for Ignite.
> >> In
> >>>>> Ignite entries on node are evicted independently.
> >>>>>
> >>>>> So you may easily get into situation like this:
> >>>>> 1) Start a cache with 1 backup and FULL_SYNC mode
> >>>>> 2) Put a key to primary node
> >>>>> 3) Stop primary
> >>>>> 4) Try reading from new primary and get null because key was evicted
> >>>>> concurrently
> >>>>>
> >>>>> Or:
> >>>>> 1) Start a transaction in PESSIMISTIC/READ_COMMITTED mode
> >>>>> 2) Read a key, get value
> >>>>> 3) Read the same key again, get null
> >>>>>
> >>>>> So in reality the choice is not between consistent and inconsistent
> >>>>> behavior, but rather about degree of inconsistency. Any solution
is
> >>>>> possible as long as we can explain it to the user. E.g. "do not
> evict a
> >>>> key
> >>>>> if it is either write-locked".
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 13, 2018 at 5:19 PM Vladimir Ozerov <
> vozerov@gridgain.com>
> >>>>> wrote:
> >>>>>
> >>>>>> 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