Linux Network Tuning with sysctl: TCP Buffers and Backlogs - 夜莺博客

Linux Network Tuning with sysctl: TCP Buffers and Backlogs

Default Linux network settings are conservative because they have to fit a laptop, a container and a 400G database server equally well. On a busy proxy, an object store or a NAS, that conservatism shows up as dropped connections and truncated throughput. This guide tunes the parameters that matter in practice - TCP send and receive buffers, the listen backlog, connection-tracking and file-descriptor ceilings - with a repeatable method: measure, change one group at a time, re-measure with iperf3 and real workload traffic, and keep the change in a versioned file under /etc/sysctl.d/.

Start with evidence, not with numbers from the internet

ss -s
ss -lnt | head
nstat -az | grep -Ei 'drop|retrans|prune|overflow'
netstat -s | grep -i listen
dmesg | grep -i 'Possible SYN flooding|nf_conntrack' | tail
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

SYNs to LISTEN sockets dropped and rising nstat overflow counters are the signals that justify backend and backlog tuning. If those counters are flat, changing sysctls will do nothing except make the next admin's life harder.

TCP buffers and the auto-tuning window

# /etc/sysctl.d/10-tcp-socket-buffers.conf
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 262144 67108864
net.ipv4.tcp_wmem = 4096 262144 67108864
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 16384
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf
iperf3 -s                       # on the receiver
iperf3 -c 10.0.0.20 -t 20 -P 4  # on the sender, 4 parallel streams
iperf3 -c 10.0.0.20 -t 20 -u -b 10G

The three numbers in tcp_rmem and tcp_wmem are minimum, default and maximum. Auto-tuning moves the effective size between default and max as the connection grows, so raising only the third value takes effect dynamically; changing the second value requires restarting the applications to be picked up. Match rmem_max and wmem_max to the maximum you set for TCP, otherwise the socket buffer ceiling clips your auto-tuned value.

Backlog and accept queue

net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_abort_on_overflow = 0

somaxconn caps how many established-but-unaccepted connections can wait; an application can request a larger backlog, but the kernel clamps it to this value. Always raise the application's own setting too (nginx backlog, Gunicorn --backlog, Java acceptCount) or the kernel ceiling is not the binding constraint. Keep tcp_syncookies enabled - it is a safety net, not a substitute for a bigger backlog.

Connection tracking, ports and file descriptors

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_tw_reuse = 1
fs.file-max = 2097152
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
dmesg | grep -i 'table full'

A NAT or load-balancing host that hits nf_conntrack: table full, dropping packet drops traffic with no application log at all - always size the table against expected concurrent flows and watch the count. For file descriptors, also check the per-process limit (prlimit --nofile --pid <pid>) and the systemd unit's LimitNOFILE; raising fs.file-max alone changes nothing.

Validation and rollback

sysctl -a > /root/sysctl-before.txt
# apply new drop-in file, then
sysctl -a > /root/sysctl-after.txt
diff /root/sysctl-before.txt /root/sysctl-after.txt

# runtime rollback for a single key
sysctl -w net.ipv4.tcp_rmem="4096 87380 6291456"

Persist changes only in /etc/sysctl.d/*.conf (never edit /etc/sysctl.conf by hand across a fleet) and record the before/after dump next to the change ticket. A tuning change without a baseline measurement and a rollback path is a future three-in-the-morning incident. Useful companions: iperf3 testing guide, Linux network troubleshooting, ethtool NIC diagnostics and tc traffic shaping.

原文链接:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/tuning-the-network-performance_monitoring-and-managing-system-status-and-performance