There is very little penalty for allocating more sites than needed for the partitions the database will use (except for incremental memory usage). Consequently, VoltDB defaults to eight sites per node to provide reasonable performance on most modern system configurations. This default does not normally need to be changed. However, for systems with a large number of available processes (16 or more) or older machines with fewer than 8 processors and limited memory, you may wish to tune the sitesperhost attribute.

The number of sites needed per node is related to the number of processor cores each system has, the optimal number being approximately 3/4 of the number of CPUs reported by the operating system. For example, if you are using a cluster of dual quad-core processors (in other words, 8 cores per node), the optimal number of partitions is likely to be 6 or 7 sites per node.

<?xml version="1.0"?>
<deployment>
   <cluster . . .
            sitesperhost="6"
   />
</deployment>

For systems that support hyperthreading (where the number of physical cores support twice as many threads), the operating system reports twice the number of physical cores. In other words, a dual quad-core system would report 16 virtual CPUs. However, each partition is not quite as efficient as on non- hyperthreading systems. So the optimal number of sites is more likely to be between 10 and 12 per node in this situation.

Because there are no hard and set rules, the optimal number of sites per node is best calculated by actually benchmarking the application to see what combination of cores and sites produces the best results. However, it is important to remember that all nodes in the cluster will use the same number of sites. So the best performance is achieved by using a cluster with all nodes having the same physical architecture (i.e. cores).

An important aspect of some runtime features is that they make use of disk resources for persistent storage across sessions. For example, automatic snapshots need a directory for storing snapshots of the database contents. Similarly, export uses disk storage for writing overflow data if the export connector cannot keep up with the export queue.

You can specify individual paths for each feature, or you can specify a root directory where VoltDB will create subfolders for each feature as needed. If you do not specify a root path or a specific feature path, the root path defaults to ./voltdbroot in the current default directory and VoltDB creates the directory (and subfolders) as needed.

To specify a common root, use the <voltdbroot> tag (as a child of <paths>) to specify where VoltDB will store disk files. If you specify a root directory path, the directory must exist and the process running VoltDB must have write access to it. VoltDB does not attempt to create an explicitly named root directory path if it does not exist. For example, the following <paths> tag specifies /opt/voltdb as the root directory:

<paths>
   <voltdbroot path="/opt/voltdb" />
</paths>

You can also identify specific path locations for individual features including:

If you name a specific feature path and it does not exist, VoltDB will attempt to create it for you. For example, the <exportoverflow> path contains temporary data which can be deleted periodically. The following excerpt from a deployment file specifies /opt/voltdb as the default root but /opt/overflow as the directory for export overflow.

<paths>
   <voltdbroot path="/opt/voltdb" />
   <exportoverflow path="/opt/overflow" />
</paths>

The deployment file defines the expected configuration of your database cluster. However, there are several important aspects of the physical hardware and operating system configuration that you should be aware of before running VoltDB: