In memory

Intro

You can launch a standalone Warp 10 in an "in memory" mode i.e. without persisting updates on disk as they happen. Optionally though, data can be dumped on disk at shutdown (assuming a clean shutdown of the Warp 10 instance) and reloaded at startup.

The "in memory" mode is CPU and memory bound. It offers more performances especially for the FETCH operation.

The in-memory mode stores the data for each GTS in chunks which cover a certain time period. The total number of chunks for each GTS is defined at configuration time. The most recent chunk covers the current time, which means that no data which should end up in a future chunk will be stored. Also as a chunk become too old (i.e. they are over the chunk count threshold when the most recent chunk changes), they are discarded and their content is no longer available.

Setup

You have to modify etc/conf.d/30-in-memory.conf.conf. See the template for a description of those properties.

For example:

[...]

//
// Directory where the leveldb files should be created
//
leveldb.home = /dev/null

[...]

//
// Set to 'true' to indicate the instance will use memory only for storage. This type of instance is non persistent.
//
in.memory = true

//
// Set to 'true' to use a chunked version of the in memory datastore
// When this datastore is in effect, the depth of data retained is
// configured using in.memory.chunk.count and in.memory.chunk.length
// All other in.memory.* parameters are ignored
//
in.memory.chunked = true

//
// Number of chunks to retain (defaults to 3)
//
in.memory.chunk.count = 2

//
// Length in platform time units of each chunk (defaults to 2**63)
//
in.memory.chunk.length = 86400000000

//
// Path to a dump file containing the state of an in-memory Warp 10 to restore.
//
in.memory.load = ${standalone.home}/data/dump

//
// Path to a dump file in which the current state of an in-memory Warp 10 will be persisted.
//
in.memory.dump = ${standalone.home}/data/dump

[...]