Linux Kernel and OS Tuning for High-Throughput Tor Relays

The Linux network stack has several tunable parameters critical for Tor relay performance. Increase socket buffer sizes: net.core.rmem_max and net.core.wmem_max to 134217728 (128MB). Set net.core.netdev_max_backlog to 50000 to prevent packet drops during bursts. Enable net.ipv4.tcp_window_scaling and set net.ipv4.tcp_wmem and net.ipv4.tcp_rmem with triple values (min default max) of 4096 65536 134217728. Set net.ipv4.tcp_mtu_probing=1 for better MTU discovery. Set net.ipv4.tcp_max_syn_backlog=65535 to handle the large number of simultaneous Tor connections. Increase net.core.somaxconn to 65535. Apply these settings in /etc/sysctl.d/99-tor-relay.conf and load with sysctl -p.

Tor relays handling high connection counts require high file descriptor limits. Default Linux limits (1024 per process) are far too low for busy relays. Set /etc/security/limits.conf to allow tor user unlimited open files (tor soft nofile 65536; tor hard nofile 65536). For systemd-managed Tor instances, add LimitNOFILE=65536 to the systemd service file. The NoFile limit for the running Tor instance should be visible in /proc/$(pidof tor)/limits. Verify the actual limit Tor is using by looking at max open files in the process limits file. Tor 0.4.x automatically adjusts its internal connection count to the available file descriptor limit, so this directly affects maximum simultaneous connections.

On multi-core systems, IRQ balance ensures network interrupt handling is distributed across CPUs. Install and enable irqbalance daemon. For high-bandwidth systems, pin network adapter IRQs to specific CPU cores manually using /proc/irq/N/smp_affinity. Pin the Tor process to specific cores with taskset or cpuset to reduce cache invalidation from context switching between cores. For multi-instance Tor deployments, pin each instance to different NUMA nodes using numactl to prevent cross-NUMA memory access. Use CPU frequency scaling with the performance governor (cpufreq-set -g performance) on all cores to prevent frequency scaling introducing latency variability.

Tor relays do not typically require high disk throughput, but disk I/O for logging, consensus documents, and descriptor downloads can become a bottleneck at very high connection counts. Mount the Tor data directory on a tmpfs (RAM-based filesystem) for workloads where non-volatile storage is not required for the directory/exit. For bridge relays where bridge descriptor persistence matters, use the deadline or mq-deadline I/O scheduler (set per device in /sys/block/sda/queue/scheduler). Disable atime on Tor data directory mount points (mount option: noatime) to reduce metadata updates. For SSDs, ensure TRIM is enabled (fstrim.timer in systemd). SSD latency eliminates the disk I/O bottleneck for most relay configurations.

Tor's memory allocation behavior benefits from tuning Linux memory management. Disable transparent huge pages for Tor processes, as THP causes latency spikes during compaction: echo never > /sys/kernel/mm/transparent_hugepage/enabled. Set vm.swappiness=1 to prevent Tor relay data from being swapped to disk, which would cause severe latency. Set vm.overcommit_memory=1 to prevent memory allocation failures under high connection load. For systems with sufficient RAM, allocate a tmpfs for /var/lib/tor/data/keys to keep cryptographic key material in RAM. Monitor memory usage with Tor's memory statistics in the logs (NOTICE level shows memory pressure events).