Tuning Tips for System Configuration

NuoDB applications, like most CPU, memory, and I/O-intensive applications, benefit from systems with fast, multi-core CPUs, lots of memory, and high-performance I/O subsystems. However, NuoDB is also designed to scale well on a network of modest computers. In general, server class machines that each have one or two sockets provide good performance at reasonable cost when compared with large multi-socket machines.

As a distributed database, NuoDB heavily uses TCP/IP networking. Transaction Engines (TEs) and Storage Managers (SMs) in the same region benefit from a high-speed, low-latency network such as 10 Gigabit Ethernet.

Machines that run TEs do not require storage for the database so there is no need for high-performance storage on TE hosts.

Machines that run SMs should have two persistent storage devices — one for the archive and one for the journal. Locate the journal on the highest-performing I/O device, preferably a PCI Express SSD. If the journal is located on an SSD, ensure the SSD has TRIM support enabled through the operating system. (For guidelines on Linux see Enable TRIM Support.)

The required size of the journal device depends on many factors including number of inserts and disk performance. In general, it is better to have an oversized device rather than an undersized device. A size of 10 gigabytes is not unreasonable for an insert-heavy workload. Be conservative when setting the size of the device the journal will reside on. If you have an insert-heavy workload then you might need to set it to the size of a substantial fraction (1/3 to 1/2) of the memory available to the host. If you do not have an insert-heavy workload then a journal device with a relatively small hard drive is likely to be sufficient.

Ensure that partitions start on physical sector boundaries.