Documentation

5.3. How VoltDB Manages Memory

To manage memory effectively, VoltDB does not immediately release all unused memory. Allocating and deallocating small
chunks of memory frequently can be expensive. Instead, VoltDB manages unused memory until larger chunks are available.
Similarly, the Java runtime and the operating system perform their own memory pooling techniques.

As a result, RSS is not an exact measurement of actual memory usage. However, VoltDB offers statistics that provide a
detailed breakdown of how it is using the memory that it has currently allocated. These statistics provide a more meaningful
representation of VoltDB's memory usage than the lump sum allocation reported by the operating system RSS.

VoltDB manages memory for persistent and semi-persistent storage aggressively to ensure unused space is compacted and
released when available. In some cases, memory is returned to the operating system, making the RSS more responsive to
changes in the database contents. In other cases, where memory is managed as a pool of resources, VoltDB provides detailed
statistics on what memory is allocated and what is actually in use.

Persistent storage for database tables (tuples) and indexes is compacted when fragmentation reaches a set percentage
of total memory. Compaction eliminates fragmentation and allows memory to be returned to the operating system as the
database volume changes. At the same time, storage for variable data such as strings and varbinary data greater than 63
bytes in length is being managed as a pool of resources. Free memory in the pool is not immediately returned to the
operating system. VoltDB holds and reuses memory that is allocated but unused for these objects.

The consequence of these changes is that when you delete rows, the allocated memory for VoltDB (as shown by RSS) may
go up during the delete operation (to allow for the undo buffer), but then it will go down — by differing amounts
— based on the type of content that is deleted. Memory for tuples not containing large strings or binary data is
returned to the operating system quickly. Memory for large string and binary data is not returned but is held for later
reuse.

In other words, the pool size for non-inline string and binary data tends to reach a maximum size (based on the
maximum required for your application workload) and then stabilize. Whereas memory for indexes as well as numeric and short
string data oscillates as your application needs vary.

To help you understand these changes, the @Statistics system procedure tells you how much memory VoltDB is using and
how much unused memory is being held for each type of content. These statistics provide a more accurate view of actual
memory usage than the lump sum value of system RSS.