Open topic with navigation
For a given database, hosting each transaction engine and storage manager on a separate machine typically gives better performance despite the added network latency. You should benchmark both configurations (TE and SM on same system and on different systems). For an overview of NuoDB architecture, see NuoDB At a Glance.
Give NuoDB processes as much memory as possible (see
mem Database option), but do not set the
mem option so high that swapping occurs.
Please note that NuoDB may use about 30% more memory than specified in the --mem option. For read-heavy workloads, give the TE more memory than the SM if RAM is limited.
For a storage manager, the
journal-sync-method database option specifies the file system synchronization mechanism 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.