Linux sysctl Performance Tuning Parameters

sysctl is one of those Linux tools that attracts two kinds of bad advice. One camp never touches it and leaves obvious workload mismatches unaddressed. The other pastes giant “performance tuning” blocks from random forum posts into /etc/sysctl.conf, reboots, and hopes for free speed.

I do not recommend either approach. Kernel parameters absolutely matter, but only a small set tends to matter on ordinary servers, and even then the right values depend on the workload. A web reverse proxy, a busy outbound API worker, a PostgreSQL box, and a container host do not all want the same defaults.

This guide focuses on the parameters I see pay off most often, how to apply them safely, which ones take effect immediately, and where people still repeat outdated tuning from the 2010s.

What `sysctl` is and where settings belong

sysctl exposes runtime kernel parameters through /proc/sys. You can read them, change them live, and persist them for future boots.

Read a value:

sysctl vm.swappiness
cat /proc/sys/vm/swappiness

Set a value temporarily until reboot:

sudo sysctl -w vm.swappiness=10

Persist settings the modern way with drop-in files under /etc/sysctl.d/:

printf 'vm.swappiness = 10\n' | sudo tee /etc/sysctl.d/99-local-tuning.conf
sudo sysctl --system

You can still use /etc/sysctl.conf, and many older guides do, but I prefer sysctl.d because it is easier to organize and audit. I usually keep application- or purpose-specific files such as:

/etc/sysctl.d/99-network-tuning.conf
/etc/sysctl.d/99-memory-tuning.conf
/etc/sysctl.d/99-routing.conf

To list everything:

sysctl -a

That output is huge. In practice I filter it:

sysctl -a | grep -E '^(net\.core\.somaxconn|net\.ipv4\.tcp_max_syn_backlog|vm\.swappiness|fs\.file-max)'

How I apply changes safely

The basic workflow I use is simple:

record the current value
change it live with sysctl -w
test the workload or observe metrics
persist it only if it helps or is operationally required

That looks like this:

sysctl net.core.somaxconn
sudo sysctl -w net.core.somaxconn=4096
sysctl net.core.somaxconn

Then I verify the application or kernel behavior. If it is part of a service stack, I may also check the app configuration because raising a kernel limit does not automatically mean the application uses it.

To reload a single config file without rebooting:

sudo sysctl -p /etc/sysctl.d/99-network-tuning.conf

To reload the whole stack:

sudo sysctl --system

I avoid bulk edits during an incident. Kernel tuning is easy to get wrong when you are tired and chasing symptoms.

`net.core.somaxconn` and `tcp_max_syn_backlog`

These two are still worth knowing on high-traffic servers.

net.core.somaxconn controls the maximum size of the listen backlog the kernel will allow. Many applications request a backlog, but the kernel caps it here.

sysctl net.core.somaxconn
sudo sysctl -w net.core.somaxconn=4096

net.ipv4.tcp_max_syn_backlog controls how many queued SYN requests can wait before the connection is fully established.

sysctl net.ipv4.tcp_max_syn_backlog
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

I reach for these on busy reverse proxies, load balancers, and API edges, especially when I see backlog pressure during bursts. But I do not raise them blindly. First I confirm whether the application is actually hitting accept queue limits, and I verify that the service itself is configured appropriately.

For Nginx or other frontends, it also helps to review the surrounding stack in the reverse proxy SSL guide because kernel tuning alone will not compensate for a badly sized worker model.

TCP keepalive parameters for long-lived connections

TCP keepalive settings matter when connections stay open for a long time and you need dead peers detected reliably. I touch these on API workers, VPN endpoints, and services sitting behind stateful firewalls or load balancers that age out idle flows.

Relevant parameters:

sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

Common tuning example:

sudo sysctl -w net.ipv4.tcp_keepalive_time=600
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=30
sudo sysctl -w net.ipv4.tcp_keepalive_probes=5

That means:

send the first keepalive probe after 600 seconds idle
retry every 30 seconds
give up after 5 failed probes

I like shorter keepalive timing than the default on systems where stale connections create real application issues. But I do not treat keepalives as a universal fix for every timeout. Sometimes the real problem is an upstream idle timeout, a NAT table issue, or application-level connection pooling.

TIME_WAIT tuning: be careful with old advice

This area is full of outdated snippets. The setting people still mention most is net.ipv4.tcp_tw_reuse.

Check it:

sysctl net.ipv4.tcp_tw_reuse

A common setting is:

sudo sysctl -w net.ipv4.tcp_tw_reuse=1

On modern kernels this can help some outbound-heavy clients reuse sockets in TIME_WAIT, but I do not change it casually on NAT-heavy systems until I understand the connection pattern.

More importantly, ignore old advice about net.ipv4.tcp_tw_recycle. That parameter was removed years ago because it caused real problems, especially with NATed clients. If you see a tuning guide recommending it, close the tab.

The better response to TIME_WAIT volume is often:

confirm whether the host is mainly a client or a server
check the ephemeral port range
inspect connection reuse at the application layer
tune load balancers or client pools before touching the kernel

File descriptors: `fs.file-max` is not the same as `ulimit`

This distinction trips people up constantly.

fs.file-max is a kernel-wide ceiling on file handles. ulimit -n is a per-process limit inherited from the shell, service manager, or PAM stack.

Check the kernel maximum:

sysctl fs.file-max

Raise it temporarily:

sudo sysctl -w fs.file-max=2097152

Check your shell’s soft and hard per-process limits:

ulimit -Sn
ulimit -Hn

For a systemd-managed service, the service limit often matters more than your shell limit. Example override:

[Service]
LimitNOFILE=262144

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart myservice
systemctl show myservice -p LimitNOFILE

If you want a deeper walkthrough on service files and resource directives, the systemd unit files guide is the right companion. Raising fs.file-max without fixing service-level limits often changes nothing useful.

Memory-related parameters that matter most often

The two memory knobs I see most often in practical use are vm.swappiness and, less often, vm.vfs_cache_pressure.

Check them:

sysctl vm.swappiness
sysctl vm.vfs_cache_pressure

Server-friendly example:

sudo sysctl -w vm.swappiness=10
sudo sysctl -w vm.vfs_cache_pressure=50

I treat vm.swappiness=10 as a reasonable starting point for many servers. It keeps swap available without encouraging eager swap-out of anonymous memory. I use it a lot on web and application hosts.

vfs_cache_pressure is more workload-specific. Lower values tell the kernel to preserve inode and dentry cache more aggressively. On file-heavy systems that can help. On random generic servers, I do not assume it is automatically better.

If you want the broader operational context behind swap and page cache decisions, read the memory and swap configuration guide. It covers how I decide whether tuning is needed in the first place.

Transparent huge pages versus explicit huge pages

Transparent Huge Pages, or THP, are often misunderstood. People hear “huge pages improve performance” and assume every memory-heavy host should just leave THP alone or enable more of it.

Check current THP status:

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

For some databases, vendor guidance recommends disabling THP because its background behavior and compaction can cause latency spikes. In those cases, I follow the application guidance rather than generic tuning advice.

That is different from explicit huge pages, which certain databases or JVMs may want configured deliberately. Those are application-level capacity decisions, not just a kernel toggle you paste into a template.

When people mix THP advice with explicit huge page allocation, they usually end up with a half-understood configuration and no baseline measurements.

`ip_local_port_range` for outbound-heavy workloads

Busy clients can run out of ephemeral ports faster than people expect, especially on NAT gateways, proxies, crawlers, or API workers opening many outbound TCP connections.

Check the current range:

sysctl net.ipv4.ip_local_port_range

A broader range often looks like this:

sudo sysctl -w net.ipv4.ip_local_port_range='10240 65535'

That gives the kernel more local ports to use for outbound connections. It will not fix every connection issue, but it is a sensible lever when the server is a high-volume client.

Before changing it, I usually inspect socket state:

ss -tan state time-wait | wc -l
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c

If outbound behavior is a concern, pair that with the network troubleshooting guide so you know whether you are looking at port exhaustion, connection leaks, or upstream slowness.

`kernel.pid_max` for systems with many processes

This one matters less often, but when it matters, it matters sharply.

Check it:

sysctl kernel.pid_max

Raise it temporarily if needed:

sudo sysctl -w kernel.pid_max=262144

I think about this on build workers, container-heavy nodes, and systems that spawn large numbers of short-lived processes. If process creation failures start showing up and PID space is constrained, this is worth checking.

It is not a magic performance knob. Raising it just expands the namespace. But on certain busy nodes, the default may be tighter than you want.

Parameters that usually take effect immediately

Most sysctl -w changes apply immediately. That is why they are useful for testing. In practical terms, these kinds of values usually take effect as soon as you write them:

vm.swappiness
net.core.somaxconn
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_keepalive_*
net.ipv4.ip_local_port_range
kernel.pid_max

But “the kernel accepted the value” is not the same as “the application behavior changed right now.” A service may need restarting to pick up new per-process limits, reopen sockets, or request a larger backlog.

That is why my validation step always includes the workload, not just sysctl output.

Parameters where reboot or service restart still matters

Some changes are runtime-visible but operationally incomplete until something restarts.

Examples:

changing fs.file-max live does not raise existing service LimitNOFILE
changing THP boot parameters often needs reboot for a clean persistent state
changes tied to module loading or boot-time kernel behavior may not fully reflect without reboot
routing or forwarding changes may need application or network stack revalidation

I also distinguish between “works now” and “survives a reboot.” I have seen admins apply a perfect temporary fix with sysctl -w and then forget persistence completely.

Test with the workload, not just the parameter

A sysctl value can be correct in isolation and still irrelevant to the real bottleneck. I learned this the hard way years ago on a busy API node where everyone wanted to raise backlog settings, but the actual problem was an application worker pool that was too small and a reverse proxy timeout that was too aggressive. The kernel accepted every shiny new value. User experience barely changed.

That is why I validate against the symptom that motivated the change:

if I changed a listen backlog parameter, I watch connection errors and queue behavior
if I changed keepalive timing, I watch stale connection counts and reconnect patterns
if I changed file descriptor limits, I verify the service can open more sockets or files under real load
if I changed memory-related settings, I watch reclaim pressure, swap I/O, and latency rather than celebrating because sysctl printed the new number

A few commands I use during that validation window:

ss -s
ss -lnt
vmstat 1
free -h
journalctl -k --since '15 minutes ago'

The point is simple: kernel tuning should move an operational metric you care about. If it does not, revert it and keep looking.

Keeping a rollback path

Because sysctl -w changes are immediate, rollback is usually easy if you recorded the previous value first. I like to keep a quick note that looks like this before I change anything:

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog
sysctl vm.swappiness

If the change is not helping, reverting is straightforward:

sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sudo sysctl -w vm.swappiness=60

For persistent config, I comment out or remove the drop-in and reload:

sudo rm -f /etc/sysctl.d/99-local-tuning.conf
sudo sysctl --system

I do not leave “temporary experiments” behind in /etc/sysctl.d/ for someone else to rediscover later. Clean rollback is part of safe tuning, not an afterthought.

Validation: how I confirm a tuning change did anything

After making a change, I re-read the setting:

sysctl net.core.somaxconn

Then I look at system behavior, not just configuration:

fewer dropped or queued connections
lower connection timeout rates
stable memory pressure
enough open file descriptors for the service
no regressions in latency

Useful validation commands:

ss -s
ss -lnt
free -h
vmstat 1
systemctl show myservice -p LimitNOFILE
journalctl -u myservice --since '10 minutes ago'

If the system is under live load, I prefer making one change at a time. Bulk tuning is almost impossible to reason about after the fact.

Common mistakes I avoid

These are the big ones:

Copying giant tuning blocks from the internet. Most lines will not help your workload.
Confusing kernel-wide and per-process limits. fs.file-max is not ulimit.
Applying changes without measurement. If you cannot describe the symptom, you cannot judge the result.
Using removed parameters. tcp_tw_recycle is the classic bad example.
Persisting everything in /etc/sysctl.conf without structure. Drop-in files are easier to audit.
Ignoring application settings. Kernel backlog and service backlog need to align.
Skipping rollback notes. Always know the original value.

A small baseline I actually use

On many general-purpose Linux servers, my baseline tuning is intentionally modest:

vm.swappiness = 10
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

That is not a universal best-practice block. It is just a conservative starting point that has held up well on ordinary web and API workloads. From there, I tune only where metrics justify it.

Conclusion

sysctl tuning is useful when it is specific. I focus on a handful of parameters that match the server’s actual role: backlog values for busy listeners, keepalive timing for long-lived connections, descriptor limits for service scale, and memory settings that fit the reclaim behavior I want.

What I do not do is chase mythical “Linux optimization” through 40 undocumented kernel toggles. Most systems do better with a small, well-understood set of changes, verified one by one, than with a huge pasted config nobody wants to own later. Boring tuning, measured carefully, wins more often than dramatic tweaks.

What sysctl is and where settings belong