Skip to content 
Kernel tuning in Linux hosting brings measurable performance gains because I specifically adjust sysctl parameters for network, memory, CPU and security. I load profiles without restarting and adjust values for workloads, concurrency and I/O behavior so that the Server reacts quickly under load and works reliably.
Key points
- sysctl Controls kernel behavior at runtime
- Network optimize: Backlogs, sockets, TCP
- Memory trim: Swapping, Dirty Pages
- CPU fine tuning: Scheduler, PIDs
- Security hardening without overhead
What is sysctl in Linux hosting?
With sysctl I read and change kernel parameters at runtime without compiling the kernel. The values are stored as files in the /proc/sys directory, such as net/ipv4/tcp_max_syn_backlog, and control the network, memory and security. For hosting workloads with many connections, direct tuning reduces latency peaks and timeouts. I make temporary changes with sysctl -w and write permanent profiles in /etc/sysctl.d/*.conf. Then I load everything with sysctl -system and check dmesg and journal logs so that I can quickly recognize misconfigurations.
How to use sysctl safely
Before making any changes Profiles and document actual values with sysctl -a so that I can roll back at any time. I first test new values on staging VMs with a comparable load. Then I increase parameters step by step, observe metrics and adjust again. This is how I prevent OOM kills, socket drops and sporadic retransmits. For reproducible setups, I create a separate file such as /etc/sysctl.d/99-hosting.conf and load it in a controlled manner.
Temporarily test #
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
Set # permanently
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
vm.swappiness = 10
vm.dirty_ratio = 20
EOF
sudo sysctl --system
Network parameters that carry web servers
For many simultaneous connections, I increase somaxconn, so that the list backlog of Nginx or Apache does not overflow. I use net.ipv4.tcp_max_syn_backlog to increase the queue of half-open connections, which helps during traffic peaks. In web-only setups I usually leave net.ipv4.ip_forward off, with reverse proxies or gateways I turn it on. I validate backlog drops with ss -s and netstat -s and check whether accept queues are running empty. If you want to go deeper into congestion control, you can also evaluate algorithms such as CUBIC or BBR; my reference to TCP Congestion Control.
# Example values for highly frequented web servers
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_forward = 0
Memory and VM tuning for hosting workloads
I lower swappiness to 10 so that the kernel uses RAM for longer and swaps less. With vm.dirty_ratio of 15 to 20 percent, I limit dirty pages so that write load does not lead to long flush bursts. For many processes, I set vm.overcommit_memory to 1 if I know the applications and understand their reserves. In addition, I monitor page cache hits and IO wait so that I can interpret caching effects correctly. I provide a deeper look at cache behavior with this guide to the Page Cache.
# Storage and VM profiles
vm.swappiness = 10
vm.dirty_ratio = 20
vm.overcommit_memory = 1
CPU and scheduler fine-tuning
With high concurrency I lift kernel.pid_max so that many worker processes receive IDs. For CFS quotas I adjust kernel.sched_cfs_bandwidth_slice_us to avoid too short slices for bursty services. I check run queue lengths, context switches and steal times, especially on shared hosts. If I need CPU isolation, I bind services to cores via taskset or cgroups. An introduction to deeper kernel optimization is provided by this compact Kernel performance-Guide.
# Process and scheduler parameters
kernel.pid_max = 4194304
# Example for finer CFS slices
kernel.sched_cfs_bandwidth_slice_us = 5000
Safety parameters without loss of performance
I activate dmesg_restrict, to prevent unprivileged users from reading kernel logs. I use kernel.kptr_restrict to hide addresses that could help attackers with exploits. At network level, I switch on rp_filter by default to prevent IP spoofing. These settings hardly cost any performance and significantly strengthen host hardening. I load them into the same sysctl file in a controlled manner so that I remain traceable.
# Hardening via sysctl
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Extended network buffers for high throughput
For high-traffic hosts I fit TCP buffer so that fast connections do not hang in the window limit. I use net.ipv4.tcp_rmem and tcp_wmem to define minimum, standard and maximum sizes. net.core.optmem_max and net.core.netdev_max_backlog help to absorb short bursts cleanly. I monitor retransmits, cwnd development and buffer fill levels before increasing values further. These steps increase throughput and noticeably reduce latency fluctuations on modern 10G links.
# extended network buffer
net.core.optmem_max = 81920
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Practice: From baseline to measurable profit
I start every tuning with a Baseline and document key figures such as P95 latency, throughput and error rate. I then change a few parameters, load the profile and measure again with ab, wrk or sysbench. If the latency drops, I record the change; if it rises, I roll it back. This is how I set up a hosting profile that corresponds to my application. Finally, I verify again under production load before I make the values permanent.
# Save actual status
sysctl -a > /root/sysctl-baseline.txt
# View network parameters
sysctl -a | grep -E 'net\.core|net\.ipv4'
# Reload profiles
sysctl --system
Comparison table: Standard vs. hosting profile
The following Table shows practical starting values that I use frequently. Values depend on workload, network and hardware. I start with this, check metrics and adjust step by step. If there are problems, I go back to the default values and increase them again in small steps. This way, I keep risks low and achieve consistent results.
| Parameters | Standard | Hosting profile | Benefit |
|---|---|---|---|
| net.core.somaxconn | 128 | 65535 | More accepted connections |
| net.ipv4.tcp_max_syn_backlog | 1024 | 4096 | Fewer drops with peaks |
| vm.swappiness | 60 | 10 | Less swapping under load |
| kernel.pid_max | 32768 | 4194304 | More processes/workers possible |
| vm.dirty_ratio | 30 | 20 | More even writing |
Avoiding common mistakes and monitoring
I do not use Extreme values, because they can lead to timeouts, OOM kills or packet loss. I test changes in stages, each with a clear metric and a short observation phase. Critical indicators are accept queue length, TCP retransmits, P95 latency, IO wait and swap in/out. I use lightweight agents and dashboards for monitoring so that I can quickly recognize trends. After kernel updates, I check whether sysctl profiles are still valid and reload them if necessary.
Persistence, sequence and distributions
To ensure that profiles remain reproducible, I observe the loading sequence in /etc/sysctl.d: Files are processed lexicographically. I deliberately assign prefixes such as 60-... or 99-... to ensure that my hosting profile overrides other defaults. Differences between distributions (Debian/Ubuntu vs. RHEL/Alma) usually only affect paths and default values; sysctl -system always loads /etc/sysctl.conf, /etc/sysctl.d/*.conf and vendor files if applicable. After major system updates, I check with sysctl -system -o (dry run depending on the version) or compare the loaded effective configuration against my template to avoid surprises.
# Example: ensure a clean sequence
sudo ls -1 /etc/sysctl.d
10-vendor.conf
50-defaults.conf
99-hosting.conf # overwrites everything before it
# effectively diff loaded values
sysctl -a > /root/sysctl-after.txt
diff -u /root/sysctl-baseline.txt /root/sysctl-after.txt | less
TCP life cycle and port management
Under heavy load, many short-lived connections are created. I put ip_local_port_range so that outgoing connections (e.g. from proxies) do not get stuck in the ephemeral port limit. tcp_fin_timeout controls how long sockets remain in FIN-WAIT-2. With meaningful Keepalive-parameters, I reduce dead sessions faster without aggressively cutting connections. TIME_WAIT is normal and protects against late packets; I don't reduce it blindly. tcp_tw_reuse primarily helps on client hosts, on pure servers it usually stays off. I leave timestamps and SACK on, as they improve performance and robustness.
# Port range and TCP life cycle
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# Caution with tcp_tw_reuse: only useful for outgoing client load
# net.ipv4.tcp_tw_reuse = 1
Keep IPv6 and neighboring tables stable
Many hosts today carry dual-stack traffic. I optimize the ARP/ND tables to avoid „neighbor table overflow“ messages, especially on proxies or nodes with numerous peers. The gc_thresh-I define thresholds to match the connection matrix. I leave ICMPv6 and router add options restrictive for servers so that no unwanted routes flow in. For IPv4, I also pay attention to ARP garbage collection so that entries age in good time but do not disappear too soon.
# neighboring tables: more generous thresholds
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
# ARP/ND aging conservative
net.ipv4.neigh.default.gc_stale_time = 60
Thinking file descriptors and backlogs together
A frequent bottleneck are File descriptors. If applications hold thousands of sockets, fs.file-max (system-wide) and ulimit/nofile (per service) fit together. somaxconn increases the list queue, but only helps if the web server itself is allowed to open more FDs and the accept rate is high enough. I make sure that system and service limits are synchronized, otherwise artificial bottlenecks occur despite „large“ kernel backlogs.
# Allow more FDs system-wide
fs.file-max = 2097152
# Service-side (example systemd unit)
# [Service]
# LimitNOFILE=1048576
Cushion UDP/QUIC workloads
Use DNS, syslog, telemetry and QUIC (HTTP/3) UDP. Here I scale the global socket buffers and UDP-specific memory limits. For large, bursty UDP loads (such as telemetry gateways), this prevents drops in the receive path. I monitor the error counters with ss -u -a and netstat -su and gradually adjust the maximums. For QUIC, net.core.rmem_max/wmem_max is also relevant, as userspace stacks often reach these limits via setsockopt.
# UDP buffer and limits
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
Specify dirty writeback: Bytes instead of percentages
On systems with a lot of RAM, percentage values can lead to large, sudden flushes. I therefore prefer to use vm.dirty_background_bytes and vm.dirty_bytes, to define absolute upper limits. This stabilizes the write rate and smoothes latencies, especially with HDDs or mixed workloads. I also consider vm.min_free_kbytes moderately so that the kernel has enough free memory for burst allocations.
# Example: absolute dirty limits (approx. 1G background, 4G hard)
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
Distribute RPS/RFS and network IRQ load
At high PPS rates, a single CPU core can hang on the NIC-IRQ. I use Receive Packet Steering (RPS) and, if necessary, Receive Flow Steering (RFS) to distribute packet processing across several cores. Globally I set net.core.rps_sock_flow_entries, The actual allocation takes place per queue via Sysfs. This reduces CPU hotspots, improves cache locality and reduces latency peaks. In combination with net.core.netdev_max_backlog, this results in a more robust pipeline.
# Global flow entries for RPS
net.core.rps_sock_flow_entries = 32768
# Note: Per-queue tuning via /sys/class/net//queues/rx-*/rps_cpus
# and rps_flow_cnt, depending on NIC and number of queues.
Containers, namespaces and VMs
Containers hold many net.*-values namespaced and can apply per network namespace. I therefore document whether I am customizing host or pod/container network. Orchestrators often only allow a safe list of sysctls; values like kernel.pid_max remain host-side. On VMs, I check which virtual NICs and offloads are active (virtio, ENA), because offloads and MTU have a strong impact on buffer requirements and cwnd development. NUMA-heavy bare-metal hosts benefit from deactivated vm.zone_reclaim_mode and deliberate CPU/IRQ affinity layout.
# Avoid NUMA side effect
vm.zone_reclaim_mode = 0
Conntrack and stateful firewalls at a glance
If the host runs as a NAT/firewall or hosts many containers with egress NAT, I scale the nf_conntrack-table. Hash tables that are too small generate drops and high latencies during table scans. I measure the load with nstat and look at „expected“ vs. „in use“. For pure web servers without NAT, conntrack is often uncritical or even deactivated; on gateways, it must be included in the tuning package.
# Conntrack size (only if actively used!)
net.netfilter.nf_conntrack_max = 1048576
Robustness against attacks and anomalies
Help with bot traffic and scans tcp_syncookies and conservative ICMP/redirect options. Syncookies save the handshake in the event of overflowing SYN queues without throttling legitimate traffic excessively. I disable redirects and source routes on servers that should not be routed. These hardenings are lightweight and complement the protection mechanisms mentioned above.
# SYN flood defense and conservative routing behavior
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
Deepen measurement practice: What I check regularly
For reproducible results, I measure consistently before and after changes. On the network side, I use ss -s, ss -ti, nstat and netstat -s to see queue lengths, retransmits and sack stats. On the memory I/O side, vmstat, iostat and pidstat help to classify dirty flushes, context switches and CPU wait times. I also look at load tests:
- Accept queue (LISTEN) and SYN queue: Dropped vs. overflows
- Pacing/throughput per connection and cwnd development
- P95/99 latencies in A/B comparison, instead of just average
- Swap in/out rate and page cache hit rate
- IRQ load distribution and run queue lengths per CPU
# quick status checks
ss -s
netstat -s | egrep 'listen|SYN|retran|dropped'
vmstat 1 10
pidstat -w -u -r 1 5
Example: Consolidated hosting profile
To start with, I combine basic and extended values in one file. Then I increase in small steps, each with clear measuring points. The following values are a conservative but performant starting point for busy web servers and proxies.
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
# Network basics
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 3000
net.core.optmem_max = 81920
# TCP buffers and ports
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# UDP/QUIC
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
# Neighbor tables
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv4.neigh.default.gc_stale_time = 60
# Security
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Memory/VM
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
vm.overcommit_memory = 1
vm.zone_reclaim_mode = 0
# CPU/Processes
kernel.pid_max = 4194304
kernel.sched_cfs_bandwidth_slice_us = 5000
# RPS
net.core.rps_sock_flow_entries = 32768
# FDs
fs.file-max = 2097152
EOF
sudo sysctl --system
Summary: Tuning as a recurring process
Targeted Kernel tuning with sysctl delivers clear effects in hosting: shorter response times, higher throughput values and constant services. I start with network basics such as somaxconn and tcp_max_syn_backlog, then take care of memory with swappiness and dirty_ratio. Then I optimize PIDs and schedulers and harden the host with dmesg_restrict, kptr_restrict and rp_filter. I measure every change, document it and keep an eye on metrics. Step by step, I create a profile that serves my workloads efficiently and has reserves for traffic peaks.
