ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: delete is too slow, sometimes even causes OOM
Date Mon, 09 Nov 2020 16:27:35 GMT
Frank,

The ticket doesn't suggest the lazy flag as a workaround. The flag is
supposed to be used to address the performance issue.

How about a workaround on your application side while you're waiting for
this improvement?

   - Query all the records for a deletion - "SELECT record_primary_key
   WHERE delete_condition"
   - Delete the records using the key-value API -
   cache.removeAll(all_primary_keys).

-
Denis


On Mon, Nov 9, 2020 at 8:20 AM frank li <frankli22568@gmail.com> wrote:

> I enforced  a lazy flag in DELETE code for tesing, but it is stil running
> very slow. I mean that "Lazy" flag cannot solve the problem of running too
> slow.
>
> On 2020/11/06 09:50:15, Юрий <jury.gerzhedowich@gmail.com> wrote:
> > Hi Frank!
> >
> > There is an old ticket [1] - We will try to prioritize it to finish
> before
> > the end of the year it should prevent OOM for most cases.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9182
> >
> > вт, 3 нояб. 2020 г. в 18:53, frank li <frankli22568@gmail.com>:
> >
> > > Current code logic for DELETE is as follows:
> > > if WHERE clause contains a condition as "key=xxx", it uses fastUpdate
> > > which remove the related item directly.
> > >
> > > else
> > >     do select for update;
> > >     for each row, call closure code "RMV" to remove it.
> > >
> > > 1. As "executeSelectForDml" get _KEY and _VAL columns for all condidate
> > > rows, it often causes OOM when there are a lot of data  to delete. Why
> do
> > > we verify "val" during remove operation?
> > >
> > > 2. After selection,  why don't we just remove it with cache.remove as
> > > fastUpdate does?
> > >
> > >
> > >
> >
> > --
> > Живи с улыбкой! :D
> >
>

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