Linux 内核参数调优与系统性能提升

net.core.somaxconn过小会导致高并发下新连接被拒，需同步调大内核参数与应用层backlog；vm.swappiness=0不等于禁用swap，真正禁用需swapoff -a并注释fstab；tcp_tw_reuse在nat环境可能引发冲突，服务器端不应启用；虚拟机中rdtsc不准，应使用clock_gettime(clock_monotonic)。

net.core.somaxconn 设置太小导致服务拒绝新连接

很多 Web 服务（比如 nginx、redis）在高并发下突然拒收连接，ss -s 显示 tw（TIME_WAIT）数量正常但 synrecv 堆积，大概率是这个参数卡住了。linux 默认值通常是 128，而现代服务监听队列动辄要上千。

• 用 sysctl net.core.somaxconn 查当前值，用 sysctl -w net.core.somaxconn=65535 临时调大
• 必须同步改应用层的 listen() 第二个参数（即 backlog），否则内核会默默截断——比如 Nginx 的 listen 80 backlog=65535，Go 的 net.Listen("tcp", ":80") 默认只传 128，得用 tcpKeepAliveListener 或第三方包控制
• 该值不能超过 /proc/sys/net/core/somaxconn，且重启后失效，要持久化得写进 /etc/sysctl.conf 并运行 sysctl -p

vm.swappiness 设为 0 并不等于禁用 swap

设成 0 只是让内核「极度不情愿」换出匿名页，但并非完全不 swap。当内存真正耗尽、OOM killer 启动前，系统仍可能把休眠进程页换出——尤其遇到大块连续内存分配失败时。

• 真正禁用 swap 要执行 swapoff -a，并注释掉 /etc/fstab 里所有 swap 行
• 设为 1 比 0 更稳妥：避免极端情况下因完全不 swap 导致 OOM 直接杀进程；设为 10 是数据库类服务常用折中值
• cat /proc/sys/vm/swappiness 看实时值，grep -i swap /proc/meminfo 确认是否还有活跃 swap 区

net.ipv4.tcp_tw_reuse 在 NAT 环境下可能引发连接冲突

开启 net.ipv4.tcp_tw_reuse = 1 能快速复用 TIME_WAIT 套接字，对客户端密集短连场景（如爬虫、微服务调用）有效。但在多用户共享出口 IP 的 NAT 环境（比如 kubernetes Node、云主机集群），它可能把新连接错发到旧连接的服务端残留缓冲区。

• 仅建议在明确是「客户端角色」且出口 IP 独占的机器上启用（例如独立网关机）
• 服务器端不要开——tcp_tw_reuse 对 server-side socket 无效，反而干扰连接跟踪
• 更安全的替代是调小 net.ipv4.tcp_fin_timeout（默认 60 秒）到 30，或用 net.ipv4.tcp_tw_recycle（已从 4.12+ 内核移除，别碰）

rdtsc 指令在虚拟机里不准，clock_gettime(CLOCK_MONOTONIC) 才是真可靠

有些性能敏感程序（比如高频定时器、延迟测量）直接读 rdtsc 指令算时间差，结果在 KVM/QEMU 或容器里跑出来抖动极大，甚至倒退。这是因为虚拟 CPU 的 TSC 频率可能被动态缩放，或跨 vCPU 不同步。

• 一律改用 clock_gettime(CLOCK_MONOTONIC, &ts)，它由内核统一维护，不受虚拟化影响
• 确认系统支持：getconf _POSIX_MONOTONIC_CLOCK 返回 200809L 或更高
• 如果必须用 rdtsc（比如内核模块或裸金属高频采样），需检查 /sys/devices/system/clocksource/clocksource0/current_clocksource 是否为 tsc，且 BIOS 中开启 INVAR_TSC 和 NONSTOP_TSC

事情说清了就结束。内核参数不是调得越激进越好，每个改动都要对应到具体瓶颈点，否则容易把一个慢问题变成另一个不稳定问题。