1. 项目复盘调优之前先想清楚三件事接手第一个Linux内核参数调优项目时我的第一反应和大多数同行一样赶紧拉出sysctl列表把那些看起来眼熟的参数全部看一遍然后搜一搜某某参数的最佳值——结果搜了一上午发现网上答案互相矛盾有人建议把net.core.somaxconn改成1024有人建议改成4096还有人说要配合net.ipv4.tcp_max_syn_backlog一起调。看了一圈反而更不敢动了。那次项目给我最大的教训是内核参数调优从来不是改参数本身而是一套完整的定位、验证、回归的诊断过程。你要调什么必须先从业务现象出发搞清楚是文件句柄不够了还是连接队列溢出了还是内存回收不及时导致进程被OOM Killer误杀。每一种表象背后对应的参数组完全不同调错了不仅不解决问题还会把原本正常的子系统拖垮。所以我后来给自己定了一条规矩接到内核调优相关的任务先把以下三件事想清楚再动手。第一先把症状描述量化。比如服务不稳定这种描述不能用服务在流量高峰时段QPS超过8000后accept队列开始出现大量超时错误日志里频繁出现connection reset by peer才是可定位的。现象越具体越能帮你在内核参数的长长清单里快速锁定排查方向。第二先确认是操作系统的问题还是业务代码的问题。很多所谓的内核参数问题最后定位出来其实是应用层没做连接复用、没有设置合理的超时时间、线程池大小配置不当。内核参数只是背锅侠。我在好几个项目里都遇到过类似情况改完fs.file-max、ulimit之类的参数之后业务侧稍作优化效果反而比一路调内核好得多。第三所有调忧必须先做基线采集。改之前跑一遍压测记录QPS、TPS、响应时间、错误率、系统CPU/内存/网络/句柄等指标。改完之后用同样的压测模型再跑一遍用数据说话而不是凭感觉说好像变快了。一套基线数据能让你在问题反复时快速回退也能让后续的每次调整都有依据。想清楚这三点之后的事情其实就顺理成章了先分清参数类别理解背后原理再按项目实际场景逐组调整最后回归验证。这篇文章我把当时项目里用到的参数分类、调整步骤、踩过的坑全部整理出来希望对正在做类似工作的同行有参考价值。2. 核心参数分类与作用原理解读Linux内核参数本质上就是/proc/sys下一堆以文件形式暴露给用户态的运行开关日常使用sysctl -w或者写入/etc/sysctl.conf去控制。虽然数量极多但做业务侧调优时真正高频用到的其实就是几大类。我把它们按作用域分开先说清楚每个块里参数之间的关系否则单独背数字没有意义。2.1 文件句柄与文件系统层面的参数先从最基础的文件句柄说起。Linux下一切皆文件这也是句柄file descriptorFD的概念。网络连接是文件磁盘文件是文件管道是文件甚至某些设备节点也是文件。当服务进程同时需要维护大量外部连接时文件句柄的数量直接决定了服务能不能跑起来。第一个要关注的参数是fs.file-max它站在系统全局的维度控制所有进程能打开的最大文件数。默认值在很多发行版上按内存算通常是内存页数的10分之一左右内存充足时并不小但高并发场景下很容易不够。查看当前值sysctl fs.file-max cat /proc/sys/fs/file-max接着是进程维度的限制ulimit -n。我之前遇到过一个很有意思的例子某服务在压测时一直报Too many open files我查了系统级的fs.file-max数值是几百万完全够用但进程就是起不来。最后发现是ulimit -n卡在1024。这属于典型的系统够、进程不够的错位情况。修改方式一般是在systemd服务文件里加LimitNOFILE或者改/etc/security/limits.conf然后重新登录取效# /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535还有一个容易被忽略的是fs.inotify.max_user_watches。做文件监听、日志收集这类业务时这个参数决定了单个用户可创建的inotify watch数量。默认值8192某个日志项目一启动就需要监控几万个文件这个值直接爆了报错信息是inotify watch limit reached。这种问题光看fs.file-max根本看不出端倪因为它压根不在文件句柄路径上而是属于inotify子系统。2.2 网络协议栈与连接队列相关参数网络层面是内核参数调优的重灾区也是最容易出效果的地方。要理解这些参数先要明白一个请求从进来到完全被应用接管会经过哪些队列。net.core.somaxconn控制的是accept队列长度也就是已完成三次握手、等待应用调用accept()取走的连接数量。很多高并发网关、负载均衡器都最常和它打交道。默认值在较新的内核上是4096旧内核是128。如果它太小突发流量会把队列占满新连接直接被丢弃或者在客户端表现为握手超时。net.ipv4.tcp_max_syn_backlog是另一个容易被误解的参数它控制的是半连接队列的长度也就是正在等待客户端回复SYN-ACK的数量。在正常TCP三次握手里客户端响应很快半连接队列一般用不满但遇到SYN Flood这类场景时半连接队列是首当其冲被打满的对象。net.ipv4.ip_local_port_range管的是客户端发起连接时使用的本地端口范围。做压力测试的机器如果端口范围太小很快会出现无端口可用的情况。默认范围通常是32768到60999做高并发压测时建议扩大到比如10240到65535。还有一个协同项是net.ipv4.tcp_tw_reuse。TIME_WAIT状态的连接会占用本地端口等到超时后才释放。tcp_tw_reuse允许客户端在需要新连接时复用仍在TIME_WAIT状态的连接只对发起方生效。这配合合适的ip_local_port_range对压测机和反向代理服务都有明显帮助。net.core.netdev_max_backlog控制的是网卡层面每个队列能缓冲的包数量。当协议栈处理速度跟不上网卡接收速度时多余的包先在netdev队列里排队。默认1000在高吞吐场景下偏小但调整它时要注意看软中断和丢包情况别盲目加大。2.3 内存管理与OOM策略参数内存相关参数在业务风险上是最高的调整时一定谨慎再谨慎。我见过不少团队为了优化内存把vm.swappiness直接改成0理由是尽量少用swap。这个做法部分场景下是对的但有代价内存回收会更激进地淘汰page cache某些读多写少的场景反而会频繁触发磁盘读性能反而下降。vm.swappiness控制的是系统在回收内存时倾向于回收匿名页还是page cache的权重。值越小越偏向回收page cache值越大越偏向把匿名页换到swap。一般建议服务器设置在10到30之间而不是一味追求0。vm.overcommit_memory是另一个容易踩坑的参数。默认值0表示内核做启发式判断允许少量overcommit值1表示允许所有overcommit值2表示严格按比率控制。做数据库类任务时我习惯用0或1做超大规模内存分配的业务时也建议先评估不要把值改成2后业务直接分配内存失败。vm.dirty_ratio和vm.dirty_background_ratio控制的是脏页回写策略。前者指脏页达到内存一定比例后进程自己负责刷盘后者是达到背景阈值时内核后台开始回写。这两个参数对大量写入场景影响很大调优时建议结合磁盘性能和业务写模型来定并配合监控盘I/O在改动后两小时内的曲线变化不要只看数值是否合理。内存相关参数里最重要的还有OOM Killer的行为策略即/proc/sys/vm/panic_on_oom和每个进程的/proc/pid/oom_score_adj。OOM Killer是内核在内存耗尽时最后的兜底手段它会挑选一个进程杀掉来释放内存。问题的关键往往不是为什么要杀而是为什么要杀这个。关于这块内容我在第三节用一个完整案例展开讲。2.4 进程调度与并发线程参数很多调优项目进展到一定阶段后瓶颈会从网络和文件系统转移到进程调度上。这个时候要关注的参数就变成了kernel.sched_*、kernel.threads-max这些。kernel.pid_max决定了系统内pid号的上界默认值通常比较大32768或更大但在容器化非常密集的机器上如果同时运行大量进程pid耗尽不是没可能。某次我排查过一个诡异的现象某服务突然fork失败fork: Cannot allocate memory但内存明明充足最后发现是pid耗尽。这类问题报错信息非常有迷惑性排查时容易往内存方向跑。kernel.threads-max限制的是线程总数上限也就是系统能同时运行的线程多少。它由物理内存大小决定默认值但少部分极端应用确实需要调优。vm.max_map_count也在这一类里控制进程能持有的内存映射区域数量。像Elasticsearch、JVM服务这类重度使用mmap的应用遇到max map count reached的错误时就要调这个参数。进程调度层面更常用的其实是cgroup和systemd层面的配置而不是传统意义上的sysctl参数。比如通过cgroup的cpu.shares控制CPU权重通过cpuset做绑核这些都不在/proc/sys里但实际调优效果比单纯改内核参数明显得多。做调优时不要把视野局限在sysctl这一层应该全局看待整个内核资源管控体系。3. 实战案例某缓存服务频繁OOM问题排查与调优3.1 故障现象与第一轮排查先说一个具体项目。某内部缓存服务为描述方便以下称项目X上线运行三个月后开始出现周期性OOM进程被OOM Killer杀掉后由部署平台自动拉起业务倒不至于中断但每次杀掉再拉起都有几秒到十几秒的空窗磁盘上的持久化缓存数据因为异常终止频繁回放整个集群的数据热点分布越来越差接口P99延迟从50ms一路涨到300ms。第一轮排查时我们做了两件事。一是看监控面板上的内存曲线发现进程内存使用是锯齿状增长的冲高后立刻被打回这是典型的周期性OOM特征。二是翻内核日志找到当时的OOM记录看内核杀进程时的score。日志里的关键信息大概是Memory cgroup out of memory: Killed process 12345 (xxx) total-vm:1234567kB但奇怪的是系统整体物理内存还剩不少是cgroup内存配额先被打满才触发的OOM。也就是说问题并不是机器没内存而是这个容器分到的内存不够用了。接下来我们开始分析为什么缓存服务内存会持续增长。项目X本身有缓存淘汰机制正常情况下会控制数据量大小但问题出在GC线程和淘汰线程的处理速度跟不上写入速度。内存里的缓存条目越积越多直到把配额打满。业务侧代码逻辑暂时不好改于是决定先通过内核参数层面做一次止血同时给业务侧排期优化淘汰策略。3.2 根因分析与参数调整方案要理解为什么会被OOM Killer盯上先要理解内核怎么挑倒霉蛋。每个进程都有一个oom_score这个分数越高在内存紧张时越优先被杀。oom_score大致上等于进程占用内存的百分比再加上一些基于oom_score_adj的调整值。常见的几个可能方向如下降低进程的oom_score_adj让OOM Killer在进程选择时排到后面去。调整内存回收策略让page cache更早被回收避免缓存条目占着内存不放。扩大cgroup内存限制或者调整swap使用策略让系统在紧迫时有更多缓冲空间。我们的具体做法是先把项目X进程的oom_score_adj从默认0调成-800。这样当OOM触发时内核会优先考虑杀其他分数更高的进程给项目X争取更多存活机会。调整命令echo -800 /proc/pid/oom_score_adj但光这样不够。如果业务代码继续膨胀即使oom_score_adj很低内核也有办法硬杀——在极端情况下如果所有进程都不适合当受害者内核会触发panic。更稳妥的方案是让内存使用降下来。这时就用到了vm.swappiness和dirty page相关参数。我们将vm.swappiness从默认的60降到10让回收内存时更多倾向回收page cache而不是把进程的匿名内存页往swap里换。同时把vm.dirty_background_ratio从10调到5让脏页更早开始回写减少脏页在内存里堆积的时间和数量。sysctl -w vm.swappiness10 sysctl -w vm.dirty_background_ratio5 sysctl -w vm.dirty_ratio20调整之后内存曲线明显平滑了一些因为page cache更早被回收而缓存进程的匿名内存页压力变小。但这只能缓解不能根治。后续还是把主要精力放在业务侧最终通过调整缓存条目的过期策略和GC频率才彻底解决内存增长问题。这个案例想说明的是内核参数调优能帮你在代码来不及修的时候稳住阵脚但你不能把它当成永久解决方案。3.3 效果验证与观察期要点参数改完后项目X进入了为期两周的观察期。我要求运维同学在监控面板上并行盯着四类指标进程常驻内存RSS曲线、OOM触发次数、接口P99延迟、以及系统回收内存时产生的page fault次数。这里有个细节只观察OOM次数减少不够还要看内存回收是否频繁。如果OOM次数为零但每次内存回收都大量触发major fault主缺页中断说明数据页频繁被换出每次访问又要从磁盘读回这种稳定但没有性能的状态同样不可接受。判断依据是vmstat输出的si和so列只要这两列经常出现非零数字就说明swap换入换出非常频繁需要继续调整。两周结束后OOM次数从每两天一次下降到零P99延迟稳定在100ms以内si和so基本为零。项目X这次调优算是成功收尾。4. 实战案例某网关服务大流量下连接堆积问题4.1 现象与根因分析第二个项目是一个对外网关服务承接客户端长连接和短连接两种流量。线上某段时间开始频繁出现客户端连接被重置的投诉而且流量越高发越严重。最初大家怀疑是后端服务处理不过来但后端监控显示CPU和内存负载都正常请求量也没有明显波动。后来上机器用ss -lnt查看socket状态时发现了一个规律处于SYN_RECV状态的连接数量特别大accept队列对应的Recv-Q在部分端口上已经堆满。这说明三次握手完成后的连接一直在内核的accept队列里积压应用层来不及取走最终触发内核丢包行为。TCP栈在accept队列满时要么对新进来的SYN直接丢弃要么对已经完成的握手连接发RST客户端表现出来就是连接被重置。根因其实有两层。第一层是网关应用的处理线程池太小并发处理能力到顶了无法及时accept新连接第二层才是内核参数问题——net.core.somaxconn的值小于网关实际的连接并发峰值比较保守导致队列很快打满。很多运维手册建议直接调大net.core.somaxconn但我后来发现光调它还不够有几个关联参数必须一起动否则效果出不来。4.2 参数组合调优方案这个问题的调法我用了一个组合不是单个参数的大改动而是一组参数的联动# 全局限值 sysctl -w net.core.somaxconn1024 # 应用监听socket的backlog也要同步调整在代码里设置listen backlog值 # 半连接队列 sysctl -w net.ipv4.tcp_max_syn_backlog2048 # SYN重试防止SYN重发导致半连接队列长期堆积 sysctl -w net.ipv4.tcp_syn_retries3 sysctl -w net.ipv4.tcp_synack_retries2 # 打开syncookies作为抵御SYN Flood的保险 sysctl -w net.ipv4.tcp_syncookies1 # 网卡待处理包队列 sysctl -w net.core.netdev_max_backlog4096tcp_syncookies这个参数值得多说一句。它开启后当半连接队列满时内核不会丢包而是通过SYN Cookie机制来处理新连接。SYN Cookie的原理是把状态信息编码进SYN-ACK的序列号里不占用队列等客户端返回ACK时再验证还原。它的代价是TCP的一些选项比如窗口缩放没法完整协商所以不适合作为常开选项但作为防御性质的保险在网关这类入口场景下很有价值。更关键的一步是应用层。网关服务使用Java Netty实现监听socket的backlog是在代码里通过ChannelOption.SO_BACKLOG配置的。内核的net.core.somaxconn只是上限应用自己设置的backlog如果小于这个上限内核按应用设置来如果大于内核按somaxconn来。所以我们必须把SO_BACKLOG同时调上去否则改内核参数等于白改。最终我们把SO_BACKLOG从默认的128调到1024和内核参数保持一致。这个配合关系特别容易忽略我在好几个项目里都见到有人只调内核不改应用导致问题反复出现然后返回来问为什么我改了somaxconn没效果。4.3 调整后的对比验证参数调整完成后我们仍然用压测工具验证。压测模型取线上真实流量特征的简化版400个并发连接每个连接连续发送1000个请求观察不同阶段的SYN_RECV数量和错误率。调整前后对比数据指标调整前调整后最大SYN_RECV数量超过3000700左右连接错误率约5%0.02%P99响应时间120ms65msaccept队列满丢包次数频繁压测期间为零这个案例里最值得说的不是参数本身而是排查路径。排查时一定要先看socket队列状态再决定调什么参数。很多同行一上来就翻各种高性能内核参数清单把几十个参数一股脑改完结果问题还是没解决因为压根不知道瓶颈在内核的哪个队列上。正确做法是先看现象、再定位队列、再针对性调整。5. 常见问题与排查技巧实录这个章节我把做内核参数调优项目时反复踩过的一些坑整理成速查表并附上独家排查心得希望能帮大家少走弯路。5.1 常见问题速查表问题现象可疑方向排查命令常用调整服务报Too many open files文件句柄耗尽ulimit -ncat /proc/sys/fs/file-max调大ulimit -n或fs.file-max连接被重置RSTaccept队列满或应用处理太慢ss -lnt观察Recv-Q调大net.core.somaxconn同步修改应用backlogSYN_RECV大量堆积半连接队列溢出或SYN Floodss -lnt state syn-recv调大tcp_max_syn_backlog开启tcp_syncookiesfork失败但内存充足pid耗尽cat /proc/sys/kernel/pid_max调大pid_maxmmap相关报错映射区域耗尽cat /proc/sys/vm/max_map_count调大vm.max_map_countTIME_WAIT过多高并发短连接ss -s统计开启tcp_tw_reuse调整ip_local_port_rangeOOM误杀核心进程OOM Killer策略问题dmesg查看OOM日志调整oom_score_adj优化内存回收swap策略大流量下网卡丢包netdev队列溢出ethtool -S看rx_dropped调大net.core.netdev_max_backlog这些看起来都是小问题但实际项目里每一个我都亲眼见过。尤其是Too many open files和fork失败这两种报错信息会误导人往内存方向查如果不知道有pid耗尽这回事排查时间会呈指数增长。5.2 针对性的排查工具与思路排查内核参数相关问题时我一般按这个工具组合来走ss、sar、vmstat、dmesg再加一个/proc下的文件检查。这套组合覆盖了连接队列、CPU负载、内存、系统事件、进程级限制五个维度。ss优先看socket状态分布。比如执行ss -s可以直接看到当前系统里各种TCP状态的连接数一眼判断TIME_WAIT占比是否异常执行ss -lnt看监听端口的Recv-Q和Send-Q到底满了没有。Recv-Q在LISTEN状态的socket上代表accept队列的积压数Send-Q则代表发送缓冲区内的排队的请求数量观察这两个值对定位服务能力瓶颈相当直接。dmesg负责看内核日志。OOM Killer触发时会在这里留下进程选择、内存规格、触发原因等详细记录。连接建立超时或SYN被丢弃也可能在这里留下明确的报错信息。项目X的OOM问题如果不是先翻dmesg恐怕要用掉一整周时间才能定位。vmstat适合观察内存换页和CPU上下文切换。如果si、so两列持续非零说明内存在频繁换入换出应用性能一定受损。cs列如果异常高说明进程频繁在睡眠和唤醒之间切换锁竞争的可能性比较大这时要考虑的是用户模式程序的并发设计而不仅仅是改内核参数。还需要一个基本功修改前用sysctl -a导出一份当前系统的完整参数快照。改动后如果出现问题这份快照能帮你快速比对哪些参数与默认状态不同。直接sysctl -w改值很简单但如果你不记录改动历史两周后想回退就只能靠猜了。这一点在多人协作的项目里尤其重要因为我见过不止一次有人不通知队友就偷偷改了net.ipv4.tcp_tw_reuse最后大家花了两天时间排查连接异常回头一看才发现是参数问题。5.3 几个必须养成的调优习惯第一每次只调一组参数。网络问题就把网络参数一次调完而不是网络内存文件系统三个大类混着改。万物互为因果一次性改太多出了问题根本无法定位是哪一行sysctl命令导致的。第二改动后要留足观察期。某些内核参数比如内存回收相关生效后需要经过一个完整的流量周期才能看出真实影响。我之前遇到过改完vm.swappiness后当天各种指标一切正常以为没问题结果一周后其他业务流量上涨内存压力变大系统的page cache被过早回收大量读请求直接走磁盘延迟暴涨。观察窗口不足这类延迟问题根本暴露不出来。第三尽量使用sysctl --system重新加载配置而不是一条条-w临时生效。前者能让修改持久化到/etc/sysctl.conf或/etc/sysctl.d/目录下的文件里-w命令只对当前运行状态生效重启后失效。如果你在排查过程中用-w临时验证最终确认有效后一定记得把参数固化到配置文件里。# 临时生效 sysctl -w net.core.somaxconn1024 # 持久化后面向后续重启友好 echo net.core.somaxconn1024 /etc/sysctl.d/99-network-tuning.conf sysctl --system6. 一个容易忽略的细节内核参数与防火墙的联动关系提到内核参数调优很多人的注意力都集中在sysctl那堆参数上容易忽略另一个重要方面——netfilter框架通常说的防火墙和连接跟踪与内核网络参数的联动。在做高并发项目时这个细节曾经给我带来过不小的麻烦。现代Linux系统的iptables在不加-t nat、-t mangle等表时默认走filter表每次新连接都要过一遍规则链匹配。连接多了以后netfilter的连接跟踪表会记录所有活跃连接状态这个表是有大小上限的由net.netfilter.nf_conntrack_max控制。默认值在多数发行版上可能是65536具体因内存而异。如果实际活跃连接数超过这个值新连接分不到conntrack条目就会被直接DROP表现与内核网络参数症状几乎一样——客户端连接超时、服务端毫无异常日志。有次线上好奇连接数到了一定规模后莫名其妙的连接超时开始增多ss和dmesg都看不出端倪跟调优前数值相比也没有太多区别。最后用conntrack -S一查发现insert_failed的计数在不停上涨这才定位到是conntrack表满了。调整方案是# 查看当前量和最大值 cat /proc/sys/net/netfilter/nf_conntrack_max cat /proc/sys/net/netfilter/nf_conntrack_count # 适当调大并缩短超时 sysctl -w net.netfilter.nf_conntrack_max262144 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established600nf_conntrack_tcp_timeout_established默认是五天的超时时间对于短连接为主的业务来说实在太长了每条连接记录都要在内存里存活五天才会被回收。缩短到600秒10分钟能明显降低conntrack表压力。改这个参数时要注意如果业务有比设定超时更长的空闲长连接这些连接可能被conntrack误删影响既有连接。我建议先统计业务连接的空闲时间分布再做决定不要照搬这个值。这个案例想说明的是在带防火墙和NAT的机器上做内核调优不能只关注TCP/IP协议栈本身还要考虑netfilter层的参数限制。排查顺序上我建议把conntrack计数也纳入常规检查项尤其是在看连接相关问题时。7. 调优之后的维护思考项目结束后我们并没有把所有参数一次性固化到生产环境而是按分组发布、逐步放量的方式推进。先在一台非核心节点上应用全部参数观察一个完整业务周期稳定后再扩大到集群中的20%再观察确认没有副作用后全量推送。每个阶段都保留完整的压测记录和监控截图作为后续调优的参照基线。参数调优的价值在于理解并利用内核的资源管理策略而不仅仅是想照着某个数值清单去改。**机器的内核协议栈参数调整与业务代码本身形成的整体系统调优是一个持续迭代的过程。**随着业务体量增长流量峰值、连接模式、读写比例都会变化今天测出的最优参数三个月后可能已经不是最优解。我把每个项目的参数变更记录按时间线维护下来每次压测或线上变更后都更新一次这样后续每次调优都能站在上一次的基线上往前走而不是每次都在猜是不是又改回去了。最后再分享一点个人经验遇到内核层面的疑难杂症不要急着搜最佳实践先花时间看懂内核日志和系统计数器里的真实数据。绝大多数看起来神秘的问题在dmesg、ss、vmstat、sar里都能找到清晰的线索。内核不会对你撒谎只要定位足够准参数调整的命令往往简单到让人怀疑——但正是这些简单的修改在正确的场景下能带来几倍甚至几十倍的性能差异。调优这条路耐心比聪明重要得多。