Re: ChronicleMap and memory efficiency vs CHM

[Peter Lawrey]

You are right that the mileage can vary *a lot* based on the size of the entry and how you do the serialization.

We offer a number of modes of use and we benchmark the fastest option as this is not only a bigger number but the situation where most of the time is spent in the Chronicle Map code rather than the serialization / deserialization. Ie it is the map we are benchmarking.

The most compact option is to use an LZW compressed Externalizable or our BytesMarshallable serialized object. Depending on the size and structure of the object you could get a 1/18 th the size with this option but you can get a range of sizes between 1/100 to worse than not compressing.  Eg the content of your data matters when using compression.
As LZW is expensive we support Snappy and no compression as well. Snappy compression is much faster but uses more space than LZW.
For one use case we examined large String values where using Chronicle Map alone halved the size of the String mostly due to UTF-8 encoding, Snappy was 1/10 th the size and LZW was better than 1/20 th the size of ConcurrentHashMap storing the same Strings. If you serialize an object you get different results as Snappy is optimised for compressing text fast. AFAIK.

Finally the fastest option is avoid serialization entirely and use a direct reference into off heap memory. This allows you access into native memory like a reference to a struct in C++ for a Java Bean (which we generate the code from an interface of getters and setters you provide) or you can hand craft the code to do this from our generated code.

As the Map is concurrent, we use multiple threads in our benchmarks. The benchmark was run on a machine with 16 cores and hyperthreading so we had 32 threads.
The table is a bit old and we get a little over 1 million updates/sec/thread when all the cpus are busy. We get about double that with just one thread running.

It is worth remembering that ChronicleMap supports persistence, ultra fast restart, data sizes larger than main memory with notional on heap foot print, and LAN/WAN replication. (The WAN replication allows you to control the amount of network bandwidth you utilise)

If you use chronicle for more than just a replacement for an on heap data structure it can be a more compelling option.

Regards,
Peter.

On 18 Apr 2015 12:06 am, "Kevin Burton" <burto...@gmail.com> wrote:

I'm considering porting ActiveMQ's memory store to ChronicleMap to get tighter in-memory representation and fewer GC pauses.

The main motivator is memory.  We're wasting a MASSIVE amount of memory hosting our queue.  I think it's along the order of 150GB of RAM right now but only for a few million objects.  

Chronicle is saying that , in their benchmarks, they're getting 18x memory savings.  

In my experience this is probably realistic.  In-memory data structures in Java can be horribly inefficient.  

(I attached their performance numbers below).

I think the performance tradeoff here is probably realistic.  While we have millions of messages our scheduling throughput is more like 1-2k per second vs the 30M per second below.  (of course my mileage may vary depending on the encoding/decoding performance).

Has anyone tested this in production?

I would post to the chronicle list but I couldn't find one.  If this works I could get this data < 10GB which would be pretty amazing.  

We're planning on scaling a LOT larger so this could easily become 1TB of memory if I'm not careful :-P  .. that would be pricey!

Number of entries	Chronicle* Throughput	Chronicle RSS	HashMap* Throughput	HashMap Worst GC pause	HashMap RSS
10 million	30 Mupd/s	½ GB	155 Mupd/s	2.5 secs	9 GB
50 million	31 Mupd/s	3⅓ GB	120 Mupd/s	6.9 secs	28 GB
250 million	30 Mupd/s	14 GB	114 Mupd/s	17.3 secs	76 GB
1000 million	24 Mupd/s	57 GB	OOME	43 secs	NA
2500 million	23 Mupd/s	126 GB	Did not test	NA	NA

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Burton]

Nice.  This is interesting.  At present, ActiveMQ doesn't support compressing the message headers. It supports compressing the bodies using LZW but not the headers.  In our situation the headers are about 50% of the space of the message.  I've actually thought about just encoding a message entirely as headers since this might actually be more efficient.

I think some of those tuneables might need to be exposed. IE should it use snappy or LZW, etc.  

Can chronicle be used as an LRU?  I couldn't find any documentation on this.  I imagine I could mirror part of the LRU inside the JVM and just keep key pointers but that would still use memory.  ActiveMQ uses LRUs for topics (not sure why).

This would basically mean I could drop in chronicle support by just changing the map constructor and literally using the same classes.  So it would just be some glue.

Would be a big win.  Off heap memory storage and much better compression.  

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Peter Lawrey]

If you needed LRU, you would need to create a Map facade which kept an LRU of the keys on heap while the entries were off heap. Maintaining an strict LRU is not simple to combine with concurrent access.
In the future, we might support a mostly LRU which is not strict but we haven't had any clients ask for it.

Regards,
Peter.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Chronicle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-chronicl...@googlegroups.com.