sysctl -p 仅重载配置，不报错≠生效；必须用 sysctl 参数名 或 cat /proc/sys/路径 验证运行值，注意内核版本兼容性及配置加载方式（如 systemd 系统应使用 sysctl --system）。
直接改 /etc/sysctl.conf 并执行 sysctl -p 就能生效，但多数人卡在参数选什么、为什么这么设、改完没效果——根本原因是没区分场景，也没验证是否真正加载。
怎么确认参数已生效而不是“看起来改了”
改完 /etc/sysctl.conf 后，sysctl -p 只是重载配置，不报错≠参数已写入内核。必须手动验证：
- 用
sysctl net.core.somaxconn查单个值，比翻配置文件更可靠 - 检查
/proc/sys/net/core/somaxconn文件内容，它和运行时值完全一致 - 如果
sysctl -p报error: "net.ipv4.tcp_tw_recycle" is an unknown key，说明该参数在较新内核（≥4.12）已被移除，强行写入会静默失败 - 某些发行版（如 RHEL 8+/Ubuntu 20.04+）默认启用
systemd-sysctl，此时应把配置放到/etc/sysctl.d/99-custom.conf并运行sysctl --system
高并发服务必调的三个关键参数及其取值逻辑
不是所有参数都值得动，以下三个直接影响连接建立成功率和吞吐上限，且有明确调整依据：
-
net.core.somaxconn：全连接队列上限。Nginx/Redis 等监听 socket 的listen()第二个参数若大于此值，会被截断。生产环境建议 ≥65535，低于 1024 容易出现ListenOverflows（可通过ss -s查看） -
net.ipv4.tcp_max_syn_backlog：半连接队列长度。需 ≥net.core.somaxconn，否则三次握手第二步（SYN-ACK）就可能丢包。设为 8192 或 16384 较稳妥，过高反而增加内存开销 -
net.core.netdev_max_backlog：网卡软中断收包队列。当网卡收包速率 > 内核处理速率时，包在此排队。千兆以上网卡建议 ≥5000；万兆环境至少 10000，否则出现netstat -s | grep "packet receive errors"中的dropped计数上升
缓冲区参数（rmem/wmem）不能只设 max，必须配 tcp_rmem/tcp_wmem 三元组
只改 net.core.rmem_max 和 net.core.wmem_max 是无效的——TCP 栈实际使用的是 net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem，它们是“最小、默认、最大”三值数组：
- 例如
net.ipv4.tcp_rmem = 4096 131072 2097152表示：每个 TCP socket 至少分 4KB 接收缓存，空闲时默认用 128KB，最大可扩到 2MB - 设得太大会浪费内存（每个连接都按最大值预分配）；太小则在高 BDP（带宽×延迟）链路上触发频繁 ACK 和窗口收缩
- 推荐起始值：
tcp_rmem = 4096 262144 4194304（4K/256K/4M），tcp_wmem = 4096 262144 4194304，再根据ss -i输出中的rcv_space和snd_cwnd实际观察调整 - 注意：
net.core.rmem_max必须 ≥tcp_rmem的第三项，否则内核会自动降级为rmem_max值
BBR 拥塞控制开启后，别忘了关掉冲突参数
启用 net.ipv4.tcp_congestion_control = bbr 能显著提升长肥管道（Long Fat Network）吞吐，但以下参数与 BBR 不兼容，必须禁用：
-
net.ipv4.tcp_sack = 0：BBR 依赖 SACK 获取精确丢包信息，关掉会导致性能反降 -
net.ipv4.tcp_timestamps = 1：BBR 需要时间戳计算 RTT，禁用将导致 BBR 退化为 Reno -
net.ipv4.tcp_window_scaling = 1：BBR 在高带宽下依赖大窗口，必须开启 - 旧教程常写的
tcp_tw_recycle = 1在 NAT 环境下会导致连接失败，现代内核已移除，切勿添加
真正容易被忽略的是：BBR 只对新建立的连接生效。改完参数后，必须重启应用或等待旧连接自然释放，否则 ss -i 里仍显示 reno 或 cubic。
