Open topic with navigation
For a given database, hosting each Transaction Engine (TE) and Storage Manager (SM) on a separate machine typically gives better performance despite the added network latency. You should benchmark both configurations, comparing the TE and the SM on same system versus having each and on a separate). For an overview of NuoDB architecture, see NuoDB At a Glance.
Set NuoDB processes to have as much memory as possible (see
mem Database option), but do not set the
mem option so high that swapping occurs.
For a SM, the
journal-sync-method database option defines the file system synchronization mechanism to be used when the journal needs to ensure the durability of a transaction commit. The synchronization method has been specifically tuned for each supported operating system.
kernelfile system synchronization method is the fastest but requires a battery backed disk controller. The
kernelmechanism on Linux requires support for the
fallocateutility. For example, use the
diskfile system synchronization method is the most durable (but slowest) mechanism.
osyncfile system synchronization method is available for copy-on-write file systems, such as ZFS.
See also: Tuning Tips for Journal Performance.