2. 性能基础
核心原理：性能问题的根源在于资源争用与延迟叠加
性能调优的本质，是理解应用程序在底层基础设施上运行时，资源如何被分配、调度和争用。计算机体系结构决定了单条指令的执行成本，操作系统管理着 CPU、内存、磁盘等资源的分配策略，而网络则引入了跨节点通信的延迟与带宽限制。三者层层叠加，最终表现为用户可感知的响应时间与吞吐量。
从一条 SQL 查询到一次 HTTP 请求，性能损耗可能发生在多个层级：CPU 缓存未命中导致的内存访问延迟、操作系统线程上下文切换带来的开销、TCP 拥塞控制引发的传输等待。性能剖析的第一步，就是建立这种分层归因的思维模型——当延迟出现时，先判断瓶颈位于计算、存储还是网络路径上。
关键认知：性能问题很少是单一原因造成的，而是多个基础组件共同作用的结果。例如，一个看似“慢查询”的数据库问题，可能源于磁盘 I/O 调度策略、文件系统缓存命中率、网络往返次数，甚至 CPU 频率缩放（DVFS）导致的算力波动。
方法流程：从系统视角建立性能剖析路径
面对一个性能问题，不应直接猜测“是不是代码写错了”，而应按照自底向上、逐层排查的流程展开。推荐的剖析路径如下：
- 确认瓶颈域：通过全局监控（如 CPU 使用率、内存水位、磁盘 I/O、网络流量）判断瓶颈属于计算型、存储型还是网络型。
- 深入子系统：若 CPU 繁忙，进一步区分是用户态（应用逻辑）还是内核态（系统调用、中断）；若磁盘繁忙，区分是随机读写还是顺序读写。
- 关联应用行为：将系统指标与业务请求关联，例如通过链路追踪查看某次慢请求对应的系统调用序列。
- 定位根因：使用 perf、strace、iostat、tcpdump 等工具缩小范围，最终定位到具体的代码行、锁竞争或网络配置。
| 性能维度 | 关键指标 | 常用工具 | 典型瓶颈 |
|---|---|---|---|
| CPU | 使用率、负载均值、上下文切换率 | top / perf / pidstat | 线程饥饿、GC 频繁、死循环 |
| 内存 | 可用内存、swap 使用、缺页率 | free / vmstat / /proc/meminfo | 内存泄漏、堆外内存溢出 |
| 磁盘 I/O | IOPS、吞吐量、await、util% | iostat / iotop / blktrace | 随机小文件读写、日志刷盘 |
| 网络 | 带宽、RTT、重传率、队列积压 | sar / netstat / tcpdump | TCP 慢启动、DNS 解析延迟 |
案例/场景：一次“数据库慢查询”背后的体系结构陷阱
某电商系统在促销期间出现大量订单查询超时，DBA 定位到一条 SQL 执行时间从 50ms 飙升至 2s。初步分析执行计划发现索引正常，但物理 I/O 等待异常升高。进一步排查发现：
- 服务器使用机械硬盘（HDD），而非 SSD，随机读 IOPS 仅约 150；
- 操作系统页缓存（Page Cache）被大量日志写入挤占，导致 SQL 所需的数据页无法命中缓存；
- 文件系统采用 ext4 默认的 ordered 模式，每次事务提交都触发磁盘 fsync，加剧了 I/O 竞争。
最终解决方案并非优化 SQL，而是：① 将数据库数据文件迁移至 NVMe SSD；② 调整日志写入策略，减少 fsync 频率；③ 为数据库进程设置 ionice 优先级，避免被日志进程抢占 I/O 带宽。这一案例说明，应用层看到的“慢”，往往是底层存储体系结构与操作系统调度策略共同作用的结果。
实操建议：在排查任何性能问题时，先执行 vmstat 1 观察 r（运行队列）、wa（I/O 等待）和 si/so（swap 换入换出）三个指标。若 wa 持续高于 20%，优先排查存储层；若 r 持续大于 CPU 核数，则转向线程调度分析。
误区/复盘：常见的基础设施认知偏差
误区一：CPU 使用率高 = 计算密集。实际上，频繁的系统调用、中断处理（如网络软中断）同样会拉高 CPU 使用率，但此时瓶颈在网络数据包处理而非业务计算。复盘案例：某网关 CPU 100%，perf 显示 softirq 占比 70%，最终通过启用网卡多队列（RSS）和调整中断亲和性解决。
误区二：内存越大越好，忽略 NUMA 效应。在多路服务器上，跨 NUMA 节点访问内存的延迟比本地访问高 1.5～2 倍。若应用线程被调度到远离其内存所在节点的 CPU 上，即使内存充足也会产生性能惩罚。正确做法是使用 numactl --cpunodebind=0 --membind=0 绑定执行，或开启内核的自动 NUMA 均衡。
误区三：网络延迟高就加带宽。TCP 的吞吐量受限于 带宽延迟积（BDP），即 带宽 × RTT。若 RTT 为 50ms，带宽为 1Gbps，则 BDP 约为 6.25MB，默认的 socket 缓冲区（通常 16KB～4MB）可能不足以填满管道，导致吞吐量远低于带宽上限。此时应增大 tcp_rmem 和 tcp_wmem，而非盲目扩容带宽。
复盘要点：每次性能事故后，应输出一份“层级归因报告”，明确标注瓶颈发生在体系结构（如缓存未命中）、操作系统（如调度延迟）还是网络（如丢包重传）层面。避免只记录“优化了代码”而忽略底层诱因，否则同类问题会在系统规模扩大后再次出现。
理解这些基础原理，不是为了背诵概念，而是为了在性能剖析时能快速建立假设-验证的循环。当你能在脑海中构建出从 CPU 寄存器到远端服务器的完整数据通路，并知道每一跳可能引入的损耗量级，定位问题就不再是盲人摸象，而是一场有地图的探险。