ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: PageMemory approach for Ignite 2.0
Date Wed, 04 Jan 2017 11:13:34 GMT
Agree with Dmitriy. We should avoid having multiple implementations of the
same thing if possible. Lets put our efforts on fixing issues with
PageMemory.

Sergi

2017-01-03 20:11 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Vova,
>
> I would qualify the need for PageMemory as strategic for Apache Ignite.
> With addition of SQL Grid component, Ignite can now also satisfy in-memory
> database use cases, which are very space consuming and require a new memory
> management approach. Basic distributed hash map is not going to work for
> such use cases.
>
> Once PageMemory becomes stable and fast, I don't believe we can afford to
> maintain two types of memory management in the project. It will be just too
> time consuming. On top of that, the old approach will simply not be needed
> anymore.
>
> I am OK with maintaining 2 implementations, assuming we can have a good
> abstraction for the memory management.However, even in that case, we should
> all weigh whether it makes sense to spend time on migrating the current
> on-heap implementation to use these new memory APIs.
>
> D.
>
> On Sun, Jan 1, 2017 at 10:47 PM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Dima,
> >
> > Performance is a serious concern, but not the main one. My point is that
> > standard users working on commodity hardware and requiring only in-memory
> > mode simply do not need page memory. They need distributed HashMap. We
> > already have it. It is fast, it is stable, it have been tested rigorously
> > for years. It does what users need.
> >
> > PageMemory approach targets high-end deployments which is hardly
> represents
> > majority of our users. Less than 10% I think. Or may be <5%, or even <1%.
> > This is who may benefit from page memory. Others will benefit nothing
> > except of additional layer of indirection, drop in performance, risks of
> > instability. And problems with capacity planning, because it is much
> harder
> > to plan two memory regions properly than a single one.
> >
> > I talked to Alexey Goncharuk some time ago, and he told it is not a big
> > deal to abstract out PageMemory. Alex, please confirm. I encourage
> everyone
> > to stop thinking of dropping "old" before you have built "new" and
> > confirmed that it is better.
> >
> > Let's ensure that new approach is well-abstracted, add it to 2.0, let it
> > maturate for 1-2 years, and then think of dropping current approach in
> 3.0.
> > This sounds much better to me.
> >
> >
> > On Sun, Jan 1, 2017 at 10:42 AM, Denis Magda <dmagda@apache.org> wrote:
> >
> > > Sorry, just recalled that Unsafe is not JNI based. However, my previous
> > > point of view still remains the same.
> > >
> > > > On Dec 31, 2016, at 11:39 PM, Denis Magda <dmagda@apache.org> wrote:
> > > >
> > > > JNI-based Unsafe that also brings performance hit
> > >
> > > —
> > > Denis
> > >
> > >
> >
>

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