服务器又卡了，top一看负载飙到几十，CPU使用率却只有不到一半；或者CPU满得冒烟，业务却迟迟没有响应。这种场景，凡是正经做过线上运维的基本都遇到过。Linux服务器性能优化这个主题，说大很大，CPU、内存、磁盘、网络、内核参数、应用层调优，每一块都能写一本厚书；说小也小，对于一个具体问题，真正管用的往往就是两三步操作和几个关键参数。
我常年跟各种Linux服务器打交道，踩过的坑、调试过的疑难杂症不算少。这篇文章我就把自己总结的一套性能优化实战思路完整梳理一遍：先从整体思路上讲清楚“怎么定位问题”，再依次拆CPU、内存、磁盘、网络四个维度的优化实操，最后附上具体的排查工具用法和常见的疑难杂症案例。适合刚接触服务器调优的运维新手，也适合已经干了一两年、想系统性梳理优化方法论的开发者。
1. 性能优化的整体思路与核心原则
很多人一上来就喜欢查“Linux优化十大内核参数”，复制粘贴一篇看似高深的sysctl.conf，重启完事。我见过不止一次，照着网上的参数一顿改，结果业务没变快，反而莫名出现连接超时、OOM频发。优化最忌讳的就是不做诊断就动手，一定要先搞清楚瓶颈到底在哪。
1.1 先回答三个问题：慢在哪、为什么慢、改哪里
接到“服务器性能差”这个反馈，先别急着上工具。我会先确认三件事：
第一，业务表现是什么样的。是响应时间变长了，还是吞吐量上不去，还是偶发超时？这个业务的IO模型是CPU密集、内存密集、磁盘密集还是网络密集？比如一个全文检索服务和一个对象存储网关，它们的性能特征完全不同，优化方向也完全不搭边。
第二，当前负载的基线是什么。在没有业务高峰的时候，系统负载、CPU使用率、内存占用、磁盘IO和网络流量各自是多少？没有基线的优化就是瞎调，因为你根本不知道改完参数之后是变好了还是变坏了。
第三，变化发生的时间点。是不是最近变更过配置、升级过内核、调整过架构、或者说业务本身出现了突增？这类信息往往能直接给你指出问题的位置。
确认了这三点，再去系统里看top、vmstat、iostat这些工具的输出，心里就有底了。
1.2 优化必须遵循的四个原则
基于我个人的实操经验，性能优化有四条原则，同时也是红线：
第一条，单变量原则。一次只改一个参数，改完观察一段时间，确认效果或问题后再动下一个。很多人喜欢一次性改十几个内核参数，结果出问题了根本不知道是哪一项导致的，回滚也是滚了一锅粥。我自己的习惯是，每次调整都记录变更内容和时间，配合监控曲线做对比。
第二条，先测量后优化原则。性能问题一定是用数据“测”出来的，不是用眼神“看”出来的。你说网卡有瓶颈，那就拿出吞吐量、丢包率、软中断占比的数据来；你说磁盘IO有问题，那就掏出util、await、队列深度来。没有数据支撑的判断，都只能算猜测。
第三条，应用到什么层次，就在什么层次解决。举个典型的例子：数据库查询慢，你在系统层面把磁盘调度器改成noop，不如先把慢查询日志打开，把那条全表扫描的SQL加个索引。系统层面的调优解决的是“通用基础设施”的效率问题，业务层面的优化往往才是杠杆最大的地方。
第四条，优化是有代价的，要有全局观。比如把文件系统挂载参数的barrier关掉，确实能提升写性能，但代价是掉电时更大概率损坏文件系统。这种“拿可靠性换性能”的优化，一定要先跟业务方确认清楚能不能接受。
1.3 建立“监控—发现—定位—优化—验证”的闭环
长期来看，性能优化不是一个一次性的项目，而是一个持续迭代的过程。我比较推荐的做法是：先在服务器上部署一套基础的监控（至少覆盖CPU、内存、磁盘、网络、关键进程），日常盯着趋势走；出了问题，用监控数据快速缩小范围；然后按下面几章的思路逐层定位；改完配置之后再回到监控上看效果，没有效果或者指标反向变化就立即回滚。
这个闭环看起来简单，但很多团队做不好，原因往往是“监控没数据”或者“数据不会看”。我在后面的章节也会具体聊每个指标怎么看、什么数值算异常。
2. CPU性能优化：从看懂负载到压榨每一颗核
2.1 CPU指标到底该怎么看
CPU优化第一课不是调参，而是会看数据。很多人只知道top里有个%CPU，但其实有几个关键指标容易被忽略。
load average（平均负载）是最容易误读的指标。它统计的是R状态（运行中）和D状态（不可中断睡眠）进程的数量之和，并不直接等于CPU使用率。假设你有16核的机器，load average长期在8左右，那CPU可能完全够用；但如果load average到了50，同时CPU使用率只有20%，那就要往D状态进程上查了——大概率是磁盘IO或者内存回收导致的进程堵在等待上。
CPU使用率要区分us、sy、wa、hi、si这几项。us高是用户态程序在跑；sy过高说明系统调用频繁、上下文切换太多；wa高是CPU在等磁盘IO完成；si高通常意味着网卡中断太频繁，软中断把CPU打满了。这些项在top或者mpstat -P ALL 里都能看到，定位思路完全不同。
上下文切换（context switch）是一个极其容易被忽略的指标。用 vmstat 1 观察cs列，如果每秒上下文切换次数动辄十几万甚至几十万，CPU的大量精力都花在了进程/线程的切换上，用户态的实际计算能力会被严重稀释。这种情况经常出现在线程池乱开、锁竞争激烈、进程数量远大于CPU核心数的应用上。
2.2 定位CPU问题的方法论
我自己排查CPU问题的标准流程是这样：
先用 top -Hp 找到目标进程里耗CPU最高的线程；再用 pidstat -t -p 1 确认线程级别的CPU占用趋势；如果发现某一线程CPU持续爆满，就用 perf top（或者perf record -g）看看热点函数到底在哪里。
这条链路走完，问题基本能定性：是应用层死循环，还是锁竞争，还是垃圾回收线程在疯狂工作，或者干脆是某个系统调用触发了内核态的高开销。比如我遇到过JVM进程CPU被打满，perf抓出来热点集中在ps_thread_stop上，查下来是JIT编译线程和GC线程互相干扰。这种问题你靠加CPU核数是解决不了的，得调整JVM参数或者升级JDK版本。
2.3 CPU优化的常用手段与实际效果
调整进程优先级（nice/renice）：这种方法适合“重要业务和次要批处理任务抢CPU”的场景。比如服务器上同时跑着数据库和定期数据同步任务，可以用renice把同步任务调到+10以上，让它在数据库闲的时候再跑。但要注意，nice值只影响CPU时间片的分配比例，对已经CPU满载的场景作用有限。
进程/线程绑核（taskset）：对延迟敏感的应用，把进程绑定到固定几个核上，能减少CPU缓存失效和核间迁移的开销。比如对Redis这种单线程模型，用taskset -pc 2,3 绑到特定的物理核上，实测延迟抖动明显变小。但绑核要小心：如果这台机器还跑了别的业务，绑得太死反而会互相干扰。
中断绑定（smp_affinity）:网卡收发中断集中在CPU0上导致单核打满，是高频问题。把网卡多队列的中断分散到多颗CPU上，能直接改善软中断导致的瓶颈。操作是查/proc/irq/<中断号>/smp_affinity_list，配合脚本把中断绑到指定的CPU集合上。开RPS（Receive Packet Steering）也有类似效果，不过会增加整体CPU消耗，需要权衡。
内核参数调节（kernel.sched_*）:这里我要提醒一句，不要随便调。大部分应用场景下，内核默认的CFS调度器已经够用了。真正值得关注的是sched_min_granularity_ns（进程最小运行时间片）和sched_wakeup_granularity_ns（唤醒抢占粒度），只在确认大量小任务频繁切换导致上下文切换开销过高时再去微调。很多网上的“优化剧本”把这两个参数改得面目全非，结果延迟不降反升。
2.4 CPU优化场景拆解
举一个我印象深刻的案例：某内部管理系统的Java应用，业务高峰期响应时间从200ms劣化到2秒以上。排查时发现，机器是16核，但CPU整体使用率只有30%，load average却高达80。用vmstat一看，r列只有个位数，但cs上下文切换达到了每秒30万以上。进一步用pidstat追，发现应用内创建了200多个线程，但实际上大部分时间都在等一个共享锁。
这个问题的根子是业务代码的锁竞争，系统层面其实已经把该做的都做了。最后的方向是改代码，用读写锁替代互斥锁，响应时间直接回到300ms以内。这个案例很好地解释了我前面说的原则：系统优化是兜底和辅助，业务层面的问题最终还得回到业务上去解决。
3. 内存性能优化：缓存、Swap与OOM的博弈
3.1 内存指标的正确打开方式
内存优化的第一步，是学会看free命令的输出。很多新手看到free -h里面available很小、used很大就急着加内存，这是一个致命的误判。
Linux的内存管理哲学是“闲着也是闲着，不如拿来当缓存”。free输出里的buff/cache一列，实际上是文件页缓存（page cache）和块设备缓冲，它们可以在应用程序申请内存时随时被回收。真正需要关注的是available这一列，它估算的是“在不触发swap的情况下，还能分配给应用程序的内存”。只要available没见底，buff/cache再高都不用慌。
Swap需要单独说明：Linux在内存压力下会把不活跃的内存页换到磁盘上的swap分区。swap的使用其实不是问题，问题是换入换出（swap in/out）的频率。用vmstat可以观察si和so两列，如果这两个数字长期大于0，说明系统内存存在真实压力，一直在做内存和磁盘之间的搬运，这种状态会严重影响整体性能。
3.2 常见内存问题的定位方法
内存泄漏：进程RSS持续增长，重启后又恢复正常，这是典型的泄漏症状。可以用pidstat -r 1看进程的内存增长趋势；也可以用/proc/<pid>/smaps分析具体内存段的分布。C/C++程序可以用valgrind，Go程序看pprof，Java程序看heap dump。定位到泄漏点才是根治，临时手段是配置监控报警和定时重启。
OOM Killer：当系统内存严重不足，内核的OOM Killer会按评分杀掉一个进程来救急。看dmesg或者journalctl -k，能查到当时系统记录里OOM的详细信息，包括被杀的进程、各进程占用内存排名。OOM本身说明两个问题，一个是内存真的不够了，另一个是进程占用内存不合理、或者内存申请不受控。我在实际生产中遇到过MySQL实例OOM，查下来是innodb_buffer_pool_size设得过大，再叠加JVM（同一台机器上还跑了个Java服务）的内存占用，正常业务流量一起来两者就“互杀”。解决办法是拆分部署，给数据库独立的内存空间。
3.3 内存优化的关键参数与实践
vm.swappiness：这是控制内存回收倾向的参数，范围0-100。数值越大，内核越倾向于把不活跃的内存页换到swap；数值越小，越倾向于回收page cache。对大多数服务器来说，swappiness设置为10左右是一个比较务实的起点——既能保证在内存紧张时回收缓存，又尽可能避免把应用的内存页怼到swap。但注意，不是所有场景都适合调低：某些内存申请峰值极高、但是平时内存富余的服务，调低swappiness反而会让峰值时的申请直接触发OOM，因为内核没有及时把该换出去的内存换出去。
vm.vfs_cache_pressure：它控制的是内核回收目录项和inode缓存的倾向，默认100。如果业务有海量的小文件读写（比如消息队列的存储目录、代码仓库），这些缓存的消耗会很大，把vfs_cache_pressure调低到50左右能减少不必要的重复lookup。但调太低（比如10以下），内存不足时可能回收不动，反而引发问题。稳妥的做法是10的倍数逐步下调测试。
HugePages（巨页）：对数据库、Java应用等内存占用巨大的服务，开启巨页能显著减少TLB（页表缓存）miss，从而提升内存访问效率。但巨页的坑也不少：首先是内存预分配，配置了多大就占多大，容易浪费；其次，如果应用没适配巨页（比如JVM需要指定-XX:+UseLargePages），调了等于没调。我对这个参数的忠告是：数据库业务如果性能敏感，值得尝试；普通Web服务不要碰。
NUMA：多路服务器普遍开启了NUMA架构，每个CPU访问本地内存比访问远端内存快得多。问题在于，默认的NUMA策略下，当某颗CPU节点上的内存耗尽，它会去“借”另一颗CPU节点的内存，导致远端访问延迟暴增。这就是为什么有些服务器内存明明还有很多，但应用性能突然劣化。用numastat可以确认节点间内存借调情况。解决方向有两个：一是用numactl --interleave=all做内存交错访问，均匀分布；二是 --membind强制本地分配，再配合绑核。这两个方案没有绝对优劣，取决于业务的内存访问模式。
3.4 从监控数据反推优化方向
我调试过一台内存吃紧的Web服务器，free的available只剩不到500MB，swap的si值一直在几百KB/s到几MB/s之间波动。用smem（按实际物理内存占用排序）看一下，发现罪魁祸首是一个第三方日志收集Agent，RSS占了2GB多，远高于它的实际需求。
这类情况不需要调内核参数，直接把Agent的配置改成批量发送日志、限制并发缓冲，问题立刻缓解。所以内存优化这块，我的体会是：先查吃内存的进程合不合理，再调内核参数。很多时候参数只是帮你把不合理的混用局面圆过去，但圆过去不等于真正解决。
4. 磁盘与文件系统性能优化：IO瓶颈的破解之道
4.1 认识磁盘IO的核心指标
磁盘性能问题往往是最让运维头疼的，因为它的表现形式会“伪装”成CPU问题或load高。先强调一个概念：磁盘IO的两种衡量方式——吞吐（带宽）和IOPS（每秒IO次数）。顺序读写大文件看吞吐，随机读写小块数据看IOPS。数据库的redo日志和普通文件服务的数据写入，本质上就是两种完全不同的IO模型。
用iostat -x 1可以看一组核心指标：
%util：设备忙的时间占比。注意，这个值不是“磁盘使用率”，很多情况下%util到100%不代表带宽用完了，而是代表IO队列一直在忙。对于机械盘，%util长期100%意味着IO已经饱和；对于SSD和NVMe，由于并发能力强，%util经常100%但实际吞吐还有大量余量，必须结合读写量和队列深度一起判断。await：IO请求的平均等待时间（包含排队时间和实际处理时间）。机械盘awa it在10-20ms正常，SSD应该是零点几毫秒到几毫秒。await飙到几十毫秒以上，先怀疑磁盘硬件性能，再怀疑队列拥塞。svctm：IO请求实际处理时间。await明显大于svctm时，说明大量时间耗在排队上，磁盘子系统已经顶不住了。
还有一个容易被忽略的点：磁盘瓶颈的“伪装术”。D状态进程增多、load average升高、CPU的wa指标升高，这三个现象同时出现，基本就是大量进程在堵着等磁盘IO。我之前排查过一次诡异的“CPU打满”，追到最后是磁盘在大量回写脏页，所有进程都在等page cache刷盘，属于典型的Linux页缓存回写导致的IO风暴。
4.2 文件系统与挂载参数的调优细节
这块的优化收益高，但坑也不少，我按优先级排一下：
noatime/nodiratime：这是性价比最高、也最安全的一个调整。默认情况下，内核每次读取文件都会更新atime（访问时间），导致一次读操作里还隐含一次写操作。对读多写少的业务来说，这个开销纯粹是浪费。在/etc/fstab的挂载参数里加上noatime,nodiratime，对机械盘和海量小文件的高频读场景，效果立竿见影。我见过一个图片服务在加了这个参数后，IO负载直接降了20%。
IO调度器：这是老生常谈，但确实值得调。早期的deadline和cfq是两种思路：deadline保证每个请求都有截止时间，防止饿死；cfq按公平性排队。SSD和NVMe已经成为主流之后，它们的延迟足够低，调度器反而成了多余的一层，所以现代内核默认给NVMe设的是none（即noop）。老的SATA SSD和机械盘，建议根据业务场景选：数据库等随机小IO重的业务用deadline/mq-deadline；大文件顺序读写为主且多业务混跑，cfq/bfq反而体验更好。用cat /sys/block/<设备名>/queue/scheduler查看当前调度器，用echo临时修改。
barrier和数据可靠性：ext4和xfs默认开了写屏障（barrier），用来保证掉电时元数据的一致性，代价是写性能有损失。一些网上的“性能优化大法”会让你挂载时加barrier=0关掉它。这个操作我非常不建议在生产环境做，除非你有UPS保证供电，并且确认业务对数据一致性要求不高。我见过某团队为了追求写入性能关了barrier，一次机房意外断电，整个文件系统直接挂载不上，最后只能从备份恢复，损失远超那一年的性能收益。
日志模式：ext4的data=ordered模式已经是默认且相对平衡的选择，保证数据块先于元数据落盘。如果你跑的是纯缓存型业务（数据丢了可以从上游恢复），可以考虑data=writeback，性能会有提升，但代价是异常断电时文件和目录大小可能对不上。这个参数要想清楚了再动。数据库的场景普遍不建议做这个调整，宁愿在数据库层面去优化日志策略。
4.3 磁盘层面的系统级优化手段
调整文件系统预读(read-ahead)参数：用blockdev --setra可以调整磁盘的预读大小。对顺序读为主的业务（比如视频点播、日志分析），加大预读（比如从默认的128KB调到1MB以上）能显著提升吞吐；但对随机读业务，过大的预读只会浪费内存带宽和增加无关IO。数据库服务器建议保持默认甚至调小预读。
RAID写缓存策略：如果你用的是带RAID卡的物理服务器，检查RAID卡上的写缓存策略。RAID卡有电池或电容保护的话，可以把写策略从Write Through改成Write Back，性能能差出一个量级。但前提是确认电池/电容状态正常且未被禁用，否则掉电丢数据的风险很大。用RAID卡的管理工具能看到bbu状态。
IO队列深度：对NVMe盘，/sys/block/<设备名>/queue/nr_requests可以调整队列请求数量。默认值一般是64，对压力很大的NVMe场景可以增大到128甚至256，有些高端NVMe盘本身队列深度很大，默认值反而限制了它。但调整的幅度要小步试，太大反而导致请求在队列里排队时间变长，延迟劣化。
4.4 实际案例：从iostat到根因
有一次线上数据库服务器出现周期性抖动，每小时的某个时间点查询延迟会从5ms涨到300ms。我坐到机器前面，iostat -x 1一看：设备util某个瞬间冲到100%，await冲到80ms，但iowait的持续时长只有几秒就又回落到正常。快速缩小范围，最后发现是每小时整点的备份任务，日志备份脚本会把几GB的binlog复制到本地另一块数据盘上。
这块数据盘和数据库数据盘在系统层面虽然分开了，但共用同一个RAID卡和同一组物理磁盘（RAID5）。备份的大规模顺序读和数据库的随机小IO互相干扰，队列被瞬间打满。解决办法也很简单：把备份任务的时间窗口错开业务高峰，并且用ionice把备份进程的IO优先级降到idle级别，让它在系统空闲时才跑。改了之后，该时间点再也没有出现过抖动。
这个案例说明，磁盘性能优化往往是“摸清全局IO节奏，然后给不同业务分配不同的IO优先级和时间片”的艺术，而不是单纯调参数。
5. 网络性能优化：从网卡中断到TCP参数
5.1 网络优化的前提：先区分问题出在哪一层
网络性能问题的排查有一个基本链路：网卡物理层 → 驱动/中断层 → 协议栈层 → 应用层。每一层的症状和数据特征都不一样：
- 物理层：网卡丢包、crc错误、链路降速，用
ethtool -S查网卡计数器里的rx_crc_errors、rx_errors、tx_timeouts。 - 中断层：CPU的si（软中断）占比高，大量CPU时间耗在网络处理上。用
top看si列，再用mpstat -P ALL看是不是集中在一两颗核上。 - 协议栈层：出现的症状是连接建立慢、重传多、丢包、TIME_WAIT堆积。用
netstat -s看TCP的重传率、丢包、SYN重传等计数。 - 应用层：连接能建上，但业务响应慢。这时候系统层面的数据基本正常，重点去抓业务日志和应用调用链。
所以不要一上来就调TCP参数，先看这个网络问题到底“长”在哪一层。TCP参数的调整，很多时候是在给不合理的网络交互模式“擦屁股”，治标不治本。
5.2 高频网络问题与对应调优参数
TIME_WAIT过多：高并发的短连接场景（比如大量HTTP请求、爬虫请求），TIME_WAIT socket堆积起来，会导致本地端口不够用，出现Cannot assign requested address。传统的优化方案是开net.ipv4.tcp_tw_reuse=1（注意，这个参数不能用在大规模TCP服务端上，在最新内核里tcp_tw_recycle已经被移除了）。我个人的建议是：tcp_tw_reuse只对客户端有效，而更稳健的方案是改造业务层，用长连接或连接池替代短连接，这才是从根源上解决。
半连接队列溢出：公开的Web服务被短连接连接风暴冲击时，经常出现SYN重传。可以看netstat -s里的SYNs to LISTEN sockets dropped计数。调大net.ipv4.tcp_max_syn_backlog和net.core.somaxconn，同时要配合应用层（如nginx的listen backlog）才能生效。只调内核参数不管应用层，是这类问题最常见的无效操作。
socket缓冲区大小：默认的收发缓冲区经常陷入两种极端——太小导致吞吐上不去，太大导致内存浪费。用iperf3测一下实际带宽，如果发现带宽远低于网卡标称值但CPU和磁盘都不忙，可以尝试增大net.core.rmem_max和net.core.wmem_max，同时把net.ipv4.tcp_rmem和tcp_wmem的三段参数调成 4096 87380 16777216 这类范围。但注意，缓冲区的投入本质上是拿内存换吞吐，如果内存紧张，增大缓冲区可能导致别的问题。
BBR拥塞控制：在跨地域的长肥网络（高带宽高延迟链路）上，TCP默认的Cubic拥塞控制算法很难把带宽跑满。把拥塞控制算法换成BBR（net.ipv4.tcp_congestion_control=bbr），实测在跨区域传输上能把吞吐从几十MB/s拉高到几百MB/s。代价是BBR在丢包率高的网络上会让延迟有一定上升，另外有些老内核版本不支持BBR，需要升级内核。我不是在劝所有人都去换BBR，但确实有大文件传输业务且链路质量不差的，值得一试。
连接跟踪表溢出：对于开启了conntrack（连接跟踪）的iptables/nftables场景，高并发下容易把nf_conntrack_max默认值撑爆，导致新连接直接被丢弃。症状是应用层报连接超时，而dmesg里有nf_conntrack: table full的报错。解决方式：看/proc/sys/net/netfilter/nf_conntrack_count的当前值，按量调大nf_conntrack_max，或者去掉不需要的连接跟踪规则。这个问题的坑在于很多人完全没意识到自己装了带conntrack的规则。
5.3 网卡多队列与中断分散：软中断优化实战
高流量服务器的网卡中断，默认条件下经常全部压在一个CPU核上，导致该核软中断占比持续100%，而其他核闲得发慌。这个问题的标准解法是开网卡多队列，配合RPS（Receive Packet Steering）/RFS（Receive Flow Steering）。
实操流程是：先确认网卡支持多队列（ethtool -l eth0看Combined队列数量），如果当前只有1个队列，尝试用ethtool -L eth0 combined 4开启多队列。开启后，再配合rps_cpus把报文分发到多个核上。RPS的配置方式是在/sys/class/net/eth0/queues/rx-<n>/rps_cpus写入掩码。
这个优化的效果非常直观。我处理过一台下载代理服务器，流量高峰时CPU0软中断高达80%，整机吞吐被拖累。开了4队列并做了中断分散后，软中断分布到了4个核上，总吞吐提升接近60%。但要注意：开多队列和RPS会增加整体的CPU占用（用额外的核来分摊软中断），CPU核数比较紧张的机器需要衡量一下值不值得。
5.4 一个网络优化的完整排查链路
举一个我实际处理过的案例：某内部API网关，高峰期出现大量TCP连接建立失败，报错是Connection timed out。第一步用ethtool -S查链路层，正常；第二步看top，发现si不高，排除中断问题；第三步用ss -s看socket统计，发现TIME-WAIT数量超过5万，接着netstat -s里有一项TCP time wait overflow在飙升。对症下药就是上面说的TIME_WAIT调优：开tcp_tw_reuse，同时建议业务层把HTTP短连接改为长连接。
改完建立连接成功率和吞吐都恢复了。这里面的教训不是“调了某个参数救了命”，而是“通过逐层排查确认问题出在哪层之后，用了正确的参数”。如果你一开始就调拥塞控制或者改缓冲区，大概率是白忙一场。
6. 监控工具与定位方法：不靠猜，靠数据
6.1 常用性能工具一览与适用场景
性能优化离不开工具，但工具的玩法是“对症下药”。我整理了一张我日常用得最频繁的工具清单：
| 工具 | 主要作用 | 典型适用场景 |
|---|---|---|
| top/htop | 全局CPU、内存、负载实时画面 | 第一眼全局观察 |
| vmstat | 进程、内存、分页、CPU的统计 | 看整体资源调度，上下文切换 |
| mpstat -P ALL | 每颗CPU的使用率明细 | 看CPU是否不均衡、单核打满 |
| pidstat | 按进程/线程看CPU、内存、IO | 定位到具体进程/线程 |
| iostat -x | 磁盘利用率、IO延迟、队列深度 | 磁盘瓶颈定位 |
| sar | 历史性能数据采集与回放 | 追溯问题时间点的数值 |
| free | 内存可用容量、缓存 | 快速判断内存余量 |
| ss/netstat | socket连接状态统计 | 连接数、TIME_WAIT、端口耗尽 |
| ethtool -S | 网卡计数器明细 | 物理层丢包、错误 |
| perf | 热点函数分析 | CPU热点代码定位 |
| strace | 系统调用追踪 | 应用卡在哪个系统调用 |
这些工具真正用好，靠的不是“背参数”，而是知道“什么时候用什么”。比如我看到CPU的wa高，会立刻打开iostat看磁盘；看到si高，立刻查网卡中断分布；看到load高但CPU不高，立刻查D状态进程。每一条指标都会指向下一层的排查方向。
6.2 快速定位四类典型性能问题的排查路径
场景一：CPU使用率高：top确认User%高，pidstat找到进程，pidstat -t找到线程，perf太热函数。如果热点在内核态，怀疑系统调用频繁，用strace -c看都调了什么系统调用。
场景二：load高但CPU不高：大概率D状态进程在等IO。用top按D排序，或者ps -eo stat,pid,cmd | grep '^D'，把D状态的进程找出来，然后用iostat确认是不是磁盘IO扛不住。
场景三：内存available快速下降：pidstat -r看哪个进程RSS在涨，free看cache占比。如果cache占比高且内存压力大，可能是文件读写太猛，也可能是vfs_cache_pressure设置不合适。
场景四：网络延迟高：先ping看基础延迟，再ss看连接状态，netstat -s看重传率，ethtool -S看底层丢包。逐层排除，不要跳层下结论。
6.3 用监控数据建立性能基线
我强烈建议每台重要的服务器都跑一个sar或者类似的定时性能采集工具，因为它能帮你回答一个关键问题：“今天的指标和上周有什么不同？”如果没有历史数据，你连“负载从8涨到20”这种最基础的变化都发现不了，更别提定位什么时间点开始劣化的。
实操上，我会在服务器上部署sysstat包，开启/etc/cron.d/sysstat里默认的采集任务。另外配一个Prometheus + node_exporter + Grafana的组合，作为日常可视化监控。这套东西对中小团队来说属于基础建设，真的别省，出了问题再想“我刚才为什么不记得昨天负载是多少”，就晚了。
6.4 工具之外的思路：极限压测与容量规划
最后讲一个优化工具之外的维度。性能优化不只是“修问题”，还包括“在问题出现之前预判容量”。我习惯在服务上线前用stress-ng、fio、iperf3分别做CPU、磁盘、网络的极限压测，摸清楚这台机器的实际天花板。
fio的写法很灵活，随手记一个典型的随机读写测试命令：
fio --name=randwrite --directory=/data/test --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --size=4G --numjobs=4 --group_reporting这个命令会模拟4个并发进程，用4K块大小做随机写，队列深度32，重点看IOPS和延迟分布。拿到极限数值之后，再结合业务预估的流量，就能判断现有的机器规格够不够、需不需要拆分、什么时候该扩容。
容量规划的另一个好处是可以反向指导应用设计：如果你的机器极限只能扛10万IOPS，而业务压测需要30万，那性能调优再怎么做也只是杯水车薪，架构上就得考虑分片或者引入缓存层。优化从来不是单点的自我感动，要从系统和架构两个维度同时看。
7. 常见问题与避坑实录：这些教训是用代价换来的
7.1 参数改完不持久化，一重启就还原
内核参数用sysctl -w临时修改后，进程一重启就还原，这个坑多少人踩过我不说。所有调试达成稳定的参数，最后都要写入/etc/sysctl.conf或/etc/sysctl.d/里的配置文件中。文件系统的挂载参数，也要记得同步到/etc/fstab里。我的习惯是每次调优记录一下变更，统一提交到一个纳管配置里，这样重建服务器时能一键恢复。
7.2 工具自己成了瓶颈，压测结果失真
用ab、wrk这类压测工具去做性能验证时，很容易忽略一个事实：压测工具本身也在消耗CPU和网络资源。我曾经在一台低配机器上压测另一台服务器，结果压测端CPU先满了，压出来的结果全是错的。正确的做法是压测工具跑在独立的机器上，至少不要让压测端和被测端互相抢资源。
7.3 swap的调试偏差
你在一台空闲服务器上把vm.swappiness调成0，让它“尽量不用swap”，结果业务上去后直接OOM。为什么？因为swappiness=0只意味着“内核不主动换出匿名内存页”，不代表“没有换出需求时不会启动”。内存一旦紧张，内核照样会开始swap，甚至某些极端配置下进程会被直接杀掉。稳妥的做法是把swap当“最后一道保险”，不要试图完全消除它，而是通过监控和告警来提前介入。
7.4 走高并发优化路线，先把文件描述符和连接数查一遍
很多连接数打不上去的问题，根子根本不在TCP协议栈，而在应用进程能打开多少文件描述符。ulimit -n默认是1024的场景我见过太多，调了半天tcp_max_syn_backlog，结果并发一上来进程直接报too many open files。排查网络问题之前，先把ulimit -n、/etc/security/limits.conf、systemd服务的LimitNOFILE都确认一遍，能省下大量时间。
7.5 内核版本差异：老经验不一定适用新系统
时代变了，老的调优经验很可能失效。比如tcp_tw_recycle这个参数，在新内核里已经被移除了，很多人还在用旧文档里的配置，结果是配置完全无效。还有IO调度器，以前大家削尖脑袋把SSD从cfq改成noop，现在NVMe默认就是none，瞎调反而干扰系统默认的合理分配。所以看到任何网上的“优化脚本”，第一件事是确认它的适用内核版本和适用场景，不要盲目套用。
7.6 性能优化的回归验证：不能只看单一指标
调优之后，验证不能只看单一的指标变了没有。比如你为了提升磁盘写性能关掉了barrier，写吞吐确实上去了，但你要同时观察应用的延迟、CPU的wa变化、IO队列深度，特别是要接受一次异常断电的考验——这个代价可能是丢失文件系统完整性。我的原则是：任何性能优化，最终都要回到业务指标上验证（响应时间、吞吐、成功率、错误率），单一的底层指标改善不代表业务变好，反而可能是优化方向错了。
7.7 调优记录与回滚预案
最后一条是方法论上的建议：每次调优之前都留好回滚预案。具体做法是，改动参数前先记录当前值（比如sysctl -a | grep xxx保存到文件），然后每次只改一个参数，改完观察10-30分钟，如果指标反向变化或者业务出现异常，立即回滚。同步在服务器的运维文档里记录这次变更的动机、时间和效果，方便后续排查问题时有据可查。
写在最后：一次性能优化实战的复盘
回到文章开头那个“CPU使用率不高但负载爆炸”的场景。如果你完整读到这里，大概已经知道应该怎么走了：先看load的构成，别被假象带偏；再用vmstat确认上下文切换和D状态进程；接着顺着D状态进程找到等的是CPU还是磁盘，然后该剖代码就剖代码，该调磁盘参数就调参数。
我自己做Linux服务器性能优化这么多年，最大的体会其实是——大部分性能问题的根子都在应用层或者架构设计上，系统参数能解决的反而只占一小部分。但恰恰是系统这一层的排查手段，能让你快速缩小范围、快速排除干扰项，把真正的问题暴露出来。所以我会建议运维和开发都认真掌握这一套从系统指标到应用代码的排查逻辑，它会让你的问题定位效率提升一个数量级。
如果你手头正有一台服务器卡得不行，可以从top和vmstat开始看起，然后顺着这篇文章的思路一层层往下走。调优这件事，重要的是“弄明白每一个指标背后的含义”，而不是复制粘贴别人的参数。希望这篇实战指南能帮你少踩一些我踩过的坑。
