The preceding sections explain how to calculate the total memory required for storing the database content and indexes. You must also account for the database process itself, which runs within the Java heap. Calculating the memory required by the sever process both helps you define the total memory needed for planning purposes but also identifies the Java heap size that you will need to set in production when starting the database.
It is impossible to define an exact formula for the optimal heap size. But the following basic guidelines can be used to accommodate differing hardware configurations and database designs.
The database features that have the most direct impact on the server process and, therefore, the Java heap requirements are:
Schema size, in terms of number tables and stored procedures
The number of sites per host
The features in use, specifically K-safety and/or database replication
The schema size affects the base requirements for the server process. The more tables the schema has and the more stored procedures it contains, the more heap space it will take up. In particular, it is important to provide enough heap so the schema can be updated, no matter what other features are enabled.
The general rule of thumb is a base Java heap size of 384MB, plus 10MB for every table in the schema. Stored procedures don't impact the heap size as much as the number of tables do. However, if you have lots of stored procedures (that is, hundreds or thousands of them) it is a good idea to add additional space to the base heap size for good measure.
Beyond the base heap size, use of K-safety and database replication each increases the requirements for Java heap space, with the increase proportional to the number of sites per host. In general each feature requires an additional 128MB for every site per host.
For example, a K-safe cluster with 4 sites per host requires an additional 512MB, while a K-safe cluster with 8 sites per host requires an extra gigabyte. If that cluster is also in an XDCR relationship, those extra heap requirements are doubled to 1GB and 2GB, respectively.
Note that the Java heap requirements for features are based solely on the sites per host, not the number of nodes in the cluster or the K-safety value. Any K-safety value greater than zero has the same requirements, in terms of the server process requirements.
The recommended method for determining the appropriate heap size for a VoltDB cluster node is the following:
Calculate the base Java heap requirement using the following formula:
384MB + (10MB X number of tables) = base Java heap size
Be sure to allow for growth if you expect to add tables in the future. Also, if you expect to have large numbers of stored procedures (200 or more), increment the base heap size accordingly. Note that where memory is available, additional Java heap space beyond the minimum settings may provide performance benefits during operational events, such as schema updates and node rejoins.
Based on the hardware to be used in production (specifically cores per server), and performance testing of the proposed schema, determine the optimal number of sites per host. 8 sites per host is the default. Setting the sites per host greater than 24 is not recommended.
Determine which database features will be used in production. K-safety, network partition detection, and command logging are recommended for all production environments. Database replication (DR) is an optional feature that provides additional durability.
If K-safety is in use, but DR is not, multiply the number of sites per host by 128MB to determine the feature-specific Java heap requirements. If K-safety is enabled and the cluster is performing database replication (DR}, multiply the number of sites per host by 256MB.
Add the base Java heap requirements defined in Step #1 to the feature-specific requirements in Step #3 to determine the recommended Java heap size for the production servers.
Documentation