1. 从一次“翻车”的调优说起
去年帮一个朋友看他的数据处理服务，单节点跑批任务，CPU 是当时挺主流的一颗 16 核 32 线程的桌面级处理器，内存 64GB DDR4 3200，硬盘是 PCIe 4.0 的 NVMe SSD。按纸面参数看，这配置处理他那点数据量应该是绰绰有余。结果他跟我说，跑一个大约 200GB 的日志聚合任务，耗时将近 40 分钟，而且 CPU 占用率死活上不去，一直在 30% 上下晃悠。
我上去先看了下top，发现 CPU 的wa（iowait）指标高得离谱，接近 40%。再看iostat，SSD 的利用率直接顶到 100%，但吞吐量只有标称值的四分之一左右。这就很有意思了——硬件明明“很快”，为什么实际跑起来“快不起来”？
后来把任务拆开看，发现他的程序在读取日志文件时，用的是单线程逐行读取，每读一行就做一次字符串分割和正则匹配，然后写数据库。问题出在两个地方：第一，单线程读取根本喂不饱 NVMe 的队列深度；第二，频繁的小块随机写把 SSD 的写放大搞得很难看。换句话说，硬件的“快”是有前提的，它需要软件用正确的方式去“喂”它。
这件事让我觉得有必要把硬件体系结构和性能方法论这块的东西系统梳理一遍。因为太多人——包括不少工作了三五年的开发者——对硬件的理解还停留在“i7 比 i5 快”“SSD 比 HDD 快”这种粗粒度认知上。一旦遇到性能问题，要么盲目升级硬件，要么对着代码瞎改，完全不知道瓶颈到底在哪一层。
这篇文章就是想把“硬件凭什么快”和“为什么有时快不起来”这两个问题讲透。我会从体系结构的基本原理出发，结合性能方法论，把 CPU、内存、存储、总线这几个核心子系统的运作逻辑拆开来讲，然后给出可落地的性能分析方法。适合所有需要跟性能打交道的开发者、运维和架构师，不管你是刚入行还是已经踩过几年坑，应该都能从中找到对自己有用的东西。
2. 硬件凭什么快：体系结构层面的速度来源
2.1 流水线、超标量与乱序执行：CPU 的“快”从何而来
很多人对 CPU 性能的理解就是“主频高就快”，这个认知大概停留在奔腾 4 时代。实际上现代 CPU 的性能来源是一个复杂的组合，主频只是其中一个维度。
先讲流水线。一条指令的执行可以拆成取指、译码、执行、访存、写回五个阶段。如果不做流水线，每条指令串行执行，那 CPU 的吞吐量就是“主频除以每条指令的周期数”。流水线的思路是让这五个阶段并行起来——当第一条指令在执行阶段时，第二条指令已经在译码，第三条在取指。理想情况下，每个时钟周期都能完成一条指令，吞吐量直接翻了好几倍。
但流水线有个天敌叫冒险。比如数据冒险：下一条指令要用到上一条指令的计算结果，但上一条还没写回。这时候要么插入气泡（stall），要么做前递（forwarding），把执行阶段的结果直接送给下一条指令的输入。控制冒险则来自分支跳转——CPU 不知道下一条该取哪条指令，只能靠分支预测来猜。猜对了继续跑，猜错了就要清空流水线，代价是十几个甚至几十个周期的浪费。
超标量是另一个维度。现代 CPU 每个周期可以同时发射多条指令，比如 4 发射、6 发射甚至 8 发射。这意味着前端需要同时取多条指令、同时译码，后端要有多个执行单元（ALU、FPU、Load/Store 单元等）来并行处理。但指令之间往往有依赖关系，超标量的效率取决于指令级并行度（ILP）。
乱序执行就是为了解决依赖问题而生的。CPU 不按程序顺序执行指令，而是看哪些指令的操作数已经就绪，就优先执行哪些。这需要重排序缓冲区（ROB）来保证最终结果按程序顺序提交，还需要寄存器重命名来消除假依赖。乱序执行让 CPU 在遇到长延迟操作（比如访存）时，可以继续执行后面不相关的指令，把等待时间利用起来。
这三者结合起来，才是 CPU“快”的真正原因。但这也解释了为什么有时候“快不起来”——如果你的代码指令级并行度很低，全是串行依赖，那再多的执行单元也帮不上忙。比如一个长链的累加操作，每一步都依赖上一步的结果，乱序执行也无能为力。
实操心得：判断代码是否受限于指令级并行度，可以看 CPU 的 IPC（每周期指令数）。如果 IPC 远低于 CPU 的发射宽度（比如 4 发射的 CPU 只跑到 1.0 IPC），说明代码的并行度不够，或者频繁遭遇分支预测失败和缓存未命中。
2.2 缓存层次与局部性原理：内存墙的应对之道
CPU 主频早就突破了 5GHz，但内存的访问延迟还停留在几十纳秒的量级。如果 CPU 每次都直接访问内存，那大部分时间都在等。这就是所谓的内存墙。
缓存的思路是利用局部性原理。时间局部性是指刚访问过的数据很可能马上又被访问；空间局部性是指访问了某个地址，附近的地址很可能也会被访问。缓存把最近访问过的数据留在离 CPU 更近的地方，下次再访问就不用去内存了。
现代 CPU 通常有三层缓存：L1 最小最快（几十 KB，延迟 4-5 个周期），L2 居中（几百 KB 到几 MB，延迟 10-20 个周期），L3 最大最慢（几十 MB，延迟 30-50 个周期）。L1 和 L2 是每个核心私有的，L3 是所有核心共享的。
缓存的工作单位是缓存行（cache line），通常是 64 字节。这意味着即使你只读一个字节，CPU 也会把整个 64 字节的块加载进来。这个设计对顺序访问非常友好，但对随机访问就不太妙了——每次随机访问都可能触发一次缓存行填充，而填充的 64 字节里可能只有几个字节是有用的。
缓存命中率是性能的关键指标。一次 L1 命中可能只要 4 个周期，一次内存访问可能要 200-300 个周期。如果缓存命中率从 99% 降到 95%，看起来只差了 4 个百分点，但实际性能可能下降好几倍。这就是为什么数据结构的选择和内存访问模式对性能影响巨大。
举个例子，同样是遍历一个二维数组，按行遍历和按列遍历的性能可能差好几倍。因为 C 语言里二维数组是行优先存储的，按行遍历是顺序访问，缓存行利用率高；按列遍历是跳跃访问，每次都可能触发缓存未命中。
2.3 存储介质的物理极限：SSD 为什么也会“慢”
SSD 的“快”来自 NAND 闪存的并行性。一颗 SSD 内部有多颗闪存芯片，每颗芯片内部又有多个 die、plane。主控可以把读写请求分散到不同的芯片和 die 上并行处理，从而实现远高于单颗芯片的吞吐量。
但 SSD 有几个物理限制。第一，读写不对称。NAND 闪存的编程（写）操作比读取操作慢得多，而且写入前必须先擦除。擦除的单位是块（block），通常几百 KB 到几 MB，而读写的单位是页（page），通常 4KB 到 16KB。这就导致了写放大——当你写入一个 4KB 的页时，如果目标块里已经有数据，主控需要先把整个块读出来，修改后再写回去。写放大会显著缩短 SSD 寿命，也会降低写入性能。
第二，垃圾回收。SSD 不能像 HDD 那样原地覆盖写，必须写到新的页，然后把旧页标记为无效。当无效页积累到一定程度，主控需要做垃圾回收，把有效页搬移到一起，腾出完整的块来擦除。垃圾回收期间，SSD 的读写性能会明显下降。
第三，队列深度。SSD 的并行性需要足够的队列深度来喂。如果软件只发一个请求，等它完成再发下一个，那 SSD 内部的并行通道根本用不起来。这就是为什么 NVMe 协议支持高达 64K 的队列深度，而 AHCI 只有 32 个命令槽。
回到开头那个案例，朋友的程序单线程逐行读取，队列深度基本是 1，NVMe 的并行性完全没发挥出来。后来改成多线程分块读取，每个线程负责一段文件，队列深度上去了，读取吞吐量直接翻了四倍。
2.4 总线与互连：数据高速公路的通行规则
CPU、内存、外设之间需要通过总线或互连来通信。传统的前端总线（FSB）早就被点对点互连取代了。Intel 的 QPI/UPI、AMD 的 Infinity Fabric，都是把内存控制器集成到 CPU 内部，通过高速串行链路连接各个组件。
PCIe 是目前外设互连的主流标准。PCIe 3.0 x4 的理论带宽是 4GB/s 左右，PCIe 4.0 x4 翻倍到 8GB/s，PCIe 5.0 x4 再翻倍到 16GB/s。但这是理论值，实际有效带宽还要考虑协议开销、编码方式等因素。
总线的带宽是共享的。如果多个设备同时争抢总线带宽，每个设备能分到的就少了。比如一块 NVMe SSD 和一块显卡同时跑，如果它们共享 PCIe 通道，就可能互相影响。这也是为什么高端主板会把 CPU 提供的 PCIe 通道和芯片组提供的通道分开标注。
注意事项：在排查性能问题时，不要忽略总线层面的瓶颈。用
lspci -vv可以看到每个 PCIe 设备的链路宽度和速率。如果一块 PCIe 4.0 的 SSD 跑在 PCIe 3.0 的插槽上，带宽直接减半，但很多人根本不会注意到这一点。
3. 为什么有时快不起来：性能瓶颈的常见来源
3.1 阿姆达尔定律与并行化的天花板
阿姆达尔定律是性能优化领域最基础的定律之一。它说的是：如果一个任务中有一部分必须串行执行，那么无论你怎么增加并行度，整体加速比都有一个上限。
公式很简单：加速比 = 1 / (S + P/N)，其中 S 是串行部分的比例，P 是并行部分的比例（S + P = 1），N 是并行度。当 N 趋向无穷大时，加速比趋向于 1/S。也就是说，如果 10% 的代码必须串行，那最大加速比就是 10 倍，哪怕你有 1000 个核心。
这个定律解释了为什么很多程序在核心数增加到一定程度后，性能就不再提升了。比如一个任务 95% 可以并行，5% 必须串行，那 16 核的加速比大约是 1/(0.05 + 0.95/16) ≈ 9.1 倍，32 核是 1/(0.05 + 0.95/32) ≈ 11.9 倍。从 16 核到 32 核，核心数翻倍，但加速比只提升了 30%。
更麻烦的是，并行化本身也有开销。线程创建、同步、通信都需要时间。当并行粒度太细时，开销可能超过收益。这就是为什么有时候单线程反而比多线程快——多线程的同步开销吃掉了并行带来的好处。
3.2 内存带宽与延迟：被忽视的隐形瓶颈
很多人优化性能时只盯着 CPU 利用率，看到 CPU 没跑满就觉得还有余量。但实际上，内存带宽和内存延迟经常是真正的瓶颈。
内存带宽是指单位时间内能从内存读取或写入的数据量。DDR4 3200 双通道的理论带宽是 51.2GB/s，DDR5 4800 双通道是 76.8GB/s。看起来很大，但如果你跑的是内存密集型任务，比如大规模矩阵运算、数据聚合、视频编解码，内存带宽很容易被打满。
内存延迟则是另一个维度。一次内存访问的延迟大约是 60-100 纳秒，而一次 L1 缓存访问只要 1 纳秒左右。如果代码的缓存命中率低，CPU 大部分时间都在等内存，那再高的主频也没用。
判断是否受限于内存，可以看 CPU 的stall周期数，或者用性能计数器看LLC-miss（最后一级缓存未命中）的比例。如果 LLC 未命中率很高，说明数据访问模式对缓存不友好，需要优化数据布局或访问顺序。
3.3 锁竞争与伪共享：多核时代的暗坑
多核编程里有两个经典的性能杀手：锁竞争和伪共享。
锁竞争是指多个线程同时争抢同一把锁。拿不到锁的线程只能等待，CPU 时间被浪费在自旋或上下文切换上。锁的粒度越粗，竞争越激烈。比如用一个全局锁保护整个哈希表，那所有线程的读写都要串行化，并行度直接归零。
伪共享更隐蔽。前面说过，缓存的工作单位是缓存行（64 字节）。如果两个线程分别修改同一个缓存行里的不同变量，虽然它们逻辑上不冲突，但硬件层面会认为它们在争抢同一个缓存行。每次一个线程修改，另一个线程的缓存行就失效了，必须重新从内存加载。这会导致大量的缓存失效和内存流量，性能急剧下降。
解决伪共享的办法是填充（padding），把每个线程独立使用的变量放到不同的缓存行里。比如在变量前后各加 64 字节的填充，确保它独占一个缓存行。
struct padded_counter { char pad1[64]; long counter; char pad2[64]; };实操心得：伪共享问题在性能剖析工具里往往表现为“莫名其妙的缓存未命中”和“内存带宽异常高”。如果你看到多个核心在修改相邻的变量，而性能远低于预期，优先怀疑伪共享。用
perf c2c可以检测缓存行竞争。
3.4 I/O 路径上的层层损耗
从应用程序发起一次 I/O 请求，到数据真正落到存储介质上，中间要经过很多层：系统调用、文件系统、块层、设备驱动、控制器、最后到存储介质。每一层都有开销，每一层都可能成为瓶颈。
系统调用本身就有开销，一次read或write系统调用大约需要几百纳秒到几微秒。如果 I/O 请求很小很频繁，系统调用的开销占比就会很高。这就是为什么批量 I/O 比逐条 I/O 效率高——把 1000 次小请求合并成 10 次大请求，系统调用次数减少两个数量级。
文件系统的开销也不可忽视。日志文件系统（如 ext4）在写入时需要先写日志，再写数据，这增加了额外的写入量。如果对数据安全性要求不高，可以用data=writeback模式减少日志开销。更极端的情况下，直接用裸设备或 SPDK 绕过内核，可以进一步降低开销。
块层的 I/O 调度器也会影响性能。传统的cfq调度器适合机械硬盘，会做请求合并和排序；但对于 NVMe SSD，none或mq-deadline调度器通常更好，因为 SSD 本身就有很强的并行处理能力，不需要内核再做太多调度。
4. 性能方法论：从测量到优化的完整闭环
4.1 USE 方法：快速定位资源瓶颈
USE 方法是 Brendan Gregg 提出的性能分析框架，三个字母分别代表 Utilization（利用率）、Saturation（饱和度）、Errors（错误）。对每一种资源（CPU、内存、磁盘、网络），都检查这三个指标。
利用率是指资源在单位时间内有多少时间处于忙碌状态。CPU 利用率 80% 意味着 80% 的时间 CPU 在执行指令。但利用率高不一定就是瓶颈——如果 CPU 利用率 100% 但任务吞吐量还在提升，说明 CPU 还没到极限。利用率低也不一定就没问题——如果 CPU 利用率只有 30% 但任务很慢，说明瓶颈在别处。
饱和度是指资源排队等待的程度。CPU 的饱和度可以用运行队列长度来衡量，如果运行队列长度持续大于核心数，说明有任务在等 CPU。磁盘的饱和度可以用 I/O 队列深度来衡量。饱和度高说明资源不够用，需要扩容或优化。
错误是指资源层面的错误计数，比如网卡的丢包、磁盘的坏道、内存的 ECC 错误。这些错误往往会导致性能下降，但容易被忽略。
USE 方法的好处是系统化，不会漏掉某个资源。排查性能问题时，先对每个资源过一遍 USE，通常很快就能定位到瓶颈所在。
4.2 火焰图与性能剖析：找到代码层面的热点
定位到瓶颈资源后，下一步是找到具体是哪段代码导致的。火焰图是目前最直观的性能剖析可视化工具。
火焰图的原理是对调用栈进行采样，每个采样点记录当前的调用栈，然后把所有采样点聚合起来。横轴是采样比例，纵轴是调用栈深度。每个矩形代表一个函数，宽度代表它占用的 CPU 时间比例。火焰图从上往下看是调用关系，从下往上看是时间分布。
看火焰图有几个技巧。第一，找“平顶”——如果某个函数在火焰图顶部很宽，说明它自己消耗了大量 CPU，而不是在等子函数。第二，找“宽底”——如果某个底层函数很宽，说明它被很多上层函数调用，可能是公共热点。第三，注意颜色——通常红色代表 CPU 密集，蓝色代表 I/O 等待，但不同工具的颜色方案可能不同。
生成火焰图通常用perf采样，然后用 FlameGraph 工具链处理：
perf record -F 99 -g -- ./your_program perf script | stackcollapse-perf.pl | flamegraph.pl > flamegraph.svg-F 99表示每秒采样 99 次，-g表示记录调用栈。采样频率不要太高，否则开销太大；也不要太低，否则统计意义不够。99Hz 是一个常用的折中值。
4.3 基准测试与对照实验：用数据说话
性能优化最忌讳的就是“我觉得这样会更快”。人的直觉在性能问题上往往不准，必须用数据说话。
基准测试的关键是控制变量。每次只改一个因素，其他条件保持一致。比如你想测试缓存行对齐对性能的影响，那就只改对齐方式，其他代码、数据规模、运行环境都不变。跑多次取平均值，去掉异常值。
对照实验是另一个重要方法。如果你怀疑某个因素是瓶颈，可以做一个“移除实验”——把可疑因素去掉，看性能是否提升。比如怀疑锁竞争是瓶颈，可以把锁去掉（哪怕结果不正确），看性能能提升多少。如果去掉锁之后性能大幅提升，说明锁竞争确实是瓶颈。
基准测试还要注意预热。JIT 编译、缓存预热、连接池初始化等都需要时间。如果测试时间太短，测到的可能只是预热阶段的性能。通常建议先跑几轮预热，等性能稳定后再开始计时。
注意事项：基准测试的环境要尽量干净。关掉不必要的后台进程，固定 CPU 频率（关闭睿频），绑定 CPU 核心，避免 NUMA 跨节点访问。这些细节看起来琐碎，但对测试结果的可靠性影响很大。
4.4 从微基准到系统级：不同粒度的性能视角
性能分析可以在不同粒度上进行，每个粒度看到的东西不一样。
微基准是针对某个特定操作或函数的测试，比如测量一次哈希查找的耗时、一次内存拷贝的带宽。微基准的好处是干净、可控，能精确测量某个因素影响。但微基准的结果不一定能直接推广到真实场景，因为真实场景中有太多微基准里没有的因素。
模块级基准是针对某个模块或组件的测试，比如数据库的写入吞吐量、消息队列的端到端延迟。模块级基准比微基准更接近真实场景，但仍然简化了很多因素。
系统级基准是端到端的测试，模拟真实的工作负载。比如用 YCSB 测试数据库、用 wrk 测试 Web 服务。系统级基准最能反映真实性能，但变量太多，很难定位具体瓶颈。
实践中通常是从系统级基准开始，发现性能不达标后，逐步下钻到模块级和微基准，定位到具体问题后再回到系统级验证优化效果。这个“自顶向下”的分析路径比“自底向上”更高效，因为系统级的问题往往不是单个微基准能暴露的。
5. 典型场景下的性能问题拆解
5.1 高并发网络服务：从网卡到应用的完整链路
一个高并发网络服务的性能瓶颈可能出现在链路的任何一环。从网卡收到数据包开始，到应用层处理完请求返回响应，中间要经过网卡驱动、内核协议栈、socket 层、应用层。
网卡层面，中断处理是第一个开销。每个数据包到达都会触发中断，如果包速率很高，中断处理本身就会消耗大量 CPU。NAPI（New API）机制通过轮询加中断的方式减少中断次数，但轮询本身也有开销。更激进的做法是用DPDK或XDP绕过内核协议栈，直接在用户态处理数据包。
内核协议栈层面，TCP 的处理涉及连接管理、拥塞控制、流量控制、重传等。这些逻辑很复杂，开销也不小。如果服务只需要简单的请求-响应模式，可以考虑用 UDP 或 QUIC 来减少协议栈开销。
应用层面，常见的瓶颈包括线程模型、内存分配、序列化/反序列化。比如每个请求创建一个线程的模型，在高并发下线程创建和上下文切换的开销会很大。改用事件驱动或协程模型可以显著降低开销。
5.2 大数据处理：当 CPU 不是瓶颈时看什么
大数据处理任务通常被认为是 CPU 密集型的，但实际上很多任务受限于内存带宽或 I/O。
比如一个简单的group by聚合，如果数据量远大于缓存，那每次访问都可能触发内存读取。这时候内存带宽就是瓶颈，CPU 大部分时间在等数据。优化方向是减少内存访问量——用更紧凑的数据结构、做分块处理让数据留在缓存里、用 SIMD 指令一次处理多个数据。
再比如排序操作，如果数据量大于内存，就需要外部排序，涉及大量的磁盘 I/O。这时候 I/O 带宽和延迟就是瓶颈。优化方向是减少 I/O 次数——用更大的缓冲区、做多路归并减少读写轮次、用压缩减少数据量。
判断大数据任务是否受限于 CPU，可以看 CPU 的 IPC 和 stall 周期。如果 IPC 很低、stall 周期很高，说明 CPU 在等内存或 I/O，单纯增加 CPU 核心数没用。
5.3 数据库场景：随机读写与日志写入的博弈
数据库的性能问题通常集中在两个地方：随机读写和日志写入。
随机读写主要发生在索引查找和数据页访问。B+ 树的查找需要多次随机访问，每次都可能触发磁盘 I/O。如果索引太大放不进内存，性能会急剧下降。优化方向包括：增大缓冲池、用更紧凑的索引结构、做分区减少索引大小。
日志写入是另一个关键路径。数据库需要保证事务的持久性，通常采用 WAL（Write-Ahead Logging）机制，先把日志写到磁盘，再写数据页。日志写入是顺序的，但每次事务提交都需要 fsync 确保日志落盘，这个 fsync 的延迟直接决定了事务的响应时间。
优化日志写入的方法包括：批量提交（把多个事务的日志合并成一次 fsync）、用非易失性内存（NVDIMM）做日志设备、调整日志文件系统的挂载参数。但要注意，这些优化可能牺牲一定的持久性保证，需要根据业务场景权衡。
5.4 容器与虚拟化：抽象层的性能代价
容器和虚拟化带来了部署的便利性，但也引入了额外的性能开销。
容器本身的开销很小，因为容器共享宿主机的内核，没有硬件虚拟化。但容器的网络和存储通常有额外开销。比如 Docker 默认的 bridge 网络需要做 NAT，增加了数据包的处理路径。用 host 网络模式可以避免这个开销，但牺牲了网络隔离。
虚拟机的开销更大，因为需要模拟硬件、运行独立的操作系统。CPU 虚拟化通过硬件扩展（Intel VT-x、AMD-V）已经接近原生性能，但 I/O 虚拟化仍然是瓶颈。virtio 半虚拟化驱动比全模拟设备快很多，但相比原生设备仍有差距。SR-IOV 可以让虚拟机直接访问物理设备，性能接近原生，但配置复杂且需要硬件支持。
实操心得：在容器或虚拟机中做性能测试时，一定要先测裸机的基线性能。否则你无法区分性能问题是应用本身导致的，还是虚拟化层引入的。我见过不少团队在容器里测出性能不达标，花了很多时间优化应用，最后发现是容器网络配置的问题。
6. 性能优化的常见误区与避坑指南
6.1 过早优化与过度优化：平衡的艺术
Donald Knuth 那句“过早优化是万恶之源”被引用了太多次，以至于很多人把它当成不优化的借口。但这句话的本意是：不要在没有测量数据的情况下凭直觉优化。如果你已经通过 profiling 定位到了瓶颈，那优化就不是“过早”。
反过来，过度优化也是问题。为了追求极致的性能，把代码写得极其复杂、难以维护，但实际收益可能只有几个百分点。这种优化不值得。优化的收益应该和它带来的复杂度成正比。如果优化让代码复杂度翻倍但性能只提升 5%，那不如不做。
判断是否值得优化的一个简单标准：这个优化是否解决了实际的性能问题？如果当前性能已经满足需求，那就不需要优化。如果性能不达标，那就优化瓶颈最大的部分，而不是所有部分。
6.2 盲目升级硬件：钱要花在刀刃上
遇到性能问题就升级硬件，这是最省事但也最费钱的做法。而且很多时候，升级硬件并不能解决问题。
比如一个受限于单线程性能的应用，你给它加再多核心也没用。一个受限于内存延迟的应用，你给它换更高频率的内存可能只有几个百分点的提升。一个受限于随机 I/O 的应用，你给它换更大容量的 SSD 也不解决问题。
正确的做法是先做性能分析，定位到瓶颈资源，然后针对性地升级。如果瓶颈是 CPU 单核性能，那就选单核性能更强的 CPU；如果瓶颈是内存带宽，那就增加内存通道数或换更高频率的内存；如果瓶颈是 I/O 延迟，那就换更低延迟的存储设备。
6.3 忽视可观测性：没有数据就没有优化
性能优化的前提是能观测到性能数据。如果系统没有埋点、没有监控、没有日志，那优化就是盲人摸象。
可观测性包括三个层面：指标（metrics）、日志（logs）、追踪（traces）。指标是聚合的数值，比如 QPS、延迟、错误率；日志是离散的事件记录；追踪是请求级别的调用链。
对于性能优化来说，指标是最基础的。你需要知道系统的吞吐量、延迟分布、资源利用率。延迟分布尤其重要——平均值会掩盖长尾问题，P99、P999 才能反映真实用户体验。
追踪则能帮你定位到具体是哪个环节慢。一个请求经过多个服务，如果没有追踪，你很难知道是哪个服务拖慢了整体。OpenTelemetry 是目前主流的追踪标准，支持多种语言和后端。
6.4 忽略工作负载特征：不同场景不同策略
性能优化没有银弹，不同的工作负载需要不同的策略。
CPU 密集型任务关注的是指令级并行度、分支预测、缓存命中率。优化方向包括算法优化、SIMD 向量化、减少分支。
内存密集型任务关注的是内存带宽和延迟。优化方向包括数据布局优化、缓存分块、预取。
I/O 密集型任务关注的是吞吐量和延迟。优化方向包括批量处理、异步 I/O、减少数据拷贝。
延迟敏感型任务关注的是 P99 延迟。优化方向包括减少排队、避免锁竞争、用无锁数据结构。
吞吐量敏感型任务关注的是单位时间处理量。优化方向包括提高并行度、流水线化、减少同步开销。
在优化之前，先搞清楚你的工作负载属于哪一类，然后选择对应的策略。用错策略可能适得其反。
7. 我在实际调优中积累的几个判断技巧
调优这件事，工具和方法论是基础，但真正拉开差距的往往是经验直觉。分享几个我在实际工作中总结的判断技巧，不一定严谨，但实战中挺管用。
第一，看 CPU 利用率的同时看 IPC。如果 CPU 利用率高但 IPC 低，说明 CPU 在空转等数据，瓶颈在内存或 I/O。如果 CPU 利用率高且 IPC 也高，说明 CPU 确实在干活，可以考虑加核心或优化算法。如果 CPU 利用率低但任务慢，那瓶颈肯定不在 CPU，去查 I/O、锁、网络。
第二，延迟问题优先怀疑排队。如果一个请求的延迟很高，但 CPU、内存、磁盘的利用率都不高，那大概率是排队导致的。排队可能发生在锁、连接池、线程池、队列等任何地方。找到排队点，要么增加资源，要么减少排队时间。
第三，吞吐量问题优先怀疑并行度。如果吞吐量上不去，先看并行度够不够。单线程程序加线程，多线程程序看锁竞争，分布式系统看分片是否均匀。并行度不够的原因可能是串行部分太多（阿姆达尔定律），也可能是同步开销太大。
第四，性能突然下降优先怀疑外部变化。如果系统之前跑得好好的，突然变慢了，先别急着改代码。查一下最近有没有部署新版本、有没有改配置、数据量有没有突增、有没有其他进程在抢资源。很多性能问题不是代码本身的问题，而是环境变化导致的。
第五，优化效果要能量化。每次优化前后都要有明确的性能数据对比。如果优化后性能没有明显提升，要么是优化方向错了，要么是瓶颈不在那里。不要因为“理论上应该更快”就认为优化有效，数据不会骗人。
最后再分享一个小技巧：在做性能优化时，准备一个“性能日志”，记录每次优化的假设、操作、结果和结论。过一段时间回头看，你会发现很多当时觉得理所当然的判断其实是错的，而这些错误正是经验积累的来源。
