Monitoring and Performance

You can set the maximum memory available to a JVM process with the -Xmx flag to java (or to bin/transactor). The more memory you give a process, the more database indexes it will be able to cache locally in memory, avoiding trips to Memcached or storage.

Memcached is a great fit for Datomic. Read more about configuring Memcached in the caching documentation.

Memcached can deliver data to peers with very low latency (on the order of 1 millisecond for a segment). If you can fit your entire database (or even the commonly-used working set) in Memcached, your read and query performance will be quite good.

Diagnostic: if your [Memcache] average is substantially less than 1.0, then you can serve more reads from Memcache by increasing the size of your memcached cluster.

Datomic reads and queries are horizontally scalable. If you can't serve as many simultaneous queries as you like, add more peers.

Datomic's entire public API is threadsafe and is designed to automatically take advantage of multiple cores where available. Having more cores will help any Datomic process, transactor, or peer.

The memory database is a convenience for development, testing, and temp data. Memory is not good for storage-sized datasets, as memory isn't storage-sized.

Check the DynamoDB section of capacity planning.

Restoring a database consumes significantly less write capacity than building the database via transactions. So if your target system has metered storage pricing (e.g. DynamoDB), it may make sense to do large import jobs on less expensive storage, backup, and then restore to the target storage.

The speed with which a Datomic transactor can write data is measured with the [TransactionMsec] metric. The minimum, average, and maximum values of this metric, combined with the size of your transactions, characterize the write latency of the system from the transactor's perspective. (To measure write latency from a peer or client's perspective, instrument your code to measure the time from when transact is called until the transaction future is realized).

The [TransactionBytes] samples metric, again combined with the size of your transactions characterize the write throughput of the system. Note that to achieve maximum throughput you will need to pipeline transactions, i.e. arrange to have multiple transactions in flight at the same time.

Register the callback for the transactor in the properties file:

metrics-callback=my.ns/handler

Register the callback for the peer with the command line argument:

-Ddatomic.metricsCallback=my.ns/handler

Java callbacks must be static public methods, taking a single Object argument, named as my.pkg.CallbackClass.handler, e.g.

metrics-callback=my.pkg.CallbackClass.handler

Clojure callbacks must be functions that can take a single argument, named as my.ns/handler, e.g.

metrics-callback=my.ns/handler

The callback argument format is alpha and is subject to change. Currently, the argument is a map with keyword keys and either number or map values. If the value is itself a map, it will contain :lo, :hi, :sum, and :count components, all with numeric values.

The example below shows :HeartbeatMsec with a map value, and :AvailableMB with a numeric value:

{:HeartbeatMsec {:lo 5000, :hi 5001, :sum 55009, :count 11}, :AvailableMB 921.0}

The metrics are the same as those reported to CloudWatch. Note that the set of metrics is dynamic, open, and subject to change over time. A correct callback implementation should be tolerant of:

• Metric names it has never seen before
• Metric values in either of the shapes documented above, regardless of what shapes it has seen previously

The Datomic Pro transactor can create at least the following CloudWatch metrics, and may create others as well:

If you're analyzing metrics through your own custom callback, or manually calculating statistics from the log, you may need to take additional steps to interpret metrics. The most common case is producing your average by dividing a sum value for a metric by its count value.

If you're looking at memcache metrics outside of AWS, you would interpret it as follows:

• count is the number of requests to Memcached
• sum is the total number of hits
• You would manually calculate misses as count minus sum
• You would manually calculate your hit rate as sum divided by count, producing, e.g., a value like 0.95