Certain features of your operating system may need to be configured.

For optimal performance, X100 by default allocates a large amount of virtual address space to be able to use it most efficiently when needed. In some circumstances, this amount can be larger than the amount of physical memory.

Some Linux distributions by default disallow reserving unlimited virtual address space. We recommend that you configure your system to allow unlimited allocation of virtual address space unless there are compelling reasons (unrelated to X100) not to.

To check if your system allows unlimited allocation of virtual address space:

should return 1.

should return unlimited.

Issue these commands after every system restart:

To learn how to make this setting persistent, refer to your Linux documentation.

Alternatively, X100 can be configured to not reserve virtual address space by setting the [memory] max_overalloc (see max_overalloc) configuration parameter to 0. This may limit the maximum performance your system can deliver.

Linux: To use the vwload command in parallel mode, /proc/sys/vm/overcommit_memory must be set to 1 or [memory] max_overalloc must be 0.

You may need to increase the max_map_count kernel parameter to avoid running out of map areas for the X100 server process.

To prevent encryption keys stored in memory from being swapped to disk (a security risk), the Linux configuration parameter RLIMIT_MEMLOCK must be properly configured. If set too low, an error will occur when working with encrypted tables. RLIMIT_MEMLOCK defines how much memory an unprivileged process can lock. Locking a memory area protects it from swapping.

To configure this setting properly, use the following calculation: 40 bytes per encrypted table used in a query, rounded up to a full page of 4K (or 8K if overlapping page boundaries) per concurrent query (and only for the duration of the query).

To verify the current setting, as the installation owner user, issue the following command at a shell prompt:

The value of "max locked memory" is the RLIMIT_MEMLOCK value. If it is too small, it can be changed by editing either the limits.conf file or the system-system.conf file, depending on whether your Linux uses systemd. Consult your system administrator for assistance.

To reduce TLB (translation lookaside buffer) misses, modern CPUs offer a feature called "large pages" ("huge pages" on Linux). Large pages allow a page size of 2 MB (on some CPUs even 1 GB) instead of 4 KB. Using a larger page size is especially beneficial when accessing large amounts of memory with a random pattern. X100 supports the use of large pages for certain data structures that would benefit the most.

You must designate an amount of memory for large pages before starting Vector. This memory is used for large page allocations only, not for normal allocations. Because this division of memory is static, you should wisely choose the amount of memory available in large pages.

If you encounter problems with large pages, you can switch it off in the vectorwise.conf file by setting [memory] use_huge_tlb (see use_huge_tlb) to FALSE.

To enable the use of huge pages in Vector the following is needed:

For easier administration of this feature, extra tools are recommended, often found in a package called libhugetlbfs-utils or similar.

The commands and amounts provided here is an example of designating memory for huge pages on Linux. Before issuing these commands, understand what they do, and adapt the examples, as needed. Reserving pages for use in huge page allocations is system wide, so make sure you are not interfering with other users.

To make 2 GB available for 2 MB huge pages, issue the following commands as root on the command line before starting Vector:

To switch off, enter the following command as root on the command line:

To check if memory is allocated for huge pages and how much of it is in use, type at the command line:

The information about huge pages is shown in the following example lines:

Making memory available for huge pages requires defragmenting the specified amount of memory, so it can take a while. Typically, it is fastest to do this immediately after system startup, when memory is not as fragmented.

For more in-depth information, see the man page of hugeadm (https://linux.die.net/man/8/hugeadm) and vm/hugetlbpage.txt (https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt) in the Linux kernel documentation.

Some modern many-core systems trade uniform memory access times with RAM for better scalability. This is known as NUMA (non-uniform memory access).

Consult the documentation for your system and for your operating system to find out if they support NUMA.

X100 provides a set of NUMA optimizations which, under Linux, require libnuma version 2.0.2 or newer. These optimizations are enabled per default when libnuma is detected and the system running X100 is a NUMA system (number of NUMA nodes > 1).

If you encounter problems with the NUMA optimizations, it can be disabled in vectorwise.conf by setting [memory] use_numa (see use_numa) to FALSE.