企业官网建设流程全解析

做Linux性能优化这些年，我最常被问到的一句话是：“你这套sysctl参数给我抄一下。”每次听到我都挺无奈的。内核优化从来不是抄几个参数就能解决的，它更像医生看病——先诊断，再开药。同一个参数，在Web服务器上是良药，在数据库服务器上可能就是毒药。

这篇文章我想把“Linux内核性能优化”这件事从头到尾讲透。不是给你一堆命令让你复制粘贴，而是把背后的原理讲清楚：CPU调度器是怎么分配时间的、页缓存为什么会导致内存看着不够用、软中断为什么会吃掉大量CPU、IO调度器选错会有什么后果。搞懂这些，你再看那些优化文章，就能自己判断哪些该用、哪些是胡扯。

无论你是运维、后端开发、嵌入式工程师，还是正在准备Linux面试，这篇文章应该都能帮你把零散的知识串成一条线。我会结合真实场景，把从定位瓶颈到动手调优、再到验证效果的完整流程走一遍。

1. 先把优化思路理清楚：内核性能优化的正确打开方式

1.1 性能优化的第一原则：先定位瓶颈，再动手调

很多人一上来就改参数，改完发现没效果，甚至更慢了，于是得出结论“优化没用”。其实大部分失败案例都是因为没找到真正的瓶颈。内核性能优化有一个铁律：先测量，再判断，最后才动手。测量不是随便看一眼top就完了，而是要有针对性地收集数据。

我自己常用的定位套路是这样的：

• 先看top或htop，确认是CPU忙、内存紧，还是负载高但CPU空闲（这种情况通常是在等IO）。
• 再看vmstat 1，关注r（运行队列）、b（不可中断睡眠进程）、si/so（swap换入换出）。如果b长期不为0，说明有进程卡在IO上。
• 用iostat -x 1看磁盘的%util、await、svctm。%util接近100%不代表磁盘坏了，但await明显升高说明IO链路出现排队。
• 网络问题用sar -n DEV 1和ss -s看吞吐、连接状态，配合perf top看软中断占比。

这一套下来，瓶颈在哪个子系统基本就清楚了。内核里凡是能调的东西，几乎都在/proc/sys目录下，用sysctl -a可以全部列出来。但知道每个参数是什么意思、改完会有什么连锁反应，才是优化的分水岭。

1.2 内核里可优化的“五块版图”

Linux内核是一个宏内核，所有核心功能都跑在内核态。从性能优化的角度看，我习惯把它分成五块地图：

• CPU调度子系统：负责决定哪个进程在哪个CPU上跑、跑多久。涉及CFS/EEVDF调度器、负载均衡、cgroup的CPU控制器。
• 内存管理子系统：负责页分配、页缓存、swap、回收机制。涉及vm.*这一大堆参数。
• 块设备IO层：负责把读写请求排成队列、合并、调度到磁盘。涉及IO调度器、队列深度、文件系统挂载参数。
• 网络协议栈：负责收包、软中断、TCP/UDP处理。涉及环形缓冲区、网卡多队列、TCP参数。
• 内核编译配置：在源码层面决定内核支持什么、不支持什么。涉及内核.config、抢占模型、时钟频率。

这五块不是孤立的。比如内存紧张会导致swap，swap会引发磁盘IO，磁盘IO变慢会拖累CPU运行队列，最后整个系统表现就是“卡”。所以调优一定要有全局视角，不能头疼医头。后面几个章节，我会按照这五块地图逐个讲解，每块都给出具体可操作的参数和验证方法。

2. CPU调度层面的优化：让每个核都干该干的活

2.1 调度器原理与负载均衡：为什么有的核忙死、有的核闲死

Linux默认的CPU调度器是CFS（完全公平调度器），从6.6版本开始又引入了新的EEVDF调度器。不管哪个，核心思想都是让每个进程按照权重公平地获得CPU时间。但“公平”不等于“高效”，比如一个多线程应用，明明有32个核，线程却挤在2个核上跑，剩下30个核闲着——这就不健康了。

这种情况通常有两个原因：一是进程没有充分利用taskset或numactl做绑定；二是内核的负载均衡没有及时把线程迁移到空闲核上。你可以用mpstat -P ALL 1看一眼每个核的使用率，如果分布极不均匀，第一件事不要调参，先检查应用层有没有绑核、有没有CPU affinity设置。

内核层面的优化手段主要是这几个：

• irqbalance服务：把硬件中断尽量分散到多个CPU上。大部分发行版默认开启，如果关了，会出现所有网卡中断都打在一个核上的情况，软中断CPU使用率飙升。
• RPS/RPS（Receive Packet Steering）：软中断分发机制。当网卡不支持多队列或者队列数少于CPU数时，可以用RPS把收包软中断分摊到多个CPU。
• smp_affinity绑定：手动指定某个中断由哪个CPU处理，写/proc/irq/<中断号>/smp_affinity，值是CPU位图。

实操示例：查看网卡中断分布。用cat /proc/interrupts看看eth0相关的中断是不是都落在CPU0上。如果是，可以这么绑定：

# 假设 eth0 的中断号是 48，把它绑定到 CPU2 和 CPU3 echo 0c > /proc/irq/48/smp_affinity

这里的0c是二进制1100，表示CPU2和CPU3。改完再用cat /proc/interrupts确认分布是否变化。注意，千万不要在线上环境盲目改中断绑定，一定要先确认哪些CPU是应用在用，避免把中断绑到繁忙的核上适得其反。

2.2 隔离CPU与实时性优化：把专属核留给关键任务

有些场景下，我们不需要“公平”，需要的是“独占”。比如高频交易、音视频处理、实时控制，这类应用要求极低的调度延迟和抖动。Linux提供了内核启动参数来支持这种需求。

isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3

• isolcpus：把指定CPU从通用调度器中分离出来，普通进程不会跑到这些核上。
• nohz_full：在指定CPU上关闭调度器时钟中断，减少周期性打断，降低抖动。
• rcu_nocbs：把RCU回调转移到其他核，避免RCU处理抢占业务CPU。

然后在应用侧用taskset把关键进程绑定到隔离核上：

taskset -c 2,3 ./your_application

踩过的一个坑是：只隔离CPU而不处理RCU和时钟中断，隔离效果会大打折扣。之前一个实时处理项目，隔离了4个核但还是周期性抖动，后来把rcu_nocbs加上才稳定下来。另外要注意，isolcpus会让这些核完全脱离负载均衡，如果应用是多线程且需要内核帮忙调度，强行隔离反而会影响性能。

2.3 cgroup的CPU控制器：多租户场景下的限流利器

cgroup v2的CPU控制器可以用来限制某个进程组的CPU使用上限，也可以设置权重。权重控制的是“竞争时的比例”，上限控制的是“绝对峰值”。比如两个服务共享一台机器，希望A最多用4核、B最多用2核，可以这样配置：

# 假设 cgroup2 挂载在 /sys/fs/cgroup mkdir /sys/fs/cgroup/ServiceA /sys/fs/cgroup/ServiceB echo 400000 > /sys/fs/cgroup/ServiceA/cpu.max # 400ms/1000ms = 4核 echo 200000 > /sys/fs/cgroup/ServiceB/cpu.max # 200ms/1000ms = 2核 echo <pid_of_A> > /sys/fs/cgroup/ServiceA/cgroup.procs echo <pid_of_B> > /sys/fs/cgroup/ServiceB/cgroup.procs

这里的cpu.max是$MAX $PERIOD格式，默认period是100000（100ms），400000表示每100ms周期最多跑400ms的CPU时间，折算就是4个核。这种方式比单纯调内核参数更精细，也更适合容器化场景。

3. 内存与缓存优化：别让数据在原地打转

3.1 页缓存与脏页回写：为什么内存越多，越要小心“假空闲”

Linux会尽量把空闲内存拿去做页缓存（page cache），这是好事，能大幅提升文件读写性能。但很多人疑惑：“明明有64G内存，可用内存只剩1G，是不是内存泄漏？”其实不是，那部分内存是缓存，随时可以被回收。

真正需要关注的是脏页（dirty pages），也就是“改了但还没写回磁盘”的页。内核不会立刻把每次写入都刷到磁盘，而是攒一批再写，这叫回写（writeback）。控制回写行为的有两个关键参数：

vm.dirty_ratio = 20 vm.dirty_background_ratio = 10

• vm.dirty_background_ratio：脏页占内存比例达到这个值时，后台内核线程开始异步刷盘。默认10，意味着脏页到10%时后台开始慢慢写，这时候应用几乎无感。
• vm.dirty_ratio：脏页占内存比例达到这个值时，进程自己的写操作会被阻塞，强制同步刷盘。默认20，如果调整太高，一旦触发就是“雪崩式”阻塞，IO延迟飙升。

为什么这两个参数很重要？想象一个文件服务器，大量小文件写入。如果dirty_ratio调得太高，比如改成40，平时看着写入飞快，等到脏页积累到40%时，所有写进程突然全部卡住，延迟从几毫秒变成几秒钟。这种“虚假繁荣”最容易坑人。

对于数据库这类对延迟敏感的应用，我建议把dirty_background_ratio调低到5、dirty_ratio保持默认或略高到30。对于大批量顺序写的场景（比如日志采集），可以适当调高dirty_ratio来提升吞吐。改之前先用cat /proc/meminfo | grep -E "Dirty|Writeback"看看当前脏页量，再决定怎么动。

3.2 手动回收缓存：drop_caches的真相与误用

你可能见过这条命令：

echo 3 > /proc/sys/vm/drop_caches

它的作用是清空页缓存、目录项和inode缓存。很多人把它当成“清理内存”的神器，定期跑一遍。我要说的是：绝大多数情况下不需要这么做。页缓存是内核自动管理的资源，内存不够时内核自己会回收，手动清空只会让后续读写变慢——因为缓存没了，所有文件访问都回到磁盘读取。

什么情况下真的需要手动清空？只有一种：你刚做完压测，页缓存里全是测试数据，接下来要跑另一次测试，为了保证两次测试的冷热环境一致，才需要清空缓存。还有一种情况是内存告警但系统又不能重启，可以临时清一下，但这是治标不治本，得找到内存去向。

另外，网上流传的“清缓存前先sync”其实是必要的：

sync echo 3 > /proc/sys/vm/drop_caches

sync先把脏页强制落盘，避免清缓存时把还没写回的数据刷掉。虽然理论上drop_caches只回收干净页，但在生产环境养成先sync的习惯总是没错的。

顺带说一个跟WSL和虚拟机相关的现象：很多人在WSL或虚拟机里删了大文件，发现磁盘空间没释放。这往往不是内核参数问题，而是文件被进程占用，或者页缓存没有及时回收。执行sync后再drop_caches一般能解决；如果还不行，用lsof | grep deleted找到占用文件的进程并重启它。

3.3 swap与透明大页：两个容易踩坑的选项

vm.swappiness控制内核使用swap的倾向程度，默认60。这个值越低，内核越倾向于保留匿名页在内存中。数据库服务器通常会设置成1甚至0，避免进程被换到磁盘。但要注意，swappiness=0不代表不会swap，内存不足时该换还是会换。设置成1的含义是“仅在绝对必要时才用swap”。

vm.swappiness = 1

如果你在容器或云主机里跑Java应用，建议检查一下透明大页（THP，Transparent Huge Pages）的状态：

cat /sys/kernel/mm/transparent_hugepage/enabled

默认可能是always，也就是内核会尝试分配2MB的大页。大页的好处是TLB命中率高，代价是分配和回收时会有延迟，而且容易产生内存碎片。对于中等负载的Web应用问题不大，但对于Redis、数据库这类对延迟极其敏感的服务，THP可能导致偶尔的突然卡顿——因为malloc一个普通页面时，内核可能触发一次大页折叠（khugepaged），阻塞当前线程。

生产环境我习惯把THP关掉：

echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag

或者在内核启动参数里加transparent_hugepage=never。很多压测报告里的“长尾延迟”问题，排查到最后都是THP在捣鬼。

4. 块设备IO与网络协议栈调优：延时的元凶都在这里

4.1 IO调度器选型：别让请求在队列里排队等死

Linux块设备层有一个“IO调度器”，负责把对磁盘的读写请求做合并、排序、限流。不同调度器的策略差别很大：

• none（或noop）：几乎不做排序，直接下发给硬件。适合NVMe SSD和硬件已经自带智能队列的虚拟磁盘。
• mq-deadline：保证每个请求在截止时间内得到处理，兼顾延迟和吞吐。适合机械盘和大部分SATA SSD。
• bfq：按进程公平分配IO带宽，适合桌面交互环境，但吞吐可能牺牲。

查看和修改调度器：

cat /sys/block/sda/queue/scheduler echo none > /sys/block/sda/queue/scheduler

我的经验是：现代SSD上无脑选none，让硬件自己做合并和调度。机械盘用mq-deadline。云主机如果是虚拟磁盘，也要选none，因为宿主机已经做了一层调度，客户机再做一层属于“二次排队”，白白增加延迟。

另一个容易被忽视的是队列深度nr_requests：

/sys/block/sda/queue/nr_requests

队列深度决定了IO请求的排队上限。对于需要高并发的场景，适当加大队列深度能提高吞吐，但也会增加单请求延迟。追求低延迟的服务反而要控制队列深度，避免请求堆积太多。

4.2 文件系统挂载参数：几个影响全局的选项

挂载文件系统时，有几个参数对性能影响很大：

• noatime：不更新文件访问时间。默认每次读文件都要写一次atime，高并发读场景下这就是纯消耗。强烈建议加上。
• nodiratime：不更新目录访问时间，同样推荐。
• barrier=0（或nobarrier）：关闭写屏障。这个要慎用，日志文件系统靠屏障保证崩溃一致性，关掉能提升性能，但断电可能导致数据损坏。对非关键数据场景可以试，对数据库绝对不要关。

挂载示例：

mount -o remount,noatime,nodiratime /

4.3 网络环形缓冲与软中断：让收包不再挤在一个核上

网络性能优化有一个容易忽略的环节：网卡环形缓冲区。收包时网卡把数据放到一个固定大小的ring buffer里，如果这个buffer太小，高流量下会丢包。查看和调整方法：

ethtool -g eth0 # 查看当前和最大ring大小 ethtool -G eth0 rx 4096 tx 4096 # 调整

如果系统日志里出现drop计数增长，先检查/proc/net/dev和ethtool -S eth0，再考虑调大ring buffer。同时确认网卡多队列：

ethtool -l eth0

如果Combined大于1，说明网卡支持多队列，要让驱动把队列都开启。如果网卡只有一个队列，那就得用RPS把软中断分摊到多个CPU：

echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus # 把softirq分到CPU0-3

f是二进制1111的十六进制，表示4个CPU。RPS配置在虚拟机和单队列网卡上效果尤其明显，但有得必有失——它会把收包处理从单个CPU分摊到多个核，适合“吞吐优先、核多”的场景；如果你跑的本来就是延迟敏感的小包应用，跨核处理反而会增加延迟，需要实测对比。

4.4 TCP协议栈参数精讲：每个参数都要知道为什么改

网络调参是重灾区，网上一搜就是一大堆听着很厉害的参数。我只挑几个经得起推敲的讲，每个都给出为什么。

接收缓冲区和发送缓冲区

net.ipv4.tcp_rmem = 4096 87380 67108864 net.ipv4.tcp_wmem = 4096 65536 67108864

三个数字分别是最小值、默认值、最大值（单位字节）。不要只调最大值，如果你的应用大多是小连接、低延迟，默认值太大的话反而浪费内存。建议用sar -n TCP或ss -m查看当前连接实际占用缓冲的情况再决定。大吞吐场景（比如文件传输、CDN节点）才需要调大最大值。

拥塞控制算法

net.ipv4.tcp_congestion_control = bbr

BBR是Google提出的基于瓶颈带宽和往返时延的拥塞控制算法，在长距离、高丢包链路上比默认的cubic好很多。但要注意，BBR依赖双方支持，如果对端不支持，效果会打折扣。而且BBR会尝试占满带宽，在共享链路里可能挤压其他业务的流量。在可控内网或者对吞吐有刚需的场景使用，收益很大。

TIME_WAIT和keepalive

net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_keepalive_time = 600

tcp_fin_timeout调低可以加快TIME_WAIT状态的回收，适合大量短连接场景。tcp_tw_reuse允许新的连接复用TIME_WAIT状态的端口。这两个参数对高并发短连接服务（比如Web网关）很有用，但对长连接服务意义不大。

慢启动

net.ipv4.tcp_slow_start_after_idle = 0

默认情况下，TCP连接空闲一段时间后会重启慢启动，也就是重新从小拥塞窗口开始发数据。对于偶尔有突发请求的服务，比如HTTP接口偶发大响应，这个重启会导致首次请求变慢。关闭后，连接能保留之前的拥塞窗口状态，响应更快。适合API服务、长连接池场景，但对空闲连接数极多的场景，代价是内存占用略升。

5. 实操案例整合：把前面讲的东西串起来跑一遍

5.1 场景一：高并发Web服务器，延迟敏感

症状：高峰期接口P99延迟飙到800ms，CPU使用率不高，但软中断占比较高。

定位过程：

• top看整体负载不高，但%si软中断占了一个核满。
• cat /proc/interrupts发现网卡中断几乎都落在CPU0上。
• ethtool -l eth0发现网卡只开了一个队列。

处理方案：

ethtool -L eth0 combined 4 # 开启网卡多队列 ethtool -G eth0 rx 4096 tx 4096 # 加大环形缓冲 echo 2 > /proc/irq/<中断号>/smp_affinity # 把中断分散到不同的核 # 配合sysctl net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_slow_start_after_idle = 0

验证结果：P99从800ms降到120ms，软中断分布到4个核上，CPU整体水位下降。这里最关键的瓶颈其实是单队列网卡收包全部挤在一个核上，光调TCP参数是解决不了的。

5.2 场景二：数据库服务器，IO敏感

症状：磁盘%util只有40%，但查询偶尔出现几百毫秒的延迟尖刺。

定位过程：

• iostat -x 1看到await忽高忽低，队列长度偶尔飙到20以上。
• /proc/meminfo里Dirty值很高，随后触发同步刷盘造成卡顿。
• 文件系统挂载时也没加noatime，读操作还要写atime。

处理方案：

# sysctl.conf vm.dirty_background_ratio = 5 vm.dirty_ratio = 30 vm.swappiness = 1 # 挂载优化 mount -o remount,noatime,nodiratime /data # IO调度器 echo none > /sys/block/nvme0n1/queue/scheduler

同时建议数据库连接池预热，避免频繁建立新连接。验证结果：延迟尖刺消失，磁盘await稳定在个位数。

5.3 场景三：嵌入式设备，需要实时性

症状：一个基于ARM的嵌入式控制设备，串口和传感器数据频繁中断，但Linux默认调度让控制任务偶尔掉帧。

处理方案：

• 内核开启CONFIG_PREEMPT_RT（或使用RT补丁内核）。
• 内核启动参数增加isolcpus=1 nohz_full=1 rcu_nocbs=1，把CPU1隔离出来给实时任务。
• 应用层用sched_setscheduler设置SCHED_FIFO策略和高优先级。
• 中断绑定：把传感器中断固定在CPU0，控制任务跑在CPU1。

这一套下来，任务周期抖动从几十毫秒降到微秒级。如果你在嵌入式设备上做Linux驱动开发，关注一下内核的实时抢占配置，比单纯调应用级别参数有效得多。

5.4 编译期优化：从源码层面做一次“瘦身”

有时候运行期的调优已经做到极致了，但内核本身太“胖”，跑着大量用不到的功能。这时候可以从内核编译入手。比如一个只跑容器服务的服务器，完全不需要蓝牙、声卡、老式IDE驱动等模块。自己编译内核时，在make menuconfig里把不需要的功能关掉，能降低内存占用、减少不必要的内核线程、降低安全面。

需要注意的关键选项：

• CONFIG_HZ：时钟中断频率。默认250或1000。追求低延迟调成1000，追求省电和低开销调成100。
• CONFIG_PREEMPT：抢占模型。桌面选CONFIG_PREEMPT，服务器选CONFIG_PREEMPT_VOLUNTARY，实时场景上RT补丁。
• CONFIG_CGROUPS：容器场景必须保留。
• 模块裁剪：去掉不用的文件系统、驱动、协议。

编译内核本身也是一个很好的学习过程。有人问“内核源码在哪里下载”，Linux内核官网（kernel.org）就能拿到，国内也有很多镜像站。编译时推荐用make localmodconfig，它会根据当前系统已加载的模块生成配置，再用make -j$(nproc)编译。新手上路建议先拿一台虚拟机练手，千万别直接在生产机上玩。

6. 常见问题排查实录：那些年被参数坑过的瞬间

6.1 参数改了没生效？多半是持久化没做对

用sysctl -w或者echo xxx > /proc/sys/xxx改的参数，重启后全部失效。要持久化有两个方法：一是写进/etc/sysctl.conf再执行sysctl -p；二是放在/etc/sysctl.d/目录下的*.conf文件中。踩坑点是：如果你在/etc/sysctl.conf里写错一个参数名，sysctl -p会报错并且停止加载后续参数，导致后面的配置全部没生效。

排查方法：

sysctl -p

如果看到error: "xxxx" is an unknown key，说明有参数名写错了。先把写错的注释掉，再跑一遍，确认所有参数都加载成功。另外要注意，有些参数比如vm.dirty_ratio设置之后不是立即生效的，它只对后续行为生效，已经积累的脏页要在下轮回写周期才处理。

6.2 echo 3 > drop_caches 清完缓存后系统反而更卡

这个前面提到过，页缓存被清空后，大量文件访问重新变成磁盘读，系统响应变慢是必然的。更严重的是，如果清缓存时正好有写压力，脏页还在回写队列里，清完缓存后这些数据还是要落盘，并不能“释放”多少实际压力。

建议：除非做性能测试需要清理冷缓存，否则别碰drop_caches。如果一定要定期清，配合监控看看你的cache被谁用了：

finfo --summary /path/to/big_files # 需要安装 finfo

其实大多数“内存不够用”问题，要查的是匿名页和slab，而不是page cache。

6.3 透明大页导致的随机延迟抖动

某个上线了Redis和PostgreSQL的机器，性能压测时总会在某个时间点出现100ms~200ms的抖动。top显示CPU不高，IO也不忙，就是偶发卡顿。排查到最后发现是THP在凌晨3点触发了khugepaged的碎片整理。把THP设为never后抖动消失。如果你在日志里看到类似huge page allocation failed或者mmap相关的阻塞，优先检查THP。

6.4 改完网络参数反而变慢，怎么回滚

网络参数的坑在于“牵一发动全身”。比如你把tcp_rmem默认值调得很大，结果每一条连接都占用大量内存，反而影响并发能力。又比如把tcp_congestion_control改成bbr后，如果链路上有限速策略，可能引发丢包增加。

我的建议是：改任何网络参数之前，先备份：

sysctl -a > /tmp/sysctl_before_optimization.txt

有问题就恢复：

sysctl -p /tmp/sysctl_before_optimization.txt

还有一个原则——每次只改一组相关参数。比如这次只动TCP缓冲区，跑一次压测记录结果；下次再动拥塞控制算法。这样即使出了问题，你也能精确定位是哪一组参数引起的。

6.5 常用参数速查表

这些只是建议起点，不是终局答案。任何参数最终都要靠压测数据说话。做压测时记得用perf stat、perf top、perf record这些工具采集内核层面的真实瓶颈，而不是只盯着业务层的平均响应时间。

最后再分享一个习惯：每次调优，我都会先改一组参数，跑压测记录数据，再改下一组。所有改动都写进变更记录，配上压测前后对比。这样半年后再看，你能清楚知道每个参数到底产生了什么影响。内核优化是一场持久战，没有银弹，但每一步都踩实了，系统的表现会给你最真实的反馈。