Skip to main content

Installation: System Configuration Recommendations

Linux​

Set a higher limit on open file descriptors​

To handle more connections to more databases and indexes at once, a higher limit on open file descriptors (which also affects the max number of network connections) is required.

ulimit -n 65535

Enlarge local available port range​

To serve more connections at once (heavy traffic usage) from clients, a higher port range is required.

sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Reuse TIME-WAIT sockets​

Reuse TCP sockets that are still in the TIME-WAIT state for new connections.
This allows RavenDB to handle more requests faster.

sysctl -w net.ipv4.tcp_tw_reuse=1

Recycle TIME-WAIT sockets​

Similar usage to the above reuse.
Do not use when working with NAT or in Kernel 4.12+.

sysctl -w net.ipv4.tcp_tw_recycle=1

Enlarge memory-mapped max usage​

RavenDB uses memory-mapped files: a few per database, plus more for indexes and other components.
Upper limit is required to serve larger amounts of databases and indexes.

sysctl -w vm.max_map_count=2000000

Select swap device​

Consider placing swap on a separate physical drive.

For details on current swapping partitions and priorities use:

swapon

Tune block-device settings for random-access workloads (read_ahead_kb, scheduler, rotational)​

read_ahead_kb controls how much data the kernel prefetches on each read.
RavenDB's typical workload is random-access over 8 KB Voron pages, so a high read_ahead_kb amplifies I/O - small random reads get fused into large ones, wasting disk bandwidth and page cache and raising latency under load (most visible with many databases or large datasets).
Lowering it keeps each read close to what RavenDB actually requested, which is what this random-access workload usually wants.

The trade-off is database startup: when a database loads, RavenDB reads its journal files sequentially, and a low read_ahead_kb slows that read down.
RavenDB mitigates this internally - it hints the kernel to read the journals sequentially during load (controlled by Storage.UseSequentialReadAheadHintForJournalRecovery) - so you can keep read_ahead_kb low without a large startup penalty.

For random-access SSD/NVMe workloads, values in the 8-64 KB range are worth experimenting with, versus the common 128 KB default.

Check the current value (<device> is e.g. sda or nvme0n1):

cat /sys/block/<device>/queue/read_ahead_kb

Set it at runtime (requires root, resets on reboot):

echo 32 > /sys/block/<device>/queue/read_ahead_kb

RavenDB captures the device's read-ahead value when it opens its files, so restart the server (or reload the databases) for a runtime change to take effect on already-open storage.

Also check rotational and scheduler.
They matter most on virtualized disks (Azure managed disks in particular), which are often misreported as rotational even when backed by SSD/NVMe, so the kernel picks HDD-oriented defaults.
Bare-metal SSD/NVMe is usually detected correctly.
For SSD/NVMe, rotational=0 and scheduler=none are usually better.

Persist these across reboots with a udev rule:

# /etc/udev/rules.d/99-ravendb.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/read_ahead_kb}="32"
ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/read_ahead_kb}="32"

# apply without reboot:
# sudo udevadm control --reload-rules && sudo udevadm trigger

This rule matches every sd* and nvme* device on the host.
If other workloads share the machine, scope it to the disks RavenDB actually uses (find the device behind a path with df <path> or lsblk) so you don't retune unrelated disks.

When to tune read_ahead_kb

The common 128 KB default works well for the majority of deployments - it is what RavenDB instances typically run with - and a lower value is worth pursuing only when heavy random-access load (many databases or large datasets on one host) shows up as high I/O wait or memory pressure.
There is no universally correct read_ahead_kb.
It depends on your disk, workload, and available memory, so test candidate values in your own environment and verify their effect on request/response times under real load before committing to one.
RavenDB raises a startup warning when a block device's read_ahead_kb is above Storage.ReadAheadKbAlertThresholdInKb (default 128 KB), since an unusually high read-ahead causes the I/O amplification described above.

In this article