这一章在做什么

什么时候翻这一章

• 服务读写文件偶尔很慢，不知道算不算盘的问题先在应用这一层（或文件系统这一层）量延迟，算出它占请求时间的比例。占比很小，就别在存储上花时间。§8.5.2§8.6.14场景手册 →
• 平均读延迟不高，p99 却很难看缓存命中和未命中混在一起，分布是两个峰；平均值落在两峰中间，什么也说明不了。看直方图，盯住慢的那一峰。§8.6.13§8.6.18场景手册 →
• ARM 板写 eMMC 或 SD 卡，一写日志就卡多半是同步写（O_SYNC、每条一次 fsync）在等闪存；也可能是脏页攒得太多，写的进程被拉去一起写回。§8.3.6§8.3.7§7.6.1场景手册 →
• free 里几乎没有空闲内存，buff/cache 占了一大半这是正常的：闲着的内存被拿去做文件缓存，应用要用时内核会收回来。该看的是 available。§8.3.2§8.6.2场景手册 →
• iostat 里盘一阵一阵地忙，应用却不慢后台写回、预读、别的进程都会产生没人在等的磁盘 IO。逻辑 IO 和物理 IO 对不上是常态。§8.3.12场景手册 →
• 自己做的读写测试，数字好得不像真的测试文件比内存小，测到的是缓存，不是盘。§8.5.8§8.7.1场景手册 →

page cache 的回收、换页和 dirty 系列参数在第 7 章（内存）；盘本身的延迟、利用率、iostat 在第 9 章。一条常见的排查路线是：先在这一章确认应用确实在等文件系统，再往第 9 章走。

先用中文过一遍

page cache：命中和未命中差两三个数量级

Linux 把读过的文件内容留在内存里，叫页缓存（page cache）。下次再读同一块，内核在内存里就找到了，几微秒返回，这是命中（cache hit）；找不到才去存储设备读，要等几百微秒到几毫秒，这是未命中（cache miss），读上来的数据顺手放进缓存（§8.2.2）。缓存会慢慢长到占满闲着的内存，这是故意的：内存闲着也是闲着，应用要用时内核再从缓存里回收（§8.3.2）。所以 free 里 free 一栏很小、buff/cache 很大，一般不用担心，看 available 就行。

两种结果的耗时差了两三个数量级，混在一起就是一个双峰分布（bimodal distribution）：左边一个峰是命中，右边一个峰是未命中。这时平均值落在两峰之间的低谷，几乎没有哪一次请求真的花了那么久；中位数也一样，命中率高时它只反映命中那一峰（§8.6.18）。书里因此坚持看完整的分布（直方图、热图），或者把慢的操作逐条列出来（§8.5.2）。命中率 99% 时，平均值几乎全由命中决定，那 1% 的慢请求被淹没在里面，而它们恰恰是用户在抱怨的。

写回和同步写：write() 返回不等于落盘

写的一侧默认是写回缓存（write-back caching）：write() 把数据拷进内核的页缓存、把这些页标成脏页（dirty page），就返回了，应用只花了拷内存的时间。真正写到盘上是之后的事，由内核的 flusher 线程在后台做：脏页放了一段时间（默认约 30 秒），脏页总量超过阈值，或者有人调了 sync、fsync，都会触发写回（§8.4.3）。代价是可靠性：掉电时，还没写下去的脏页就丢了（§8.3.6）。

不能丢数据的程序用同步写（synchronous write）：文件用 O_SYNC / O_DSYNC 打开，每次 write() 都等数据和必要的元数据落盘才返回；或者照常写，到一个检查点再调一次 fsync()，把之前的写一起提交（§8.3.7）。后者通常快得多，因为一批写只等一次盘。嵌入式板子上这件事特别要紧：慢的闪存上每等一次都可能是毫秒级，一个每条日志都 fsync 的线程，吞吐就被钉死在每秒几百条甚至更少。

预读和直接 IO：两种绕开等待的办法

顺序读一个大文件，按说每一块第一次读都该未命中。实际上很快，因为文件系统发现偏移量一个接一个，就提前把后面的几块读进缓存，这叫预取（prefetch），Linux 上一般叫预读（read-ahead）（§8.3.4）。猜对了，应用的读全是命中；猜错了，白读的数据占着缓存、占着盘的带宽。随机读没法预读，这也是随机读比顺序读慢得多的原因之一（§8.3.3）。

另一头是直接 IO（direct I/O）：用 O_DIRECT 打开文件，读写都绕过页缓存（§8.3.8）。数据库这类自己管缓存的程序用它，免得同一份数据在两处各缓存一遍。它还常被拿来做测试，量的是盘而不是缓存。注意它不是同步写：O_DIRECT 不承诺 O_SYNC 那样的落盘保证，而且对缓冲区地址、IO 大小有对齐要求，不对齐可能直接返回 EINVAL。

逻辑 IO 和物理 IO：应用看到的不是盘看到的

应用发给文件系统的读写叫逻辑 IO（logical I/O），文件系统发给盘的叫物理 IO（physical I/O）。两者常常对不上（§8.3.12）：有的缩水了（命中缓存就没有物理 IO，多次改同一块只写回一次），有的膨胀了（改几个字节要读写整块，再加一份日志），有的是间接的（预读、后台写回），有的跟你的应用根本无关（别的进程、备份、RAID 重建）。这就是书里不推荐只盯着磁盘排查的原因（§8.5.1）：盘上 50 毫秒的写，可能没有任何请求在等；应用卡住的那次读，在盘上可能根本不存在（它在等一把锁，或者在等同一个文件上的 fsync）。

方法：按什么顺序查

书里建议先用这几种方法，顺序是：延迟分析、性能监控、负载特征、微基准测试、静态性能调优（§8.5）。核心是第一个：从应用这一侧量文件系统操作的延迟，而不是先看盘。落到一次排查上，本站整理成下面六步。前两步决定要不要继续查文件系统；要 root 的 BPF 工具从第二步开始出场，没有它们时每一步都给了退路。

1. 文件系统占了请求时间的多少？

   在应用里给读、写、fsync 计时，或者对一个线程短时间跑 strace -c / strace -T 粗看。占比 = 一个请求里阻塞在文件系统上的时间 ÷ 请求总时间。占九成，消掉它最多能快近十倍；只占百分之一，就去查别处。§8.5.2

2. 延迟的分布长什么样？

   ext4dist-bpfcc 10 1（要 root）按操作类型给出直方图。只有左边一个微秒级的峰，说明读几乎全命中，文件系统不是问题；右边有一个毫秒级的峰，再看它占多少。没有 BPF 时，在应用里自己按 2 的幂分桶计数，就是同一张图（见下面第二个实验）。§8.6.13§8.6.18

3. 慢的那几次是什么操作、哪个文件、谁发的？

   ext4slower-bpfcc 1 列出超过 1 毫秒的操作。类型是 S（fsync）的多，是同步写在等盘；R 的多，是读未命中。只有 strace 时用 strace -T -e trace=read,write,fsync -p PID，但要记住它会把每次调用拖慢一大截。§8.6.14§8.6.7

4. 施加的负载是什么样的？

   谁在读写哪些文件：opensnoop-bpfcc、filetop-bpfcc -C；读写比例、同步写有多少、顺序还是随机。/proc/PID/io 里 rchar 是读了多少（逻辑），read_bytes 是真正从存储层取了多少（物理），两者一比就知道命中了多少。常常能找到根本不该做的读写（反复打开同一个配置文件、调试日志没关）。§8.5.3§8.6.10§8.6.11

5. 缓存够不够、写回压不压得住？

   free -m 看 buff/cache 和 available；cachestat-bpfcc 1 看命中率；grep -E 'Dirty|Writeback' /proc/meminfo 看脏页有多少。命中率低，先比一比工作集和可用内存：应用自己的内存占得太多，留给缓存的就少。§8.6.2§8.6.12§8.5.8

6. 配置有没有问题？

   mount 看文件系统类型和挂载选项（relatime / noatime、有没有 sync）；df -h 看是不是快满了；程序是 O_SYNC 逐条写还是攒一批 fsync。这些都排除了，延迟确实来自盘，就到第 9 章去看盘本身。§8.5.5§8.6.1§8.3.16

工具速查

free、vmstat、slabtop 在 procps 包里，sar 在 sysstat，strace 和 fatrace 各是一个同名包。带 -bpfcc 后缀的是 Debian bpfcc-tools 包里的 BCC 工具，和 fatrace、slabtop 一样都要 root。工具名链到本站的工具卡：free、strace、fatrace、opensnoop、filetop、cachestat、ext4dist、ext4slower、slabtop。

动手：在自己的机器上试

# 在自己的目录里做，文件总量控制在两三百 MB 以内
$ mkdir -p ~/fslab && cd ~/fslab
$ free -m
$ dd if=/dev/urandom of=f1 bs=1M count=128 status=none
$ free -m
# 先把 f1 落盘，再请内核把它的页从缓存里丢掉
$ sync f1
$ dd if=f1 iflag=nocache count=0 status=none
$ free -m
# 冷读、热读、绕过缓存各一次
$ dd if=f1 of=/dev/null bs=1M
$ dd if=f1 of=/dev/null bs=1M
$ dd if=f1 of=/dev/null bs=1M iflag=direct

buff/cache（MB）  写之前 1867   写完 f1 1998   丢掉 f1 的缓存后 1867

冷读  134217728 bytes copied, 0.142748 s, 940 MB/s
热读  134217728 bytes copied, 0.0316084 s, 4.2 GB/s
直接  134217728 bytes copied, 0.0531463 s, 2.5 GB/s

$ dd if=/dev/zero of=f2 bs=4k count=2000
# 每次写都等落盘（相当于 O_DSYNC）
$ dd if=/dev/zero of=f2 bs=4k count=2000 oflag=dsync
# 照常写，最后 fsync 一次
$ dd if=/dev/zero of=f2 bs=4k count=2000 conv=fsync
# 看脏页什么时候被写回：写 100 MB，每 5 秒看一次 Dirty
$ dd if=/dev/zero of=f3 bs=1M count=100 status=none
$ for i in $(seq 0 8); do grep '^Dirty:' /proc/meminfo; sleep 5; done
$ rm -f f1 f2 f3

普通写    8192000 bytes copied, 0.0206156 s, 397 MB/s
dsync     8192000 bytes copied, 3.19233 s, 2.6 MB/s
末尾 fsync 8192000 bytes copied, 0.0162681 s, 504 MB/s

Dirty（每 5 秒）  104700  103804  107076  107292  98696
                  99104  105156  9112  11608   （kB）

// lat.c：随机读一个文件 N 次（每次 4 KB），给每次 pread 计时，打印对数直方图
#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <sys/stat.h>

static long long now_ns(void) {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ts.tv_sec * 1000000000LL + ts.tv_nsec;
}

static int cmp(const void *a, const void *b) {
    long long x = *(const long long *)a, y = *(const long long *)b;
    return (x > y) - (x < y);
}

int main(int argc, char **argv) {
    if (argc < 3) { fprintf(stderr, "usage: %s FILE N\n", argv[0]); return 1; }
    int fd = open(argv[1], O_RDONLY);
    if (fd < 0) { perror("open"); return 1; }
    int n = atoi(argv[2]);
    struct stat st; fstat(fd, &st);
    long blocks = st.st_size / 4096;
    posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM);   // 关掉预读，每次未命中只读这一块
    static char buf[4096];
    long long *t = malloc(sizeof(long long) * n), sum = 0;
    int hist[32] = {0};
    srand(42);                                     // 固定种子：每次跑读的是同一串偏移
    for (int i = 0; i < n; i++) {
        off_t off = (off_t)(rand() % blocks) * 4096;
        long long t0 = now_ns();
        if (pread(fd, buf, sizeof buf, off) != sizeof buf) { perror("pread"); return 1; }
        t[i] = (now_ns() - t0) / 1000;             // 微秒
        sum += t[i];
        int b = 0; while (b < 31 && (2LL << b) <= t[i]) b++;   // 落在 [2^b, 2^(b+1)) 这一桶
        hist[b]++;
    }
    for (int b = 0; b < 32; b++)
        if (hist[b]) printf("%6lld -> %-6lld us : %d\n", b ? 1LL << b : 0, (2LL << b) - 1, hist[b]);
    qsort(t, n, sizeof *t, cmp);
    printf("avg %lld us, p50 %lld us, p99 %lld us\n", sum / n, t[n / 2], t[n * 99 / 100]);
    return 0;
}

$ gcc -O2 -Wall lat.c -o lat
$ dd if=/dev/urandom of=f1 bs=1M count=128 status=none
# 全冷：丢掉 f1 的缓存再读
$ sync f1; dd if=f1 iflag=nocache count=0 status=none
$ ./lat f1 4000
# 全热：同一串偏移再读一遍，刚才读过的块都在缓存里
$ ./lat f1 4000
# 一半热：丢掉缓存，只把前 64 MB 读进来，再随机读整个文件
$ dd if=f1 iflag=nocache count=0 status=none
$ dd if=f1 of=/dev/null bs=1M count=64 status=none
$ ./lat f1 4000

     0 -> 1      us : 721
     2 -> 3      us : 1104
     4 -> 7      us : 216
     8 -> 15     us : 120
    16 -> 31     us : 17
    64 -> 127    us : 162
   128 -> 255    us : 1630
   256 -> 511    us : 25
   512 -> 1023   us : 3
  1024 -> 2047   us : 2
avg 74 us, p50 5 us, p99 245 us

$ dd if=f1 of=/dev/null bs=1M status=none
$ ./lat f1 4000 | tail -1
$ strace -o /dev/null -e trace=pread64 ./lat f1 4000 | tail -1
$ rm -f f1

直接跑      avg 0 us, p50 1 us, p99 1 us
strace 下   avg 141 us, p50 133 us, p99 219 us

动手：模拟器

先猜：命中率 90%，命中 2 微秒，未命中 1 毫秒（慢一点的闪存），平均延迟是多少？有多少次读的耗时接近这个平均值？再把命中率调到 99%，平均值降了多少，那 1% 的慢请求还在不在？

1. 默认设置读 1000 次：平均值落在哪？「落在平均值 ±30% 内的读」是多少？再把未命中换成机械盘，平均值翻了几倍，两个峰本身变了吗？
2. 命中率从 90% 调到 99%、再到 99.9%：p50 几乎不动，平均值一路下降。到 99.9% 时读 1000 次，p99 落在哪一峰？这就是为什么高命中率时平均值和中位数都看不见那几次慢读，要看 p99、p99.9 或者逐条列慢操作。
3. 把命中延迟从 2 微秒改成 10 微秒（比如每次读还要多走一层加密或校验）：命中率 99% 时，它对平均值的影响和「未命中从 1 毫秒变成 8 毫秒」比，哪个大？

成书之后

分节地图

这一章还是那个套路：背景（§8.1–8.3）、架构（§8.4）、方法（§8.5）、工具（§8.6）、实验和调优（§8.7–8.8）。上手要读的是概念里讲缓存、预读、写回、同步写、逻辑与物理 IO 的几节，架构里的 Linux 缓存，方法里的延迟分析和微基准测试，工具里的 free 和三个 BPF 工具，最后是讲双峰的可视化。各种文件系统的细节、ZFS 的调优用到再查或者跳过。

1. File system performance often matters more…约 300 词开篇为什么文件系统比盘更贴近应用；学习目标和六个部分。
2. Terminology约 300 词术语本章的 IO 只算直接读写的操作，open、close 不算。
3. Models约 100 词模型一句引子。
4. File System Interfaces约 100 词文件系统的接口把文件系统当黑盒，只量各种操作的延迟。
5. File System Cache约 100 词文件系统缓存命中、未命中、预热；写也会先缓冲。
6. Second-Level Cache约 100 词二级缓存闪存做的第二级缓存，主要是 ZFS 的做法，一般用不到。
7. Concepts约 100 词概念一句引子。
8. File System Latency约 300 词文件系统延迟首要指标；哪些情况下应用并不直接等它。
9. Caching约 200 词缓存缓存吃掉空闲内存为什么是正常的；几种缓存。
10. Random vs. Sequential I/O约 200 词随机与顺序 IO按偏移量区分；碎片让顺序读变成随机读。
11. Prefetch约 300 词预取顺序读怎么被提前读进缓存；猜错的代价。
12. Read-Ahead约 100 词预读Linux 的叫法和 readahead 系统调用。
13. Write-Back Caching约 200 词写回缓存写进内存就返回，稍后再刷；掉电的风险。
14. Synchronous Writes约 200 词同步写逐次同步写和用 fsync 成批提交的区别。
15. Raw and Direct I/O约 200 词裸 IO 与直接 IO绕过文件系统和只绕过缓存；对齐和 EINVAL。
16. Non-Blocking I/O约 200 词非阻塞 IOO_NONBLOCK、aio 和 io_uring；普通文件上未必生效。
17. Memory-Mapped Files约 200 词内存映射文件mmap 省的是系统调用，省不掉等盘。
18. Metadata约 200 词元数据逻辑元数据和物理元数据；stat 密集的负载。
19. Logical vs. Physical I/O约 700 词逻辑 IO 与物理 IO应用的 IO 和盘的 IO 为什么对不上，五类原因。
20. Operations Are Not Equal约 200 词操作各不相同只看每秒操作数说明不了什么。
21. Special File Systems约 100 词特殊文件系统tmpfs、/proc、/sys 这些不落盘的文件系统。
22. Access Timestamps约 100 词访问时间戳读文件也会引起写；怎么关掉见调优。
23. Capacity约 100 词容量文件系统快满时为什么变慢。
24. Architecture约 100 词架构这一部分的引子。
25. File System I/O Stack约 100 词文件系统 IO 栈从系统调用到设备的几条路径。
26. VFS约 100 词VFS各文件系统共用的接口，也是统一的观测点。
27. File System Caches约 900 词文件系统的几种缓存buffer cache、page cache、dentry、inode 缓存；脏页何时写回。
28. File System Features约 500 词文件系统特性块与 extent、日志、写时复制、擦洗。
29. File System Types约 2000 词文件系统类型FFS 的历史，ext3、ext4、XFS、ZFS、btrfs 的性能特性。选文件系统时查。
30. Volumes and Pools约 400 词卷与存储池LVM 和存储池；RAID 重建会拖慢很久。
31. Methodology约 100 词方法方法总表和作者建议的起手顺序。
32. Disk Analysis约 100 词只看磁盘只盯着盘的老办法为什么不够了。
33. Latency Analysis约 600 词延迟分析在哪一层量、怎么呈现；请求里文件系统耗时的占比。
34. Workload Characterization约 600 词负载特征描述文件系统负载的几项属性和一张问题清单。
35. Performance Monitoring约 200 词性能监控长期盯操作速率和延迟两个指标。
36. Static Performance Tuning约 200 词静态性能调优一张检查配置的问题清单。
37. Cache Tuning约 100 词缓存调优几种缓存都可以查看、往往可以调。
38. Workload Separation约 100 词负载分离日志和数据放在不同的盘上。
39. Micro-Benchmarking约 400 词微基准测试工作集大小决定测的是缓存还是盘。
40. Observability Tools约 100 词观测工具工具总表：传统工具和 BPF 工具。
41. mount约 100 词mount挂载选项；relatime 怎么减少时间戳写入。
42. free约 100 词freebuff/cache 和 available 两列怎么读。
43. top约 100 词top头部也有缓存大小。
44. vmstat约 100 词vmstatbuff 和 cache 两列。
45. sar约 100 词sar-v 看目录项和 inode，-r 看缓存大小。
46. slabtop约 100 词slabtop哪些 slab 是文件系统的缓存。
47. strace约 200 词strace在系统调用层计时；开销大，数字会被拉长。
48. fatrace约 100 词fatrace基于 fanotify 的文件访问事件；忙时输出太多。
49. LatencyTOP约 100 词LatencyTOP作者说它久未更新、要少见的内核选项，用 BPF 工具代替。
50. opensnoop约 200 词opensnoop跟踪文件打开，找配置、日志和缺失的文件。
51. filetop约 200 词filetop按文件排的 top，找意外忙碌的文件。
52. cachestat约 200 词cachestatpage cache 命中率；命中率低时调什么。
53. ext4dist (xfs, zfs, btrfs, nfs)约 200 词ext4dist 等延迟分布工具按操作类型画延迟直方图，读出双峰。
54. ext4slower (xfs, zfs, btrfs, nfs)约 200 词ext4slower 等慢操作工具逐条列出超过阈值的操作，看出写后同步的模式。
55. bpftrace约 800 词bpftrace单行命令、跟踪 read 的坑、VFS 延迟按类型拆分。要自己写工具时查。
56. Other Tools约 200 词其他工具别处讲过的十几个 BPF 工具，df、inotify，ZFS 的工具。
57. Visualizations约 400 词可视化文件系统延迟为什么是双峰，热图怎么读。
58. Experimentation约 100 词实验测试时让 iostat 一直开着，确认盘上有没有动静。
59. Ad Hoc约 100 词临时测试用 dd 粗测顺序读写；写的数字是进内存的速度。
60. Micro-Benchmark Tools约 500 词微基准测试工具Bonnie、fio、FileBench；作者推荐 fio。
61. Cache Flushing约 100 词清空缓存drop_caches 的三个值，测试前让缓存回到冷状态。
62. Tuning约 100 词调优最大的收益来自去掉不必要的工作。
63. Application Calls约 200 词应用的调用fsync 成批提交；posix_fadvise 和 madvise 给缓存提示。
64. ext4约 300 词ext4挂载选项、tune2fs、/sys/fs/ext4 和 e2fsck；noatime。
65. ZFS约 200 词ZFSZFS 的属性调优；不用 ZFS 的读者可以跳过。
66. Exercises约 300 词习题习题；动手部分本页已经给了替代。

词与短语

只收先读和用到再查两档的节。斜体那一行是原句里连续的几个词，在电子书里搜它就能找到那一句。

§0 开篇

§8.2.2 File System Cache

§8.3.1 File System Latency

§8.3.4 Prefetch

§8.3.6 Write-Back Caching

§8.3.9 Non-Blocking I/O

§8.3.10 Memory-Mapped Files

§8.3.12 Logical vs. Physical I/O

§8.3.13 Operations Are Not Equal

§8.4.3 File System Caches

§8.4.5 File System Types

§8.4.6 Volumes and Pools

§8.5.1 Disk Analysis

§8.5.2 Latency Analysis

§8.5.7 Workload Separation

§8.5.8 Micro-Benchmarking

§8.6.7 strace

§8.6.8 fatrace

§8.6.12 cachestat

§8.6.18 Visualizations

§8.7 Experimentation

§8.8 Tuning

诊断题：换成你来查

场景和输出都是本站编的。先自己判断，再点选项看解释。

write(5, ..., 96) = 96 <0.011820>
write(5, ..., 112) = 112 <0.009347>
write(5, ..., 88) = 88 <0.014105>

        total   used   free  shared  buff/cache  available
Mem:    15890   3490    410      25       12360      12400

usecs              count
0 -> 1              8120
2 -> 3              1530
4 -> 7               210
（中间几桶都是 0）
2048 -> 4095         400
4096 -> 8191         900
8192 -> 16383        250

time       w/s   w_await   %util
10:00:01    12      0.9      1.1
10:00:31   840     82.4     96.0
10:00:32    15      1.2      1.5

$ dd if=/dev/zero of=test bs=1M count=200
209715200 bytes (210 MB, 200 MiB) copied, 1.1 s, 191 MB/s

值得停下来的句子

For this reason, representing the distribution as a single value—such as a mean, mode, or median—is misleading.— §8.6.18。本站译：因此，用一个数——平均值、众数或中位数——来代表这个分布，会误导人。

这句话前面是理由：文件系统延迟本来就是两个峰，一个是缓存命中，一个是去存储设备。监控面板上最常见的恰恰是一个平均值。读者自己的服务大概率也是这样：缓存命中率九成以上，平均值被几微秒的命中拉得很好看，用户抱怨的却是那几次几十毫秒的读。看到「平均延迟正常」时，先问一句分布是什么样的，上面的模拟器把这件事演了一遍。

From the disk device-level statistics, this looks alarming; however, no application is waiting on these to complete.— §8.3.1。本站译：从磁盘设备层的统计看，这很吓人；可是并没有哪个应用在等它们完成。

「这」指后台刷写已写数据时突发的高延迟磁盘 IO。它说的是这一章的立足点：衡量好坏的是应用等了多久，不是盘有多忙。反过来也成立：盘很闲，应用也可能在等文件系统（等锁、等同一个文件上的 fsync）。所以排查从应用那一层的延迟开始，确认确实在等，再往下走到盘。

带走的几条

一句话：从应用这一层量文件系统延迟、看整个分布，分清命中、未命中和同步写，确认应用真在等了，再去看盘。