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
