1
2
3
4
5
6
7
作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

做运维这么多年，见过不少朋友处理系统性能问题，喜欢去网上搜罗一大段内核调优参数，直接复制粘贴到服务器里生效。

问起为什么要改这些，说不出个所以然；一旦业务出异常，排查起来一头雾水。折腾久了我才明白，性能调优不是靠网上抄配置，它是一套有完整逻辑的做事思路。

很多人还会把性能调优和故障排查混为一谈，其实这两件事完全不是一回事：

  • 故障排查：修好已经出问题的系统，让服务恢复正常可用（解决“系统不能用”）
  • 性能调优：针对本身正常运行的系统，调整设置，提升资源利用率、吞吐量、降低响应延迟（解决“系统用着不够好”）

动手调参前，这些问题要先想明白

不要着急敲命令改配置，首先要确立调优目标，同时心里要接受一个现实：几乎所有调优都会带来取舍，很难把所有指标同时拉到最优。

实际例子：调大系统网络缓冲区，可以提升网络吞吐量，但会消耗物理内存。内存被占多了，业务可用内存变少，系统就会频繁swap，磁盘IO压力暴涨。
如果业务可以接受这个副作用，修改才有意义；如果业务对磁盘IO敏感，参数再好看也不能改。

两个核心性能指标

  1. 吞吐量：单位时间之内系统能够处理的请求或者数据总量
  2. 延迟：发送请求之后，得到反馈所要等待的时间
  • 批处理、报表任务：优先看重吞吐量，追求单位时间处理更多任务
  • Web网站、API接口交互式业务：优先看重延迟，不能让用户长时间等待

绝大多数场景吞吐量与延迟会互相制衡，必须结合业务做权衡。

两个容易被忽略的关键点

  1. 性能瓶颈：CPU、内存、磁盘、网卡其中某一项硬件触达上限，拖累整套系统性能。
  2. 人为主观判断：业务方感觉系统慢 ≠ 服务器资源真的跑满。只靠体感调参，不看监控指标，很容易越调越差。

容量规划要关注的3个重点

  1. ✅ 可扩展性：系统能否适配业务负载上涨
  2. ✅ 系统限制：软硬件本身固有的性能上限
  3. ✅ 关键资源：搞清楚业务真正消耗哪些硬件资源

规划不能只看当前负载，也要为未来业务增长预留余量。

实用硬件性能排查思路：USE分析法

Brendan Gregg提出的 USE分析法（使用率、饱和度、错误率），专门针对CPU、内存、磁盘、网卡这类硬件资源，⚠️不适合软件层面问题排查。

USE完整排查步骤

  1. 梳理识别服务器全部硬件资源
  2. 优先检查错误率！有报错先解决错误，再谈调优（很多卡顿根源是硬件报错、丢包、IO异常，不是参数问题）
  3. 无报错，再检查资源使用率
  4. 使用率正常，继续检查饱和度（任务过多，硬件处理不过来，请求排队）
  5. 定位可疑点深度排查，遍历全部硬件资源，分析结束

具体可以看下图，看不清的可以点击放大：

flowchart LR
    A[开始] --> B[识别资源]
    B --> C[选定一项资源]
    C --> D{存在错误?}
    D --是--> H[调查发现项]
    D --否--> E{高使用率?}
    E --是--> H
    E --否--> F{存在饱和?}
    F --是--> H
    F --否--> G{全部资源检查完毕?}
    H --> I{定位到问题?}
    I --是--> Z[结束]
    I --否--> G
    G --否--> C
    G --是--> Z

三个核心名词通俗解释

  • 使用率：硬件花多少时间在处理业务
  • 饱和度：业务量超过硬件能力，任务排队积压的程度，只要出现排队就是风险信号
  • 错误率：各类错误事件计数，性能下降同时错误持续上涨，必须优先处理

各硬件需要重点监控指标

硬件资源核心监控指标
CPU使用率百分比、负载平均值、队列平均长度
内存可用容量、吞吐量、异常错误
磁盘存储IOPS、IO等待时间、吞吐量、剩余可用空间 💡存储同时属于容量资源 + I/O资源
网络吞吐量、往返延迟、丢包数量、错误计数

实战小经验：磁盘使用率超过 70%，IO排队延迟就会频繁出现；CPU任务可以被抢占中断，磁盘不行，磁盘繁忙时新IO只能排队等待。

线上修改配置标准流程（必看）

  1. 采集基线数据：改动前保存完整监控指标，作为后续对比基准，千万不要跳过。
  2. 一次只修改一项配置：多参数同时改动，无法定位哪个配置生效；只有官方文档明确要求联动修改，才可以批量操作。
  3. 修改完成，复现相同业务负载，验证指标变化。
  4. 效果存疑就回滚基线，做对比测试。
  5. 确认改动有效，做好完整变更记录，方便故障回滚与同事接手维护。

容易踩的坑：别混淆两套计量单位

很多运维都会遇到一个迷惑现象：硬盘厂商标注容量，和操作系统识别出来的大小对不上，相差接近10%，根源是两套计量单位混用。

  1. SI十进制单位（10的幂，厂商宣传使用）
    k=1000、M=1000²、G=1000³

用途：硬盘标称容量、网络带宽规格

  1. IEC二进制单位（2的幂，操作系统内部统计）
    Ki=1024、Mi=1024²、Gi=1024³

用途：内存统计、文件系统磁盘实际容量

实例：市面上标称2TB硬盘，操作系统识别实际只有约1.82TiB。做容量规划直接照搬厂商标值，会造成预估错误。

Linux下我们可以使用 bc 命令做精确换算，scale=4代表保留4位小数，日常三类常用换算场景，直接复制命令就能跑出结果，做性能报表、存储评估非常方便：

  1. 带宽换算：10000 MiB/h 换算 MiB/s
1
echo "scale=4; 10000 / (60 * 60)" | bc

输出结果：2.7777

  1. 网络换算：1 Gb/s（比特）换算 MiB/s（字节）>

    注意：1字节=8比特，MiB是2的20次方

1
echo "scale=4; 10^9 / (8 * 2^20)" | bc

输出结果：119.2092

  1. 存储换算：标称10 TB硬盘，换算系统识别 TiB
1
echo "scale=4; 10 * 10^12 / 2^40" | bc

输出结果：9.0949

以后遇到带宽、硬盘容量算不清楚，直接改数字套上面命令即可。

写在最后

真正的性能调优，不在于背诵一堆内核参数。
核心逻辑：先明确业务目标 → 定位系统瓶颈 → 使用科学方法分析 → 修改配置后验证对比。

线上很多莫名其妙故障，都是网上直接复制调优脚本导致。先分析，后改动，才是运维稳妥的做事方式。

如果你需要，我可以再帮你把USE方法流程图描述补充到文章内，适配博客排版。