# System Requirements and Recommendations The following are some requirements and recommendations you should follow when provisioning and setting up your hosts to optimize the performance of your cluster. ## Recommended Hardware The following are additional hardware recommendations for optimal performance. SingleStore strongly recommends running leaf nodes on hosts that have the same hardware and software specifications. | Component | Recommendation | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU** | For each host, an x86\_64 CPU and a minimum of 4 cores (8 vCPUs)SingleStoreis optimized for architectures supporting SSE4.1 and AVX2 instruction set extensions.Refer to Recommended CPU Settings (below) for more information. | | **Memory** | A minimum of 8GB of RAM available for each aggregator nodeA minimum of 64GB of RAM available for each leaf nodeRefer to[General](https://docs.singlestore.com/db/v9.1/introduction/faqs/general.md)for more information. | | **Storage** | Provide a storage system for each node with at least 3x the capacity of main memory.SSD storage is recommended for columnstore workloads.Both`ext4`and`xfs`filesystems are supported.Refer to[Recommended Storage Settings](https://docs.singlestore.com/#section-idm456952404292963278011261918.md)for more information. | ## Recommended Operating System Settings ## Platform and Kernel Our recommended platforms are: * Red Hat Enterprise Linux (RHEL) / [AlmaLinux](https://almalinux.org/) 7 or later * Debian 8 or 9 (version 9 is preferred) / Ubuntu 14.04 and later CentOS 6, 7, and 8 are supported but are not recommended for new deployments. CentOS 8 has reached [end of life](https://www.centos.org/centos-linux-eol/) and CentOS has discontinued numbered releases. When provisioning your hosts, the minimum Linux kernel version required is 3.10 or later. For SingleStore 8.1 and later, `glibc` 2.17 or later is also required. ## Toolbox Platform and Kernel Checkers The following Toolbox [checkers](https://docs.singlestore.com/db/v9.1/reference/singlestore-tools-reference/sdb-report-commands/check.md) are run prior to deploying SingleStore. Note that the associated [sdb-report collect](https://docs.singlestore.com/db/v9.1/reference/singlestore-tools-reference/sdb-report-commands/collect.md) and [sdb-report check](https://docs.singlestore.com/db/v9.1/reference/singlestore-tools-reference/sdb-report-commands/check.md) Toolbox commands may also be run from the command line. | Host Setting | Checker | Description | Host Configuration | | ------------------------------ | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **cpgroups** | `cgroupDisabled` | Checks if control groups ([cgroups](https://wiki.archlinux.org/title/cgroups)) are disabled | Disabled in non-VM deployments.Run the kernel with the following arguments to disable cgroups:`intel_pstate=disable``cgroup_disable=memory` | | **Defunct (Zombie) Processes** | `defunctProcesses` | Checks if there are[defunct (zombie) processes](https://linuxreviews.org/Defunct_process)on each host | Kill all zombie processes on each host before deployingSingleStore | | **Filesystem Type** | `filesystemType` | Checks if a host’s filesystem can supportSingleStore | `xfs`and`ext4`are supported filesystems | | **Kernel Version** | `kernelVersions` | Checks for[kernel version](https://linuxize.com/post/how-to-check-the-kernel-version-in-linux/)consistency | Kernel versions must be the same for all hosts | | **Linux Out-of-Memory Killer** | `OutOfMemory` | Checks in[dmesg](https://man7.org/linux/man-pages/man1/dmesg.1.html)for invocations of the Linux out-of-memory killer | The Linux out-of-memory killer is not running on any host | | **Major Page Faults** | `majorPageFaults` | Checks the number of[major page faults](https://scoutapm.com/blog/understanding-page-faults-and-memory-swap-in-outs-when-should-you-worry)per second on each host and determines if it’s acceptable | Major page faults per second on each host: | | **Orchestrator Processes** | `orchestratorProcesses` | Checks if any[orchestrator process](https://www.redhat.com/en/topics/automation/what-is-orchestration)is found on any host | Not a requirement nor any action required. The`sdb-report`command will simply notify if one is found. | | **Proc Filesystem (`procfs`)** | `procFs` | Collects diagnostic files from`/proc/fs`, specifically: "`info`", "`options`", and "`es_shrinker_info`" | | ## Configure Core Files SingleStore recommends enabling core file creation on each host in the cluster. Core files can help SingleStore Support troubleshoot issues that may arise while running SingleStore. Refer to [Configure Core Files](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/configure-core-files.md) for more information. ## Configure File Descriptor and Maximum Process Limits A SingleStore cluster uses a substantial number of client and server connections between aggregators and leaf nodes to run queries and cluster operations. SingleStore recommends setting the Linux file descriptor and maximum process limits to the values listed below to account for these connections. Failing to increase this limit can significantly degrade performance and even cause connection limit errors. The ulimit settings can be configured in the `/etc/security/limits.conf` file, or directly via shell commands. Permanently increase the open files limit and the max user processes limit for the `memsql` user by editing the `/etc/security/limits.conf` file as the root user and adding the following lines: ``` memsql soft NOFILE 1024000 memsql hard NOFILE 1024000 memsql soft nproc 128000 memsql hard nproc 128000 ``` > **📝 Note**: Each node must be restarted for the changed ulimit settings to take effect. The `file-max` setting configures the maximum number of file handles (file descriptor limit) for the entire system. On the contrary, ulimit settings are only enforced on a process level. Hence, the `file-max` value must be higher than the `NOFILE` setting. Increase the maximum number of file handles configured for the entire system in `/proc/sys/fs/file-max`. To make the change permanent, append or modify the `fs.file-max` line in the `/etc/sysctl.conf` file. ## Configure the Linux nice Setting Given how the Linux kernel calculates the maximum nice limit, SingleStore recommends that you modify the `/etc/security/limits.conf` file and set the maximum `nice` limit to `-10` on each Linux host in the cluster. This will allow the SingleStore engine to run some threads at higher priority, such as the garbage collection threads. To apply this new `nice` limit, restart each SingleStore node in the cluster. Alternatively, you may set the default `nice` limit to `-10` on each Linux host in the cluster prior to deploying SingleStore. ## Configure Linux ulimit Settings Most Linux operating systems provide ways to control the usage of system resources such as threads, files and network at an individual user or process level. The per-user limitations for resources are called ulimits, and they prevent single users from consuming too much system resources. For optimal performance, SingleStore recommends setting ulimits to higher values than the default Linux settings. The ulimit settings can be configured in the `/etc/security/limits.conf` file, in the `/etc/security/limits.d` file, or directly via shell commands. ## Configure Linux vm Settings SingleStore recommends letting first-party tools, such as `sdb-admin` and `memsqlctl`, configure your `vm` settings to minimize the likelihood of getting memory errors on your hosts. The default values used by the tools are the following: * `vm.max_map_count` set to `1000000000` * `vm.overcommit_memory` set to `0` **WARNING**: `vm.overcommit_memory` should be set to 0. Using values other than 0 is recommended only for systems with swap areas larger than their physical memory. Please consult your distribution documentation. * `vm.overcommit_ratio` ignore, unless `vm.overcommit_memory` is set to `2`, in which case, set this to `99`. See the warning above for `vm.overcommit_memory` values other than 0. * `vm.min_free_kbytes` set to either 1% of system RAM or 4 GB, whichever is smaller * `vm.swappiness` set between `1` and `10` If SingleStore Tools cannot set the values for you, you will get an error message stating what the value should be and how to set it. You can set the values manually using the `/sbin/sysctl` command, as shown below. ```shell sudo sysctl -w vm.max_map_count=1000000000 ``` ```shell sudo sysctl -w vm.min_free_kbytes= ``` ## Toolbox vm Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | -------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Max Map Count** | `maxMapCount` | Checks that[vm.max\_map\_count](https://opensearch.org/docs/latest/opensearch/install/important-settings/)is at least`1000000000` | The`vm.max_map_count`kernel setting should be at least`1000000000` | | **Minimum Free Kilobytes** | `minFreeKbytes` | Checks if[vm.min\_free\_kbytes](https://www.thegeekdiary.com/how-to-calculate-recommended-value-of-vm-min_free_kbytes-kernel-tuning-parameter/)is greater than the recommended minimum | The value of`vm.min_free_kbytes`is set to either 1% of system RAM or 4 GB, whichever is smaller | | **Swappiness** | `vmSwappiness` | Checks the value of[vmSwappiness](https://linuxhint.com/understanding_vm_swappiness/) | The swappiness value (`0 - 100`) affects system performance as it controls when swapping is activated, and how swap space is used.When set to lower values, the kernel will use less swap space. When set to higher values, the kernel will use more swap space.Recommended: Swappiness should never be set to`0`. | | **vmOvercommit** | `vmOvercommit` | Checks if the`vmOvercommit`kernel setting is too low\.By design, Linux kills processes that are consuming large amounts of memory when the amount of free memory is deemed to be too low\.Overcommit settings that are set too low may cause frequent and unnecessary failures.Refer to[Configuring System Memory Capacity](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-configuration_tools-configuring_system_memory_capacity)for more information. | Providing virtual memory without guaranteeing physical storage for it | ## Configure Swap Space SingleStore recommends that you create a swap partition (or swap file on a dedicated device) to serve as an emergency backing store for RAM. SingleStore makes extensive use of RAM (especially with rowstore tables), so it is important that the operating system does not immediately start killing processes if SingleStore runs out of memory. Because typical hosts running SingleStore have a large amount of RAM (> 32 GB/node), the swap space cannot be small (>= 10% of physical RAM). For more information setting up and configuring swap space, please refer to your distribution’s documentation. After enabling these settings, your hosts will be configured for optimal performance when running one or more SingleStore nodes. ## Toolbox Swap Space Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | -------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Swap** | `swapEnabled` | Checks if swapping is enabled. | Recommended: Enabled.The total swap memory on each host should be >= 10% of the total RAM (total physical memory) | | **Swap Usage** | `swapUsage` | Checks if the[swap space](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_storage_devices/getting-started-with-swap_managing-storage-devices#getting-started-with-swap_managing-storage-devices)that is actively being used is less than 5% | | ## Configure Transparent Huge Pages Linux organizes RAM into pages that are usually 4 KB in size. Using transparent huge pages (THP), Linux can instead use 2 MB pages or larger. As a background process, THP transparently re-organizes memory used by a process inside the kernel by either merging small pages to huge pages or splitting few huge pages to small pages. This may block memory usage on the memory manager, which may span for a duration of a few seconds, and prevent the process from accessing memory. As SingleStore uses a lot of memory, SingleStore recommends that you disable THP at boot time on all nodes (master aggregator, child aggregators, and leaf nodes) in the cluster. THP lag may result in inconsistent query run times or high system CPU (also known as red CPU). To disable THP, add the following lines to the end of `/etc/rc.local` before the `exit` line (if present), and reboot the host: ``` echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag echo no > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag echo 0 > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag echo no > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag ``` On Red Hat distributions, THP will be under `redhat_transparent_hugepage`, on other distributions of Linux it will just be `transparent_hugepage`. You can check which your system uses by running `ls /sys/kernel/mm/`. Keep only the four relevant settings. The `khugepaged/defrag` option will be `1` or `0` on newer Linux versions (e.g. CentOS 7+), but `yes` or `no` on older versions (e.g. CentOS 6). You can check which your system uses by running `cat /sys/kernel/mm/*transparent_hugepage/khugepaged/defrag`. Keep only the matching setting. For example, if you see `1` or `0`, keep the line with `echo 0`; if you see `yes` or `no`, keep the line with `echo no`. You should end up with at least three lines of settings, for `enabled`, `defrag`, and `khugepaged/defrag`. For example, the correct configuration for CentOS 7 is: ``` echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag echo 0 > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag ``` Typically, you may include all eight settings and THP will still be disabled as expected. > **📝 Note**: Refer to the documentation for your operating system for more information on how to disable THP. ## Toolbox THP Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | -------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | **Transparent Huge Pages (THP)** | `transparentHugepage` | Checks if[transparent huge pages](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge)are disabled on each host in`/sys/kernel/mm/transparent_hugepage/enabled`and`/sys/kernel/mm/transparent_hugepage/defrag` | Recommended: Disabled.The value of these two settings must be either`[never]`or`[madvise]`. | ## Configure Network Time Protocol Service Install and run `ntpd` to ensure that system time is in sync across all nodes in the cluster. For Debian distributions (like Ubuntu): ```shell sudo apt-get install ntpd ``` For Red Hat / CentOS/ AlmaLinux: ```shell sudo yum install ntp ``` ## Recommended CPU Settings ## Configure Cluster-on-Die Mode If you are installing SingleStore natively and have access to the BIOS, you should enable Cluster-on-Die in the system BIOS for hosts with Haswell-EP and later x86\_64 CPUs. When enabled, this will result in multiple NUMA regions being exposed per processor. SingleStore can take advantage of NUMA nodes by binding specific SingleStore nodes to those NUMA nodes, which in turn will result in higher SingleStore performance. ## Configure NUMA If the CPU(s) on your host supports Non-Uniform Memory Access (NUMA), SingleStore can take advantage of that and bind SingleStore nodes to NUMA nodes. Binding SingleStore nodes to NUMA nodes allows faster access to in-memory data since individual SingleStore nodes only access data that’s collocated with their corresponding CPU. If you do not configure SingleStore this way, performance will be greatly degraded due to expensive cross-NUMA-node memory access. Configuring for NUMA should be done as part of the installation process; however, you can reconfigure your deployment later, if necessary. > **📝 Note**: Linux and `numactl` cannot detect when the virtual environment hosts have NUMA. Therefore, the processor and memory binding must be done by the management system of the virtual environment. The recommended setup is to configure the VMs with SingleStore nodes, such that processors and memory are bound or reserved for that NUMA node.This configuration is recommended as it allows for VM portability with the associated performance improvements afforded by optimizing your system for NUMA. . SingleStore Toolbox can perform the NUMA binding for you; however, you must have `numactl` installed first. Perform the following steps on each host: 1. Log into each host and install the `numactl` package. For example, for a Debian-based OS: ```shell sudo apt-get install numactl ``` 2. For Red Hat / CentOS / AlmaLinux, run the following: ```shell sudo yum install numactl ``` 3. Check the number of NUMA nodes your hosts by running `numactl --hardware`. For example: ```shell numactl --hardware ``` ```output available: 2 nodes (0-1) ``` The output shows that there are 2 NUMA nodes on this host, numbered 0 and 1. For additional information, see [Configuring SingleStore for NUMA](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/cluster-configuration/configuring-singlestore-for-numa.md). ## Toolbox CPU Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | ------------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU Features** | `cpuFeatures` | Read the content of[cpuinfo](https://www.thegeekdiary.com/proccpuinfo-file-explained/)and check that the flags field contains the[sse4\_2](https://en.wikipedia.org/wiki/SSE4)or[avx2](https://www.chessprogramming.org/AVX2)extensions set. | Recommended: sse4\_2 and  avx2 are enabledSingleStoreis optimized for architectures supporting SSE4.2 and AVX2 instruction set extensions, but will run successfully on x64 systems without these extensions.Refer to[AVX2 Instruction Set Verification](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/cluster-configuration/avx-2-instruction-set-verification.md)for more information on how to verify if your system supports AVX2. | | **CPU Frequency** | `cpuFreqInfo` | Collects information about CPU frequency configuration | The following folders should exist:`/sys/devices/system/cpu/cpufreq`and/`sys/devices/system/cpu`[CPU frequency scaling](https://wiki.archlinux.org/title/CPU_frequency_scaling)data is collected from`/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` | | **CPU Hyperthreading** | `cpuHyperThreading` | Checks that hyperthreading is enabled on each host via the[lscpu](https://man7.org/linux/man-pages/man1/lscpu.1.html)command (available on each host) | Hyperthreading is enabled | | **CPU Threading Configuration** | `cpuThreadingInfo` | Collects information about CPU threading configuration[lscpu](https://man7.org/linux/man-pages/man1/lscpu.1.html)is available on each host | Hyperthreading is enabled if the number of threads per core > 1 | | **CPU Idle and Utilization** | `cpuIdle` | Checks the[CPU utilization](https://www.techopedia.com/definition/28291/cpu-utilization)&[idle](https://en.wikipedia.org/wiki/Idle_\(CPU\))Checks if the CPU is frequently more than 5% idle.If not, this typically indicates that your workload will not have room to grow, and more cores are (will likely be) required | Percentage of time the CPU is[idle](https://01.org/linuxgraphics/gfx-docs/drm/driver-api/pm/cpuidle.html): | | **CPU and Memory Bandwidth** | `cpuMemoryBandwidth` | Check that CPU and[memory bandwidth](https://en.wikipedia.org/wiki/Memory_bandwidth)is appropriate for safe performance on your hosts.[mlc](https://www.intel.com/content/www/us/en/developer/articles/tool/intelr-memory-latency-checker.html)and[lscpu](https://man7.org/linux/man-pages/man1/lscpu.1.html)are available on each host | | | **CPU Model** | `cpuModel` | Checks if all[CPU models](https://www.pcmag.com/encyclopedia/term/pc-cpu-models)are the same on each host | | | **CPU Power Control** | `cpuFreqPolicy` | Checks that power saving and turbo mode settings on all hosts are disabled | [turbo](https://wiki.archlinux.org/title/CPU_frequency_scaling)and[powerSave](https://wiki.archlinux.org/title/CPU_frequency_scaling)are disabled | | **NUMA Configuration** | `numaConfiguration` | Checks ifSingleStorewith NUMA is configured via[numactl](https://linux.die.net/man/8/numactl)for optimal performance as described in[Configuring SingleStore for NUMA](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/cluster-configuration/configuring-singlestore-for-numa.md) | Enabled on each leaf node host and configured via`numactl`for optimalSingleStoreperformance | ## Recommended Memory Settings ## Toolbox Memory Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | --------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Committed Memory** | `memoryCommitted` | Checks the[committed memory](https://linustechtips.com/topic/820185-what-is-committed-memory/)on each host and determines if it’s acceptable | Committed memory on each host: | | **Maximum Memory Settings** | `maxMemorySettings` | Checks the host’s maximum memory settings | Maximum memory settings are recommended to be a percentage of the host's total memory, with a ceiling of 90%Recommended: | ## Recommended Storage Settings > **❗ Important**: Using unlimited (bottomless) storage with a storage provider that is not S3-compatible is not supported. Please contact [SingleStore Support](https://support.singlestore.com) for additional information. ## POSIX-Compliant To maintain data durability and resiliency, SingleStore’s data directory (as defined by the [datadir](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/engine-variables/list-of-engine-variables.md) engine variable, and which holds database snapshots, transaction logs, and columnstore segments) must reside on a POSIX-compliant filesystem. SingleStore officially supports ext4 and XFS file systems. However, any POSIX-compliant file system can be used with SingleStore. We have conducted extensive testing with ext4 and XFS file systems and can provide support for all non-infrastructure related issues when running on a POSIX-compatible host. Most Linux filesystems, including ext3, ext4, XFS, and ZFS are POSIX-compliant when mounted on a POSIX-compliant host. ## Storage Requirements Storage guidelines include: * The storage location must be on a single contiguous volume, and should never be more than 60% utilized * 30 MB/s per physical core or vCPU * 300 input/output operations per second (IOPS) per physical core or vCPU. For example, for a 16-core host, the associated disk should be capable of 500MB/s and 5000 IOPS. * For rowstore, the amount of required disk space should be about 5x the amount of RAM. Rowstore storage capacity is limited by the amount of RAM on the host. Increasing RAM increases the amount of available data storage. * For columnstore, the amount of required disk space should be about the size of the raw data you are planning to load into the database. For concurrent loads on columnstore tables, SSD storage will improve performance significantly compared to HDD storage. * When using high availability (HA), the amount of disk space required will be 2x the size of the raw data.. ## Toolbox Disk Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | ----------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Presence of an SSD** | `validateSsd` | Verifies if a host is using an SSD for storage | Recommended: Each host is using an SSD for storage | | **Disk Bandwidth** | `diskBandwidth` | Checks that[disk bandwidth](http://matthewrocklin.com/blog/work/2015/12/29/disk-bandwidth)allows safe operation with aSingleStorecluster | Read, write, and sync-read speed >= 128.0 operations/second (ops/s) | | **Disk Latency** | `diskLatency`with`diskLatencyRead`,`diskLatencyWrite` | Checks the read and write[latency of the disk](https://www.bluematador.com/docs/troubleshooting/disk-latency)to determine overall disk performance | Read/write latency: | | **Disk Storage in Use** | `diskUsage` | Checks the amount of free disk space and determines if it’s approaching the capacity limit | Free disk space: | ## Recommended Network Settings ## Configure Network Settings **Note**: Perform the following steps on each host in the cluster. 1. As root, display the current `sysctl` settings and review the values of `rmem_max` and `wmem_max`. ```shell sudo sysctl -a | grep mem_max ``` 2. Confirm that the receive buffer size (`rmem_max`) is 8 MB for all connection types. If not, add the following line to the `/etc/sysctl.conf` file. ``` net.core.rmem_max = 8388608 ``` 3. Confirm that the send buffer size (`wmem_max`) is 8 MB for all connection types. If not, add the following line to the `/etc/sysctl.conf` file. ``` net.core.wmem_max = 8388608 ``` 4. Confirm that the maximum number of connections that can be queued for a socket (`net.core.somaxconn`) is at least 1024. SingleStore will attempt to update this value to `1024` on a node's host when the node starts. After the cluster is up and running, run the following on each host to confirm that this value has been set. ```shell sudo sysctl -a | grep net.core.somaxconn ``` If this value could not be set by SingleStore, add the following line to the host's `/etc/sysctl.conf` file. Note that values lower than `1024` could allow connection requests to overwhelm the host. ``` net.core.somaxconn = 1024 ``` 5. Persist these updates across reboots. ```shell sudo sysctl -p /etc/sysctl.conf ``` 6. At the next system boot, confirm that the above values have persisted. ## Default Network Ports Depending on the host and its function in deployment, some or all of the following port settings should be enabled on hosts in your cluster. These routing and firewall settings must be configured to: * Allow database clients (such as your application) to connect to the SingleStore aggregators * Allow all nodes in the cluster to talk to each other over the SingleStore protocol (`3306`) * Allow you to connect to management and monitoring tools | Protocol | Port | Direction | Description | | -------- | ------ | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TCP | `3306` | Inbound and Outbound | Default port used bySingleStore. Required on all nodes for intra-clustercommunication. Also required on aggregators for client connections. | | TCP | `22` | Inbound and Outbound | For host access. Required between nodes inSingleStoretool deployment scenarios. Also useful for remote administration and troubleshooting on the main deployment host. | | TCP | `443` | Outbound | To retrieve public repo key(s) for package verification. Required for nodes downloadingSingleStoreAPT or YUM packages. | | TCP | `8080` | Inbound and Outbound | Default port for Studio. (Only required for the host running Studio.) | The service port values are configurable if the default values cannot be used in your deployment environment. For more information on how to change them, see the [SingleStore configuration file](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/engine-variables/memsql-cnf.md), the [sdb-toolbox-config register-host](https://docs.singlestore.com/db/v9.1/reference/singlestore-tools-reference/sdb-toolbox-config-commands/register-host.md) command, and [Studio Installation Guide](https://docs.singlestore.com/db/v9.1/reference/singlestore-tools-reference/singlestore-studio/singlestore-studio-installation.md). We also highly recommend configuring your firewall to prevent other hosts on the Internet from connecting to SingleStore. ## Toolbox Network Checkers The following Toolbox checkers are run prior to deploying SingleStore. | Host Setting | Checker | Description | Host Configuration | | -------------------- | ------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Network Settings** | `networkBuffersMax` | Checks that the network kernel settings`mem_max`and`rmem_max`are not set too low | Recommended: Set each of these values to a minimum of 8 MB (>= 8 MB) | ## Self-Managed Columnstore Performance Recommendations SingleStore supports the `ext4` and `xfs` filesystems. As many improvements have been made recently in Linux for NVMe devices, SingleStore recommends using a 3.0+ series kernel. For example, CentOS 7.2 uses the 3.10 kernel. If you use NVMe drives, set the following parameters in Linux (make it permanent in `/etc/rc.local`): ``` # Set ${DEVICE_NUMBER} for each device echo 0 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/add_random echo 1 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/rq_affinity echo none > /sys/block/nvme${DEVICE_NUMBER}n1/queue/scheduler echo 1023 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/nr_requests ``` *** Modified at: March 30, 2026 Source: [/db/v9.1/reference/configuration-reference/cluster-configuration/system-requirements-and-recommendations/](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/cluster-configuration/system-requirements-and-recommendations/) (An index of the documentation is available at /llms.txt)