ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: SQL Performance indexing performance on-heap vs off-heap
Date Sun, 20 Sep 2015 18:23:27 GMT
Forgot to mention

5. On-heap index snapshots can be reused between threads if nothing changed
in between, for off-heap each thread has to take its own snapshot each
time. This is again due to difficulties in manual memory management.


2015-09-17 13:35 GMT+03:00 Sergi Vladykin <sergi.vladykin@gmail.com>:

> Dmitriy,
> May be this is because you don't know code base well enough? ;)
> Val,
> There are few things I can name right away without any investigation:
> 1. Memory allocation: Unsafe.allocateMemory is inherently not parallel
> while SnapTree after snapshotting switches into Copy-on-Write mode
> which does allocations heavily. In multithreaded ops especially on large
> caches it becomes a bottleneck and you will see it in hot spots easily.
> 2. Memory deallocation: since it is a concurrent data structure with
> manual memory management it is protected by GridUnsafeGuard which is
> implemented as linked queue. I'm not sure if this is the most efficient and
> scalable algorithm, may be it makes sense to revisit it in the future.
> Needless to say that Unsafe.freeMemory has the same scalability issues as
> allocateMemory.
> 3. We have to always deserialize values to access fields (I hope this can
> be improved after new marshaller will be merged).
> 4. Cache value is accessed using swap API.
> Sergi
> Sergi
> 2015-09-17 7:27 GMT+03:00 Alexey Kuznetsov <akuznetsov@gridgain.com>:
>> Igniters,
>> As I understand "javadevmtl" prepared some code.
>> May be someone experienced could run it under java profiler and may be it
>> will give some useful information where is the slowdown?
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com

View raw message