简介这是一份面向Linux系统管理员、运维工程师及网络应用开发者的调优参数速查文档重点解决高并发、高带宽场景下网络吞吐与延迟性能瓶颈。文中对TCP/IP核心参数逐一拆解rmem_max与wmem_max决定收发缓冲区上限大流量或高并发连接可适当调大tcp_timestamps置0可省去包头12字节开销tcp_sack开启后允许接收方通告已收到分段提升丢包重传效率tcp_window_scaling则突破64K窗口限制显著提升长肥网络下的带宽利用率。同时对比了echo命令临时调整与写入/etc/sysctl.conf持久化两种配置思路方便直接借鉴落地。除网络参数外还涵盖/proc/sys/fs/super-max、kernel/acct、ctrl-alt-del等文件系统与内核行为设置帮助读者形成从网络到内核的完整调优认知。资源共1个docx文档约18KB轻量易用适合放在手边随时查阅已有312人学习是部署Linux服务器、排查网络性能问题时的常用参考。1. 一份调优参数文档救不了不做功课的人先想清楚它管的是哪一层很多刚接手 Linux 服务器的朋友第一反应是找一份“Linux操作系统调优参数.docx”打开、复制到 /etc/sysctl.conf、执行 sysctl -p认为调优就算完成了。我也曾这么干过结果是数据库服务器改了 vm.swappiness 之后内存回收策略突变热数据被提前换出查询延迟涨了近一倍回滚配置花掉的时间比调优还长。参数表本身没有错错的是把一份调优文档当成万能药。Linux 调优参数解决的是内核资源调度策略不是硬件性能翻倍。它的真实价值只在你先搞清楚“这台机器跑什么业务、压力集中在哪个子系统、当前基线长什么样”之后才能体现出来。下面按参数结构、四组调优项、落地顺序、避坑清单、验证沉淀这条路径把这套 docx 背后的完整操作流程讲清楚。2. 先认识参数表结构sysctl、/proc 伪文件、内核 cmdline 三条来源打开参数文档你可能以为它是一堆随便看看的 keyvalue。但 Linux 调优参数并不是一段神秘代码它是内核运行时对外暴露的可调开关。绝大多数参数通过 sysctl 接口读写底层对应 /proc/sys 目录下的伪文件。你在 docx 里看到的 vm.swappiness实际上是 /proc/sys/vm/swappiness 这个文件的映射。搞懂这个对应关系后面所有操作都有迹可循。2.1 参数在 /proc 下的对应关系先用几条常用命令读出当前状态对于刚接触参数调优的人与其死记硬背不如先掌握怎么查看当前值、怎么列出可用项。下面这几条命令基本构成了一半的调优动作# 查看系统中所有可调参数行数通常在 1500 到 2500 之间 sysctl -a | wc -l # 按子系统前缀过滤例如只看内存相关参数 sysctl -a | grep ^vm\. # 查看单个参数当前值 cat /proc/sys/vm/swappiness # 把整套参数快照到文件作为调优前的基线 sysctl -a /tmp/sysctl_baseline_$(date %F).txt查看单个参数我习惯直接cat /proc/sys/vm/swappiness即使 sysctl 命令不可用也能读到值。sysctl -a输出上千行用 grep 过滤是常规动作。把当前状态全部导出到带日期文件里是后续对比的原材料。很多运维出问题后才问“之前值是多少”到那时候基线已经丢了。关于伪文件的另一个关键点这类文件虽然是普通文本方式读写但内核会做严格的类型和范围检查。vm.swappiness 只接受 0 到 100 的整数net.ipv4.ip_local_port_range 必须给两个端口号写入越界或类型错误内核直接返回 Invalid argument不会给你任何缓冲。所以调优文档里如果出现明显超出取值范围的数值要么是文档笔误要么是面向特定内核版本不要盲目照抄。2.2 同一份调优文档在发行版间表现不同内核版本是分水岭“照着调优文档抄结果机器一直报错”这种情况我遇到不止一次。问题通常不在数值而在参数在当前内核里根本不存在。发行版之间差异最大的是内核版本和编译选项不是路径。举个例子net.ipv4.tcp_tw_reuse 在 Linux 4.12 前后的语义有过调整到了新内核这个参数默认状态本身就不同如果内核没有编译 CONFIG_NET_NS网络命名空间相关参数根本不会出现在 /proc/sys 里。同一份 docx 在 CentOS 7 上 sysctl -p 顺利通过换到 openEuler、麒麟或统信 UOS 这类国产 Linux 发行版上很可能直接提示 No such file or directory。所以动手前先记录三个信息内核版本、发行版版本、CPU 架构。如果参数表没有标注适用内核版本这份文档只能当参考书不能当生产环境的直接配置脚本。# 查看内核与发行版信息 uname -r cat /etc/os-release | grep -E ^(NAME|VERSION) # 检查某个参数在当前内核是否存在 ls /proc/sys/net/ipv4/tcp_tw_reuse echo exists || echo missing2.3 参数生效有三个入口sysctl 配置、内核 cmdline、运行时写入还有一个常见误解是以为一个参数只有一个写入口。实际上最终生效值可能来自三个地方生效时机和覆盖关系各不相同。# 内核启动参数开机最早阶段生效例如 transparent_hugepagenever cat /proc/cmdline # sysctl 配置文件/etc/sysctl.conf 以及 /etc/sysctl.d/*.conf cat /etc/sysctl.conf # 运行时立即修改马上生效重启后失效 sysctl -w vm.swappiness10sysctl.d 下的文件会按文件名顺序加载靠后的覆盖靠前的。这就是为什么很多人习惯用 /etc/sysctl.d/90-custom.conf 这样的命名目的是让自定义配置最后加载覆盖发行版默认值。内核 cmdline 里的参数在引导阶段固定sysctl 改不了它运行时 sysctl -w 优先级最高但重启即失。理清这三条路后再看参数文档你会更容易判断某个参数应该写进 sysctl.conf、改 GRUB还是得用 systemd 服务在启动后补设。如果文档里只给了一行 keyvalue 却没标注持久化方式那就不是一份可直接执行的清单。3. 按业务负载调参内存、CPU、文件系统、网络四组高频调优点读参数文档时最容易犯的错是“横着读”从第一行抄到最后一行。我习惯按子系统竖着读把参数分成内存、CPU 与调度、文件系统与 I/O、网络四组再结合业务负载判断要不要动。下面给的数值都是生产环境用过的“可用起点”不是绝对真理需要压测确认。3.1 内存组先看内存画像再动 swappiness、overcommit、dirty page内存参数最容易把系统改出问题也最容易出现“感觉变快了”的错觉。先观察实际压力# 查看内存总量和交换分区使用 free -h # 每秒采样一次看 si/so 是否持续不为 0 vmstat 1 5free -h 看的是剩余量vmstat 里的 si、so 字段才反映交换分区的换入换出。如果 si/so 长期不为 0说明内存压力已经不小这时候靠调参数只是缓解症状不如想想该扩内存还是降缓存。vm.swappiness 默认通常是 30范围 0 到 100。值越低越倾向于回收文件页而不是把匿名页换到 swap数据库、缓存这类的延迟敏感服务在内存充足时降到 10 或更低是常见做法。注意 swappiness0 不代表禁用 swap它在极端内存压力下仍然会换页所以我不建议设成 0留个 10 更稳妥给极端情况留条退路。vm.overcommit_memory 是另一个高频参数但副作用很大。0 是启发式模式也是多数发行版默认1 是总是允许超卖适合大量小进程、内存波动大的场景OOM 风险高2 是严格模式配合 overcommit_ratio 使用适合防止单进程吃光内存的场景。# 查看当前策略 cat /proc/sys/vm/overcommit_memory # 严格模式示例生产环境谨慎执行 sysctl -w vm.overcommit_memory2 sysctl -w vm.overcommit_ratio90overcommit_memory2 会把允许分配的内存限制为“物理内存乘以上述比例再加交换分区”。数据库启动时申请大块共享内存很容易直接失败。我见过不止一个案例改完这个参数后 PostgreSQL 再也起不来。数据库和 Java 服务我不建议动这个参数除非你非常清楚自己的内存模型。再往下是 dirty page 相关参数。vm.dirty_background_ratio 和 vm.dirty_ratio 决定脏页攒到多少开始后台回写和强制回写。调高能提升顺序写吞吐但断电时丢数据的窗口变大。我的倾向是数据库机不动它日志型或大数据导入场景把 background_ratio 从 5 调到 10、dirty_ratio 从 20 调到 30减少小规模写停顿。每次只改一个方向改完观察不要同时调一串参数。3.2 CPU 与调度NUMA 亲和、内核自动迁移、cgroup 限流的介入时机多核时代的 CPU 调优核心不是“提高主频”而是让线程落在该落的核上。先看拓扑# 查看 NUMA 节点与 CPU 分布 lscpu | grep -E NUMA|CPU\(s\) numactl --hardware单实例重负载应用典型的如数据库、高吞吐缓存服务建议用 numactl 固定到本地节点避免跨 NUMA 访问内存numactl --cpunodebind0 --membind0 ./my_appkernel.numa_balancing 默认可能开启内核会自动迁移内存页提升命中率。但迁移本身有开销对延迟敏感的业务我通常选择关闭sysctl -w kernel.numa_balancing0进程调度层面kernel.sched_autogroup_enabled 在服务器上比较有争议。它按会话自动分组并分享 CPU 时间对交互式终端友好但服务器上多个并发任务可能互相干预。在跑批任务的机器上我会关掉它让调度器按单进程公平分配。容器场景则要管 cgroup 的 cpu.cfs_quota_us 和 cpu.cfs_period_us这两个不是 sysctl而是普通文件位于 /sys/fs/cgroup/cpu/ 下。看到 /sys/fs/cgroup 开头的文件就别再往 sysctl.conf 里写了那是容器编排层的事情。3.3 文件系统与 I/OI/O 调度器、挂载选项、文件句柄与异步 I/O文件系统调参往往不在 sysctl 里而在块设备队列和挂载选项里。先看当前状态# 查看块设备当前的 I/O 调度器 cat /sys/block/sda/queue/scheduler # 查看文件系统挂载参数 mount | grep -E ext4|xfs对 NVMe SSDI/O 调度器的影响已经很小多数发行版默认 none 或 mq-deadline。机械盘或混合存储下mq-deadline 通常比 none 更适合数据库吞吐密集的日志盘可以试 bfq前提是内核编了它。不要盲目把所有盘都改成 none一切以压测结果为准。挂载选项最常见的调整是加 noatime避免读文件时更新访问时间减少写盘次数。数据库场景的 barrier、日志模式这类可靠性参数不要轻易动除非你完全能承担断电的不一致风险。文件句柄是另一个高频调优点。fs.file-max 是系统级帽子进程的 ulimit -n 是进程级门两层都要看# 查看系统文件句柄上限与实际使用 sysctl fs.file-max cat /proc/sys/fs/file-nr/proc/sys/fs/file-nr 输出三列第一列已分配、第三列系统上限。当已分配数接近上限时需要调 fs.file-max但更常见的情况是系统上限很高进程自己的 limit 卡在 1024应用仍然报 Too many open files。所以调优文档里要把系统参数和进程限制分开写不然照抄只能解决一半问题。还要提一个隐蔽参数 fs.aio-max-nr数据库和高并发磁盘场景容易踩。异步 I/O 请求数一旦打满MySQL、ClickHouse 会报 io_setup: Cannot allocate memory日志里往往只有这一句内存却明显足够。提高上限即可sysctl -w fs.aio-max-nr10485763.4 网络组连接跟踪、accept 队列、本地端口范围网络调优最容易连锁翻车。先看连接跟踪表和当前连接状态# 当前连接状态摘要 ss -s # 连接跟踪表使用情况 sysctl net.netfilter.nf_conntrack_max sysctl net.netfilter.nf_conntrack_countnf_conntrack 表满是最经典的生产事故。现象是 dmesg 报 nf_conntrack: table full, dropping packet外部连接大量超时服务端看起来却没什么流量。原因是并发连接数超过了表容量。对策如下sysctl -w net.netfilter.nf_conntrack_max1048576注意调大表容量会占用内核内存。8GB 内存的机器我不会拉到 100 万设到 26 万或 52 万更合适。表太大导致 OOM比连接被丢更让人头大。连接队列方面net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 在高并发短连接场景要同步调sysctl -w net.core.somaxconn65535 sysctl -w net.ipv4.tcp_max_syn_backlog65535但实际 accept 队列长度由应用层的 listen(fd, backlog) 决定通常取 backlog 和 somaxconn 的较小值。如果应用层 backlog 写死 128系统调成 65535 也白搭这就是所谓的“应用不配合”陷阱。本地端口不足的场景同样常见sysctl -w net.ipv4.ip_local_port_range10240 65535出站并发特别高时日志会出现 Cannot assign requested address此时再考虑调端口范围。调之前先确认没有服务占用端口冲突的排错比端口耗尽更糊弄人。4. 落地执行顺序先基线、再快照、最后固化别跨过任何一步直接套用文档参数修改前不做记录这是把调优变成玄学的根源。可复现的调优流程应该是先收集基线、再小步改动、最后持久化并验证。顺序不能反。4.1 建立基线用 vmstat、iostat、mpstat 记录改动前的真实状态改参数之前先抓一组“当前状态”数据。调优结束后要回答的核心问题是“跟改动前相比系统到底变好了没有”没有基线就没有结论。# 存储内存、CPU、swap 统计每 2 秒一次共 30 次 vmstat 2 30 /tmp/vmstat_before.txt # 存储磁盘 I/O 扩展统计 iostat -x 2 10 /tmp/iostat_before.txt # 存储每核 CPU 使用率和软中断分布 mpstat -P ALL 2 10 /tmp/mpstat_before.txtvmstat 中 r 列代表正在运行的进程数si/so 代表换入换出iostat 的 w_await 能反映写延迟mpstat 的软中断列能看多队列网卡是不是被某个核独自扛住。这组命令不依赖第三方监控组件任何时候都能跑。采集时间要贴近问题窗口。如果线上故障集中在晚上 20 点到 22 点就别拿凌晨 3 点的数据做基线负载特征完全不一样。采样的同时把业务指标留底QPS、响应时间、错误率。系统指标告诉你资源紧不紧张业务指标才能证明改完到底有没有用。4.2 修改前先拍照当前所有参数快照留一条可靠的后悔药安全落地的前提是随时可以回滚。很多参数通过 sysctl.conf 持久化后重启后仍然生效一旦改错连重启都不一定救得回来。所以改动前必须把当前状态完整地拍下来。# 全量快照 sysctl sysctl -a /tmp/sysctl_before_$(date %Y%m%d_%H%M).txt # 挂载参数与内存信息也一起归档 mount /tmp/mount_before_$(date %Y%m%d).txt cat /proc/meminfo /tmp/meminfo_before_$(date %Y%m%d).txt快照的意义是在怀疑参数改错的时候把当前值和快照 diff 一下立刻知道哪个参数被动过。这比靠记忆回滚可靠得多。写入配置时我的习惯是新建独立文件而不是直接改 /etc/sysctl.confcat /etc/sysctl.d/90-tuning-custom.conf EOF # 数据库专用参数 vm.swappiness10 net.core.somaxconn65535 fs.file-max2097152 EOF # 不重启地加载配置 sysctl --system独立文件的好处是回滚方便把这个文件移走再执行一次 sysctl --system 就恢复默认。90 前缀保证优先级较高避免被发行版默认文件覆盖。sysctl --system 会按 /etc/sysctl.d/*.conf 的顺序加载比旧版 sysctl -p 更全面也支持直接重读全部配置。4.3 持久化有三条路sysctl 配置、GRUB cmdline、systemd 补设一部分参数写 sysctl 没有用因为它们根本不在 sysctl 的管理范围内。落地执行时要把参数分好类直接支持 sysctl 的写进 /etc/sysctl.d/ 下独立文件。引导早期就要确定状态的比如透明大页 THP必须改 GRUB cmdline。需要在某个服务启动后生效的可以写 systemd 单元通过 oneshot 服务在开机后补设。透明大页是典型例子。它的开关在 /sys/kernel/mm/transparent_hugepage/enabled临时关闭可以直接 echo never 写入重启后恢复。要持久化就得改 /etc/default/grub在 GRUB_CMDLINE_LINUX 里加上 transparent_hugepagenever再 update-grub 重启。这类参数写进 sysctl.d执行 sysctl --system 时大概率飘红 read-only file system因为它根本不归 sysctl 管。虚拟化环境还有额外一层因素在 VMware 里安装 Linux 后如果虚拟机配置的是超分配 CPU宿主机的切换开销会导致调参收益打折如果绑核手动设置 CPU 亲和又可能和 vCPU 固定策略冲突。遇到虚拟机场景先确认绑核还是超分配再谈调度参数不然容易越调越慢。4.4 改完验证主动压测加被动观察保留足够长的时间窗口调优参数往往是叠加生效刚改完测试十分钟很难暴露问题。我的经验是“压测确认方向在线观察一周”。压测必须使用同一套脚本、同一组并发模型否则数据之间没有可比性。压测现场保留原始输出压测命令和参数随手记到本次调优文档里。观察期内重点看 P99 延迟和错误率不要只盯平均值均值容易被长尾掩盖。如果一周内指标比改动前更平坦、更可预期才能谈“确认有效”。5. 调优避坑与排查五个真实翻车现场按现象、原因、解决记录参数调优踩坑是常态以下五个问题我都实际遇到过按现象、原因、处理三部分记录。它们覆盖了参数不存在、内存策略误用、队列调优失效、文件系统挂载失败、容器内配置无效这几类最常见的翻车点。5.1 现象sysctl -p 报错 No such file or directory从旧文档复制配置或者跨发行版抄参数执行 sysctl -p 时屏幕滚过一串 No such file or directory后面的行也不再加载。更迷惑的是这些报错参数看起来都很眼熟。原因是参数在当前内核中不存在要么对应模块没有加载要么参数已在较新内核中改名或删除。tcp_tw_recycle 就是最典型的例子老文档里常出现新内核基本已移除。处理方式分两步。先用 sysctl -a 确认当前内核有没有这个参数如果确认是模块提供的先 modprobe 对应模块再加载配置。稳健的做法是在脚本里先判断伪文件是否存在再写入if [ -f /proc/sys/net/ipv4/tcp_tw_reuse ]; then echo 1 /proc/sys/net/ipv4/tcp_tw_reuse fi这能防止单个参数错误导致整个配置加载中断后续参数全部没有生效。5.2 现象改完 vm.overcommit_memory2 后数据库进程启动失败在跑 PostgreSQL 的机器上做“强制控制内存超卖”实验把 overcommit_memory 从 0 改成 2然后数据库直接起不来了。日志报共享内存分配失败内存总量明明很多。原因是严格模式下内核会逐次检查内存分配是否超过允许比例数据库启动时要预留大块共享内存而默认的 overcommit_ratio 不足以承接。处理办法确实要用严格模式的话先把 overcommit_ratio 调大再重启应用。但更稳妥的判断是数据库类服务尽量不要离开 0 模式。遇到共享内存分配失败先去查 kernel.shmmax 和 kernel.shmall这两个值决定单块共享内存的上限sysctl kernel.shmmax sysctl kernel.shmall调内存参数前务必确认业务进程的内存申请模型这是拿真金白银换来的教训。5.3 现象somaxconn 调大后接口延迟不降反升高并发短连接场景我把 net.core.somaxconn 调到 65535压测结果反而比默认更差平均延迟涨了约 30%。压测曲线看起来非常古怪。原因是应用层没有同步调整 listen backlog。系统把内核队列上限提高了但应用进程仍然用默认 backlog比如 Nginx 默认 511、Tomcat 默认 100实际 accept 队列长度由双方共同决定光改内核不解决问题还增加了排序和队列切换的复杂度。处理办法是让应用层配合。Nginx 在 listen 指令里指定 backlog65535其他语言在 socket listen 调用处传入更大的值。同时用 ss -lnt 观察 Send-Q 列它显示的是应用层 backlog 设置而不是系统 somaxconn。如果 Send-Q 一直是 128、511 这类数字说明系统参数改了也没被真正用上。5.4 现象改完挂载选项重启后直接进救援模式在 /etc/fstab 中调整某数据分区的挂载选项比如加 noatime 和 barrier重启后系统直接卡在救援模式文件系统挂载不上。原因是挂载选项不被当前文件系统支持或者对应分区设备名写错。fstab 解析失败时系统启动流程会中断等待人工介入。快照类虚拟机里更常见设备路径存在且不会反复变化的问题比较小但物理机换过盘后盘符漂移很容易导致这种情况。处理方式不要再直接编辑生产环境的 fstab先在已挂载状态下用 mount -o remount 验证选项能否被接受mount -o remount,noatime /data确认无误后再写入 fstab。如果系统已经进不去通过救援模式把 fstab 里对应行注释掉重启验证之后再补挂载。注意别在救援模式里顺手改其他配置分清哪些是本次故障引入的变更。5.5 现象容器里执行 sysctl 没有报错但配置根本没有生效在 Kubernetes 或 Docker 容器内执行 sysctl -w vm.swappiness10 没有任何报错进入容器查看却还是老值。以为是写成功了实际上内核根本没接招。原因是容器里的 /proc/sys 是只读或半只读视图绝大多数 vm.、fs.参数没有实现命名空间隔离写入请求被静默忽略。容器运行时最多放行一小部分安全的网络参数其他全局参数不允许容器内独立设置。处理办法在宿主机层面调优不要把容器内进程当成操作系统的 init 去管理内核参数。容器编排环境确实需要隔离配置时先确认运行时是否支持对应 sysctl 白名单例如 Kubernetes 里 net.core.somaxconn 可能被允许而 vm.swappiness 通常是禁止项。不支持的情况下宁可当作全局参数在宿主机设置做到行为可预期也不要留给容器内静默失败。6. 验证调优结果并把它沉淀成一份可追溯的参数表参数改完不是终点最后一步是用对比数据回答“到底有没有用”并且把过程沉淀成可追溯的文档。这两个动作决定你下次遇到同类问题能不能直接复用。6.1 用同一套压测工具做前后对比对比实验最关键的是控制变量。调优前用 ab 压测 20 万请求调优后换个时间再压如果两者并发数和请求路径完全一致结果才有可比性# 调优前 ab -n 200000 -c 200 http://127.0.0.1/api /tmp/bench_before.txt # 调优后使用完全相同参数 ab -n 200000 -c 200 http://127.0.0.1/api /tmp/bench_after.txt对比的维度要覆盖 P99 延迟、吞吐、错误率再看系统侧的上下文切换、软中断分布。P99 下降明显且系统平均负载没有恶化说明方向对了如果吞吐没变只有 CPU 使用率上下乱跳那只是把压力换了种形态不算优化成功。6.2 把变更记录整理成五列表格杜绝调优黑匣子三个月后再看一串 sysctl -w 命令很难记起每条对应什么业务、为什么这么设。我习惯每次调优都沉淀成一张五列表格参数、前后值、适用条件、回滚方式一目了然参数调优前调优后适用条件回滚方式vm.swappiness3010内存充足、延迟敏感的数据库sysctl -w vm.swappiness30net.core.somaxconn12865535短连接高并发网关sysctl -w net.core.somaxconn128fs.file-max1024002097152文件句柄不足且确认 ulimit 已调sysctl -w fs.file-max102400表格里的原则是必须有“适用条件”和“回滚方式”这两列是我从多次故障里换来的经验。只写参数和值的调优文档是危险的它会让后来者以为所有机器都适用同一套数值而标明了业务前提和回滚路径的文档任何接手的人都能安全操作。最后一个习惯改完参数后把当天的 sysctl 快照、压测报告和变更说明放进同一个目录用日期和主机名命名。下次系统出现性能波动先解压这份归档确认是不是最近一次变更引起的。这个动作帮我避免过很多次玄学排障希望也能帮到你。本文还有配套的精品资源点击获取