简介《Linux操作系统调优参数.docx》是一份面向系统运维、后端开发与云计算从业者的Linux性能调优速查文档重点关注高并发Web服务、大数据传输等网络密集型业务下的内核参数配置。压缩包内为1个docx文档整包仅18KB内容短小精悍适合作为随身查阅的运维笔记。目前已有312人浏览学习适合需要快速建立调优认知的工程师参考。文档围绕/proc/sys/net目录中的TCP/IP调优项展开逐项解释接收缓冲区最大值、发送缓冲区最大值、时间戳开关、选择性应答以及窗口缩放机制的作用与适用场景同时覆盖文件系统超级块数量限制、进程记账、控制台重启组合键等内核行为控制参数除了区分临时修改与永久保存两种配置路径还给出可直接套用的默认值示例和写入启动脚本或系统控制文件的具体写法方便读者结合实际带宽与延迟条件做针对性调整在减少误改风险的前提下提升系统性能。1. Linux 操作系统调优参数先从 /proc/sys 里找网络瓶颈网上聊 Linux 操作系统调优参数的内容不少但大多数只贴一串 sysctl 命令不解释为什么这么改。真正决定应用吞吐量的往往集中在/proc/sys/net下几个文件里改对了高并发下网络延迟和丢包是肉眼可见的改善改错了轻则参数不生效重则把生产环境搞到反复重启。这份资料把 TCP/IP 收发缓冲、窗口缩放、时间戳开关、内核 IPC 和虚拟内存参数都摊开了讲还给了 rc.local 和 sysctl.conf 两套持久化方案。适合刚接手 Linux 服务器、被“网络慢”逼着做性能调优的运维和开发照抄配置能落地也知道每行参数背后对应什么代价。2. TCP/IP 网络参数调优收发缓冲与 TCP 特性开关怎么设2.1 收发缓冲区rmem 与 wmem 的默认值和上限TCP 连接的两端各有一个发送缓冲区和一个接收缓冲区。发送方把应用层数据先写进 wmem 对应的发送缓冲由内核协议栈按拥塞窗口和接收窗口决定什么时候发出去接收方把到达的数据放进 rmem 对应的接收缓冲等应用来读。如果接收缓冲太小对端发来的数据会被直接丢弃触发重传如果发送缓冲太小应用写数据时会被阻塞吞吐量上不去。先看当前值再手动调整# 查看当前接收/发送缓冲区的默认值和最大值 cat /proc/sys/net/core/rmem_default cat /proc/sys/net/core/rmem_max cat /proc/sys/net/core/wmem_default cat /proc/sys/net/core/wmem_max # 立即生效的写法重启后失效 echo 256960 /proc/sys/net/core/rmem_default echo 256960 /proc/sys/net/core/rmem_max echo 256960 /proc/sys/net/core/wmem_default echo 256960 /proc/sys/net/core/wmem_max这里四个文件名的含义要拆开看rmem_default是新建 socket 时默认分配的接收缓冲区大小rmem_max是内核允许单个 socket 接收缓冲区的上限wmem同理对应发送方向。资料里给出的 256960 字节约等于 251KB按带宽延迟积估算大致对应 100Mbps 链路、20ms RTT 的场景100Mbps × 0.02s 2Mbit 256000 字节和这个数字非常接近。所以这个值不是拍脑袋定的它是在平衡内存占用和吞吐量之后取的一个中间值。我一般会提醒一句数字单位是字节不是 KB。之前见过有人把 256960 当成 256960KB 写结果内存直接吃满。默认值影响的是新建连接的初始缓冲最大值限制的是应用通过setsockopt(SO_RCVBUF)能申请到的上限。如果只调大默认值不调大 max高负载应用想请求更大的缓冲时仍然会被内核截断。2.2 时间戳与 SACK12 字节开销与重传效率的取舍/proc/sys/net/ipv4/tcp_timestamps控制 TCP 时间戳选项这个机制在 RFC 1323 里定义作用是在每一个 TCP 包的头部增加 12 字节用于更精确地计算往返时间 RTT从而让重传超时和拥塞控制更敏锐。资料里的配置是把它设为 0也就是完全关闭这样做的好处很明显每个包省 12 字节。对于每秒收发几十万个小包的高频接口省下来的带宽相当可观。# 关闭 TCP 时间戳每个数据包省 12 字节 echo 0 /proc/sys/net/ipv4/tcp_timestamps # 开启选择性确认 SACK echo 1 /proc/sys/net/ipv4/tcp_sack关闭时间戳的代价是 RTT 测量精度下降尤其在高延迟、长距离链路上拥塞控制对延迟变化的反应会变钝。资料里给的这个配置更适合内网低延迟、高 PPS 的场景跨地域的链路我一般不关时间戳省下的 12 字节远不如精确重传带来的收益大。sack是选择性确认接收方可以精确告诉发送方“哪些段到了、哪些段丢了”发送方只重传丢失的部分而不是把整个窗口都重传一遍。这个参数在现代内核里默认就是开启的资料里明确建议写 1。注意 SACK 和关闭时间戳并不冲突一个是重传效率一个是报文开销可以独立设置。2.3 窗口缩放64K 上限之外的关键开关TCP 头里的窗口字段只有 16 位最大值是 65535也就是 64KB。如果接收缓冲区超过 64KB比如前面设置的 256960接收方在通告窗口时就没法表达这个数字发送方会以为接收窗口只有 64KB吞吐量被死死限制住。tcp_window_scaling就是解决这个问题的它让 TCP 在握手时协商一个缩放因子实际窗口 16 位窗口值 × 2^缩放因子。# 必须设置为 1否则超过 64K 的窗口无法生效 echo 1 /proc/sys/net/ipv4/tcp_window_scaling # 配合估算带宽延迟积BDP # 带宽 1GbpsRTT 10ms估算需要的接收缓冲 echo $((1000 * 1000 * 1000 / 8 * 10 / 1000))上面的算术结果是 1250000 字节约 1.25MB这是 1Gbps 链路在 10ms RTT 下跑满带宽需要的接收缓冲下限。资料里把rmem_max和tcp_window_scaling放在一起改是合理的但要注意窗口缩放只在握手时协商一次协商完后每个数据包仍然是 16 位窗口字段配合缩放因子解释而时间戳是每个包都带 12 字节两者机制完全不同别混淆。光开窗口缩放还不够内核rmem_max必须同步放大。窗口缩放只是让接收方有能力通告大窗口如果 socket 缓冲区本身被rmem_max卡在上限之下窗口再大也没有实际数据可收。2.4 接收队列与日志限流netdev_max_backlog 和 message_*/proc/sys/net/core/netdev_max_backlog指定网卡接收数据包的速度比内核协议栈处理速度快时允许排队的数据包最大数目缺省值是 300。这个值在千兆网卡、高 PPS 场景下明显偏小数据包在队列里被丢弃会造成上游重传。常见做法是调到 1000 到 3000但要留意这个队列是每个网络设备独立的调得太大反而会占用不必要的内存具体数值要看网卡中断频率和单核处理能力。# 高 PPS 场景适当加大接收队列 echo 1000 /proc/sys/net/core/netdev_max_backlog # 内核日志限流50 表示 5 秒单位 0.1 秒 echo 50 /proc/sys/net/core/message_burst echo 5 /proc/sys/net/core/message_costmessage_burst和message_cost是一组配合使用的内核日志限流参数防止某个进程用大量警告消息刷爆系统日志这算一种轻量级的拒绝服务防护。message_burst的默认值 50 单位是 0.1 秒也就是 5 秒内允许连续写警告的时间窗口message_cost越大系统越倾向于忽略警告消息。这两个参数日常很少动知道它们是做什么的就行不需要盲目调整。3. 内核、文件系统与内存参数除了网络还有这些隐藏瓶颈3.1 SysV IPC 参数消息队列与共享内存的边界在哪里/proc/sys/kernel下的msgmax、msgmnb、msgmni三个参数控制 SysV 消息队列的行为。msgmax指定单条消息的最大长度缺省 8192 字节msgmnb指定一个消息队列中最大的总字节数缺省 16384msgmni指定消息队列标识的最大数目资料里写的缺省是 16。这三个值在很老的内核上是这个水平新内核里msgmni通常会按内存大小自动起算到几千甚至几万如果你在旧系统上跑多进程通信的业务才需要手动关注。共享内存方面有shmmax、shmall、shmmni三个参数。shmmax缺省 3355443232MB限制单个共享内存段的最大大小数据库场景几乎必然要调大shmall是系统可用的共享内存总量shmmni缺省 4096是共享内存段的最大数目。常见调整方向是数据库或消息中间件所在的主机把shmmax调到物理内存的一半左右shmall同步上调。改之前先看当前使用情况# 查看当前共享内存的使用状况 ipcs -m # 调整共享内存段最大大小以字节为单位 sysctl -w kernel.shmmax1073741824 # 1GB sysctl -w kernel.shmall262144 # 单位是页注意不同内核文档口径不一致注意shmall的计量单位在不同内核文档里口径不一致早期文档写“字节”现代内核实际按内存页数计算多翻几个发行版的经验帖也能看到这个坑。改完务必用ipcs -m验证实际生效情况不要只看 sysctl 的输出。3.2 系统行为参数panic、ctrl-alt-del、sysrq 与 printkpanic参数控制内核遇到致命错误时的行为缺省是 0。资料里的原文是“零秒设置在发生内核严重错误时将禁止重新引导”这句话很容易被反着理解。很多人以为panic0是“立刻重启”实际上恰恰相反——它是禁止自动重启服务器会直接挂死在现场等你远程失联后才意识到问题。线上建议设置成一个非零值比如 10让内核在 panic 后 10 秒自动拉起至少保证服务能恢复。# 内核 panic 10 秒后自动重启避免长时间挂死 sysctl -w kernel.panic10ctrl-alt-del控制 CtrlAltDelete 组合键的行为。0 表示捕获这个按键组合并交给 init 程序走正常的 shutdown 流程1 表示不捕获直接非干净关闭相当于拔电源。托管机房里的物理机如果误设成 1运维手滑按到组合键机器就直接硬断电文件系统一致性全靠重启后的 fsck 兜底。这个参数对云主机影响不大但物理机一定要保持为 0。printk有四个值控制内核日志往控制台输出的过滤规则缺省是6 4 1 7位置默认值含义第 1 个6控制台日志级别优先级高于 6 的消息才打印到控制台第 2 个4默认消息日志级别用于没有显式优先级的消息第 3 个1控制台日志级别可设置的最小值第 4 个7控制台日志级别的默认值内核日志级别数字越小优先级越高所以第 1 个值设为 6意味着只有级别 0-5 的消息会打到控制台。如果调试内核驱动想看更多日志把第 1 个值临时调成 7 或 8 就行但别在线上这么干控制台会被刷爆。3.3 文件系统超级块与文件句柄挂载多的场景别忽略/proc/sys/fs/super-max控制超级块处理程序的最大数目缺省 256。每次挂载文件系统都需要分配一个超级块容器宿主机、NFS 客户端、批量挂载磁盘的场景很容易触到这个上限。super-nr是只读的显示当前已分配的超级块数量用来做监控告警很合适如果super-nr接近super-max就该考虑调大了。文件句柄上限是另一个高频踩坑点。资料里给了一个很典型的示例用 sysctl 把/proc/sys/fs/file-max对应的变量改成 16384。文件句柄耗尽时应用会报 Too many open files但很多人先去改 ulimit忘了内核层的file-max才是总闸# 查看当前已分配文件句柄数和上限 cat /proc/sys/fs/file-nr # 调高系统级文件句柄上限 sysctl -w fs.file-max16384file-nr的第一个数字是已分配句柄数第二个是已分配但未使用的句柄数第三个是上限。如果第一个数字长期接近第三个数字除了调大file-max还要排查是不是应用本身存在句柄泄漏。单纯调大上限只是推迟问题爆发的时间。3.4 虚拟内存三组参数buffermem、freepages、kswapd/proc/sys/vm下有三组参数经常被忽略它们共同决定内核怎么管理内存和交换分区。buffermem控制用于缓冲区内存的百分比三个值分别是最低百分比、内存紧张时内核试图维护的百分比、最高百分比缺省2 10 60。freepages控制空闲内存的响应策略三个值分别是最低空闲页数低于这个值只允许内核分配少量内存、积极交换的阈值低于这个值内核会加大 swap 力度、目标空闲页数内核希望保持这个数量的空闲内存缺省512 768 1024。# 查看三组虚拟内存参数的当前值 cat /proc/sys/vm/buffermem cat /proc/sys/vm/freepages cat /proc/sys/vm/kswapdkswapd是内核换页线程三个值控制它一次释放页面的最大数量、最少次数和每次交换写入的页数缺省512 32 8。资料里特别提醒第三个数太大会因为“淹没”请求队列而影响性能——这指的是 swap 写入过于集中磁盘 I/O 队列被写满反而拖慢整体响应。内存充足的服务器上可以适当调大第一个值让 kswapd 更快地释放内存但如果物理内存本身就紧张调大这个值只会让系统更早进入 swap 地狱。调整方向一句话优先保证freepages的目标值合理再动kswapd的带宽参数。4. 持久化方案rc.local 与 sysctl.conf 两种写法怎么选4.1 sysctl 变量命名规则/proc/sys 到点分路径的转换/proc/sys下的每个文件都可以用 sysctl 命令来读写但变量名不是直接照抄路径而是要经过两步转换去掉/proc/sys前缀再把路径里的斜杠换成点。比如/proc/sys/fs/file-max变成fs.file-max/proc/sys/net/core/rmem_max变成net.core.rmem_max。转换规则只有这两条但非常关键因为/etc/sysctl.conf里写的全部是这种点分格式写错一个点或漏掉一层目录sysctl -p就会报 unknown key。# 查看所有可调参数及其当前值 sysctl -a # 按关键字过滤只看网络相关参数 sysctl -a | grep net.core # 临时修改单个参数和 echo 写 /proc 等效 sysctl -w net.core.rmem_max256960用sysctl -w和echo重定向两种方式修改的是同一个地方效果完全一样。区别在于sysctl -w会先做一次变量名校验路径写错了能立刻看到报错而 echo 直接写不存在的文件只会得到一个 No such file or directory排查成本更高。查看某个参数的值时sysctl -a | grep和cat /proc/sys/...也等价前者适合批量确认后者适合脚本里快速精确取值。4.2 rc.local 与 sysctl.conf 的对比和写法资料里给了两套持久化方案。第一套是往/etc/rc.local追加 echo 命令系统启动时逐行执行第二套是写/etc/sysctl.conf由 sysctl 服务在启动早期统一加载。rc.local 的写法直接沿用上一章的 shell 命令#!/bin/bash # /etc/rc.local 追加以下内容 echo 256960 /proc/sys/net/core/rmem_default echo 256960 /proc/sys/net/core/rmem_max echo 256960 /proc/sys/net/core/wmem_default echo 256960 /proc/sys/net/core/wmem_max echo 0 /proc/sys/net/ipv4/tcp_timestamps echo 1 /proc/sys/net/ipv4/tcp_sack echo 1 /proc/sys/net/ipv4/tcp_window_scalingsysctl.conf 的写法是键值对等号两边有没有空格都可以但保持一个空格可读性更好# /etc/sysctl.conf 追加以下内容 net.core.rmem_default 256960 net.core.rmem_max 256960 net.core.wmem_default 256960 net.core.wmem_max 256960 net.ipv4.tcp_timestamps 0 net.ipv4.tcp_sack 1 net.ipv4.tcp_window_scaling 1两种方案对比下来sysctl.conf 明显更优对比项rc.localsysctl.conf生效时机启动流程最后阶段启动早期由 sysctl 服务加载语法shell 命令键值对无解释器依赖错误处理命令失败不报错启动日志里也难找sysctl -p会明确报出 unknown key适用发行版老 SysV init 系统所有主流发行版包括 systemd推荐程度不推荐新系统使用首选方案资料给出 rc.local 的写法有其历史背景但现在的发行版基本都转向 systemdrc.local 的优先级已经被边缘化了。两套方案不需要同时配选 sysctl.conf 就够了。4.3 sysctl -p 加载与配置拆分让参数按功能分文件/etc/sysctl.conf是默认配置文件但现代发行版还会加载/etc/sysctl.d/目录下所有.conf文件。这个机制适合把参数按功能拆开比如网络参数放99-network-tune.conf内核 IPC 参数放90-ipc.conf互不干扰回滚时也只动一个文件。# 建议放自定义参数的目录文件 vim /etc/sysctl.d/99-network-tune.conf # 创建后立即加载验证是否有语法错误 sysctl -p /etc/sysctl.d/99-network-tune.conf # 或者重新加载所有配置 sysctl --system数字前缀决定多个文件之间的加载顺序99 比 90 后加载后加载的参数可以覆盖先加载的。如果同一个参数在/etc/sysctl.conf和/etc/sysctl.d/里都写了最终生效的值以加载顺序靠后的为准这个细节排查问题时非常关键。加载完成后习惯性用cat /proc/sys/net/core/rmem_max确认一下别只信配置文件的输出。提示每次改 sysctl.conf 之前先cp /etc/sysctl.conf /etc/sysctl.conf.bak.$(date %F)这是花十秒钟能买到的后悔药。5. 避坑与排查改坏参数后的恢复出路5.1 改完没生效先分清是查询姿势不对还是真没写进去现象执行了sysctl -w net.core.rmem_max256960再用sysctl -a | grep rmem_max查询看到的还是旧值或者重启后参数全部回到默认。原因最常见的是变量名写错比如把net.core.rmem_max写成net.core.rmem_max多了空格或者net/ipv4混进去变成net.ipv4.tcp_sack和net/ipv4/tcp_sack两种写法搞混。另一个可能是/proc/sys下某些文件是只读的只有内核模块加载后才能通过特定接口修改比如super-nr这种纯信息文件。解决先用cat /proc/sys/net/core/rmem_max直接对文件确认这是最终真相sysctl -a只是它的另一种表现。确认文件内容确实改了再查配置持久化。如果sysctl -p报错把报错行原样贴回配置文件对比路径和变量名99% 是拼写问题。5.2 窗口缩放开了但吞吐量没起色现象tcp_window_scaling1、rmem_max调到 8MB用 iperf3 一测带宽还是只有几十到几百 Mbps和调之前没区别。原因内核参数只是设了一个上限实际 socket 缓冲区大小由应用自己决定。很多应用根本不调用setsockopt(SO_RCVBUF)用的还是rmem_default的默认值窗口再大也是空转。还有一种情况是中间链路设备比如某些老交换机或安全设备不支持 window scale 选项握手协商时缩放因子自动降级为 0。解决先看连接实际协商出来的窗口参数再下结论。ss -tni输出里的wscale:7表示缩放因子是 2^7如果看到wscale:0说明协商失败了。测试时用 iperf3 显式指定窗口大小排除应用层因素# 带窗口参数的带宽测试 iperf3 -c 目标IP -t 60 -w 2M # 查看连接的窗口缩放和缓冲区 ss -tni | head -305.3 panic0 不是“立刻重启”是“禁止重启”现象某台物理机内核 panic 后彻底失联带外管理口能看到机器还在通电但系统完全无响应只能去机房手动重启。原因/proc/sys/kernel/panic缺省值是 0文档原文明确写的是“禁止重新引导”。0 不是“立刻重启”而是“永不自动重启”。很多人看到 0 就直觉以为是不等待、马上重启这个方向完全反了。解决线上服务器设置成非零值比如panic10内核 panic 后 10 秒自动重启配合 kdump 抓现场再分析。物理机务必把这个值写进 sysctl.conf同时确认带外管理可用别让一次 panic 变成一次机房之旅。5.4 rc.local 在 systemd 时代经常悄悄失效现象把 echo 写入/etc/rc.local重启后cat /proc/sys/net/core/rmem_max还是旧值但/etc/rc.local文件里明明有内容。原因systemd 发行版上 rc.local 默认不是启用的rc-local.service处于 disabled 状态即便服务启用/etc/rc.local如果没有可执行权限或者首行没有#!/bin/bash脚本也会被跳过。这三个问题任何一个都能让整个文件静默失效而且启动日志里未必有明显报错。解决先systemctl status rc-local看服务状态再检查文件权限和首行。最省事的方案是放弃 rc.local把参数写进/etc/sysctl.d/99-network-tune.conf再sysctl -p加载绕开整个 shell 执行链路。5.5 一次改太多参数翻车了都不知道哪行的锅现象把网络、IPC、虚拟内存的参数一次性全部写入 sysctl.conf重启后系统变慢甚至启动过程卡在挂载或服务启动阶段。原因参数之间会互相影响。比如freepages的目标值调得太高内核会持续积极地交换内存导致所有进程频繁缺页msgmni调得太大每个消息队列都占用内核内存总量控制不住tcp_*参数改得太激进内存占用上升的同时还可能影响同机其他业务。同时改十个参数出了问题根本没法定位是哪个。解决一次只改一个子系统改完立刻验证验证通过再动下一组。改之前先sysctl -a /tmp/sysctl-baseline.txt保存基线回滚时直接对比。sysctl.conf 改了之后不要急着reboot先sysctl -p临时加载观察一段时间确认稳定再重启。这套流程多花十分钟能省掉一次事故复盘会。6. 验证调优效果用 nstat 和 ss 量化前后差异6.1 用 nstat 与 ss 采集前后快照改参数之前先采集一次基线改完再采集一次用 diff 对比。这样每一组参数调整的收益和代价都是数字可查的而不是“感觉快了”这种玄学结论。# 改参数之前采一次基线 nstat -az /tmp/net-baseline.txt ss -tni /tmp/ss-baseline.txt # 改完参数之后采第二次 nstat -az /tmp/net-after.txt ss -tni /tmp/ss-after.txt # 对比网络统计计数器的变化 diff /tmp/net-baseline.txt /tmp/net-after.txtnstat -az输出的是内核网络协议栈里所有计数器的值重点看这几列TcpRetransSegs重传次数、TcpExtTCPTimeouts超时次数、TcpExtTCPLossUndo拥塞窗口撤销次数。重传次数明显下降说明丢包缓解也就是缓冲区和窗口的调整起了作用如果重传没降反升说明缓冲区调大了但中间链路或拥塞控制反而出了问题。ss -tni看连接级细节wscale:7表示缩放因子 2^7窗口上限可以到 65535×128send-q和recv-q表示发送和接收队列里积压的字节数。如果recv-q长期接近满值说明接收缓冲还是不够或者应用读得太慢。6.2 带宽对比iperf3 实测的读法参数调整最终要落到带宽和延迟的实测数据上。iperf3 是最常见的验证工具测试时注意固定窗口和时长避免变量太多# 服务端 iperf3 -s # 客户端固定窗口 2MB测试 60 秒 iperf3 -c 目标IP -t 60 -w 2M输出结果里有两个关键数字SUM行的带宽值以及每个时间间隔内的retr重传次数。如果-w 2M下带宽能跑满但默认窗口下跑不满说明瓶颈在 socket 缓冲区设置而不是链路本身如果两种窗口下带宽都没变化问题大概率在网络中间设备或对端接收能力。做完调优后顺手看一眼 CPU 的软中断占用mpstat -P ALL 1确认是不是单核软中断已经打满这种情况网络参数怎么调都没用要做的是多队列和网卡绑核。从那以后我每次动/proc/sys下的参数都强制走一遍这套流程先备份 sysctl.conf再记录 nstat 基线改完一组参数必须做一次 iperf3 复测不达标就回滚换下一组。调优不是把参数都调到最大而是找到当前业务模型下最合适的平衡点。希望帮到你。本文还有配套的精品资源点击获取