Off-heap Storage •

Edin Zulich

Agenda• Motivation and goals for off-heap storage• Off-heap features and usage• Implementation overview• Preliminary benchmarks: off-heap vs. heap• Tips and best practices• Future Directions

Motivation and goals for off-heap storage

Why Off-heap

• • Increase data density and reduce memory overhead

• 128+ GB user data in one JVM

• 10+ TB user data in one cluster

• Usable out-of-box without extensive GC tuning of JVM

• Maintain existing throughput performance

Off-heap Usage and Features

Off-heap: How Do I Use It?

• Set the off-heap memory size for the process– Using the new property: off-heap-memory-size

• Mark regions whose entry values should be stored off-heap

– Using the new region attribute: off-heap (false | true)• Adjust the JVM heap memory size down accordingly

– The smaller the better; at least try to keep it below 32G• Optionally

– Configure Resource Manager– Lock the off-heap memory

Off-heap Features

• Startup options

• Interaction with other features

• Resource Manager

• Monitoring & Management

• Limitations

Startup Options

• --off-heap-memory-size specifies amount of off-heap memory to allocate

• --lock-memory specifies whether to lock the off-heap memory

• Example:

gfsh start server –initial-heap=10G –max-heap=10G –off-heap-memory-size=200G –lock-memory=true

Off-heap Interaction with Other Features

• Deltas: values have to be copied (the clone option is ON, and cannot be turned off)

• EntryEvents– Limited availability of oldValue, newValue

• Indexes– Functional range indexes not supported (too expensive)

• Region operations that compare the value do not call object equals, but either PDXInstance or serialized bytes– In order to do equality check without having to deserialize

data

More Expensive with Off-heap

• PDX– Values currently copied from off-heap to create a

PDXInstance• Deltas: to apply a delta you have to

serialize/deserialize every time• Compression: there is an extra copy on

decompression• Querying: deserialize on every query

Off-heap and Resource Manager

• Out of Memory Semantics

• Eviction and Critical Thresholds

• Resource Manager API

“Out of Memory” Occurs When...

• Java heap runs out of memory– Threads start throwing OutOfMemoryError

• Off-heap runs out of memory– Threads start throwing OutOfOffHeapMemoryException

• => causing the Geode member to close and disconnect

– Closes the Cache to prevent reading inconsistent data– Disconnects from the Geode cluster to prevent distribution

problems or hangs

Eviction and Critical Thresholds for Off-heap

• CriticalOffHeapPercentage– triggers LowMemoryException for puts into off-heap

regions– critical member informs other members that it is critical

• EvictionOffHeapPercentage– triggers eviction of entries in off-heap regions configured

with LRU_HEAP• Semantics the same as with the equivalent heap

thresholds

Startup Options

• Existing:• -critical-heap-percentage• -eviction-heap-percentage

• New:• -critical-off-heap-percentage• -eviction-off-heap-percentage

• Example:start server –initial-heap=10G –max-heap=10G –off-heap-memory-size=200G –lock-memory=true –critical-off-heap-percentage=99

ResourceManager API

• GemFireCache#getResourceManager()• com.gemstone.gemfire.cache.control.ResourceMana

ger– exposes getters/setters for all of the heap and off-heap

threshold percentages– Examples:

▪ public void setCriticalOffHeapPercentage(float offHeapPercentage);▪ public float getCriticalOffHeapPercentage();

Monitoring & Management

• Statistics

• Mbeans

• gfsh

Statisticsname descriptiondefragmentations The total number of times off-heap memory has been defragmented.defragmentationTime

The total time spent defragmenting off-heap memory.

fragmentation The percentage of off-heap memory fragmentation. Updated every time a defragmentation is performed.

fragments The number of fragments of free off-heap memory. Updated every time a defragmentation is done.

freeMemory The amount of off-heap memory, in bytes, that is not being used.largestFragment The largest fragment of memory found by the last compaction of off heap memory.

Updated every time a defragmentation is done.maxMemory The maximum amount of off-heap memory, in bytes. This is the amount of memory

allocated at startup and does not change.objects The number of objects stored in off-heap memory.reads The total number of reads of off-heap memory.usedMemory The amount of off-heap memory, in bytes, that is being used to store data.

MBeansMemberMXBeangetOffHeapDefragmentationTime -- provides the value of the defragmentationTime statisticgetOffHeapFragmentation -- provides the value of the fragmentation statisticgetOffHeapFreeMemory -- provides the value of the freeMemory statisticgetOffHeapObjects -- provides the value of the objects statistic

getOffHeapUsedMemory -- provides the value of the usedMemory statisticgetOffHeapMaxMemory -- provides the value of freeMemory + usedMemory

RegionMXBeanlistRegionAttributes (operation)

enableOffHeapMemory (true | false)

Gfsh Support for Off-heap Memory

• alter disk-store: new option "--off-heap" for setting off-heap for each region in the disk-store

• create region: new option "--off-heap" for setting off-heap• describe member: now displays the off-heap size• describe offline-disk-store: now shows if a region is off-

heap• describe region: now displays the off-heap region attribute• show metrics: Now has an offheap category. The offheap

metrics are: maxMemory, freeMemory, usedMemory, objects, fragmentation, and defragmentationTime

• start server: added --lock-memory, --off-heap-memory-size, --critical-off-heap-percentage, and --eviction-off-heap-percentage

Off-heap Limitations

• Maximum object size limited to slightly less than 2 GB

• All data nodes must consistently configure a region to be off-heap

• Functional Range Indexes not supported• Keys, subscription queue entries not stored off-heap• Fragmentation statistic is only updated during off-

heap compactions

Implementation Overview

Off-heap: How are We Doing It?

• Using memory that is separate from the Java heap– Built our own Memory Manager– Memory Manager is very finely tuned and specific to our

usage– Avoid GC overhead

▪ Avoid copying of objects for promotion between generations▪ Garbage Collector is a major performance killer

– Use sun.misc.Unsafe API for performance• Optimizing code to minimize usage of heap memory• Using off-heap as primary store instead of

overflowing to it

Off-heapMemory

Management

Off-heap Implementation

• Memory allocated in 2GB slabs– Max data value size: ~2GB– Object values stored serialized; blobs stored as byte arrays– Allocation faster for values < 128KB

▪ Controlled by a system property: gemfire.OFF_HEAP_FREE_LIST_COUNT

▪ First try to allocate from the free list; if that fails, allocate from unused memory

▪ Small values (< 8B) inlined (not using any off-heap space)

• Defragmentation consolidates free memory to minimize fragmentation

– Blocks writes; best to avoid by minimizing fragmentation

Off-heap Implementation (cont’d)

• Allocated chunks– Header

▪ isSerialized▪ isCompressed▪ Size▪ Padding size

• Free chunks– Header

▪ Size▪ Address of next chunk in the list

What is Stored On-heap vs. Off-heap

Always Stored On-heap Stored Off-heapRegion Meta-Data ValuesEntry Meta-Data Reference Counts - Off-Heap Addresses Lists of Free Memory BlocksKeys WAN Queue ElementsIndexesSubscription Queue Elements

Preliminary Benchmarks: Off-heap

vs. Heap

Off-heap: Initial Testing Results

• 256 GB user data per node across 8 nodes for total of 2 TB of user data

• Heap-only test worked twice as hard to produce 1/3 the updates as test using Off-Heap

– Details on the next slide• Succeeded in scaling up to much larger in-memory

data• Increased throughput of operations for large data

sets

Heap vs. Off-Heap Comparison

Java Heap Off-Heapcreates/sec 30,000 45,000updates/sec 17,000 (std dev: 2130) 51,000 (std dev: 737)

Java RSS size 50 GB 32 GBCPU load 70% (load avg 10

cpus)32% (load avg 5 cpus)

JVM GC ConcurrentMarkSweep ConcurrentMarkSweepGC ms/sec 777 ms 24 msGC marks (GC pauses) 1 per 30 sec never

Recommendations and Best Practices

Off-heap Rules of Thumb

• Try to minimize fragmentation– In order to avoid defragmentation– Beware of usage patterns that lead to fragmentation

▪ Many updates of varying value size▪ Use cases that require a lot of serialization/deserialization

• Beware of more expensive features– Deltas– Querying– Compression– PDX

Off-heap Recommendations

• Recommended when– The values are relatively uniform in size– The values are mostly less than 128K in size (configurable)– The usage patterns involve cycles of many creates followed

by destroys or clear– The values do not need to be frequently deserialized

• Configure all data nodes with the same off-heap-memory-size

Future

How about...

• Storing keys, indexes, subscription queues off-heap?• An API to invoke a defragmentation?• A way to configure the slab size?• A way to configure the max value size for the most

efficient off-heap allocation, or maybe the size increment?

• A different defragmentation algorithm/policy?• Anything else?

Questions?

Feedback Welcome!

Full spec at:

https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Memory+Spec

Join the Apache Geode Community!• Check out: http://geode.incubator.apache.org

• Subscribe: user-subscribe@geode.incubator.apache.org

• Download: http://geode.incubator.apache.org/releases/

Thank You!