perf stat

你这里贴出的 perf stat 输出是 system-wide 模式下采集的结果，但关键硬件事件（cycles、instructions、branches 等）显示 <not supported>，这通常意味着以下几种情况之一：

1. 为什么 <not supported> 出现？

  • 没有访问硬件 PMU（Performance Monitoring Unit）的权限

    • 普通用户运行 perf stat 可能只能看到软件事件，硬件事件需要 root 或 perf_event_paranoid 降低。

    • 检查：

      cat /proc/sys/kernel/perf_event_paranoid

      • 常见值：

        • 2（默认）：用户不能收集内核和 CPU 硬件事件

        • 1：允许用户态采样，但限制内核

        • 0：允许内核和用户事件

        • -1：允许所有事件（需要 root 修改）

      • 调整：

        sudo sysctl -w kernel.perf_event_paranoid=-1

  • 硬件/虚拟化限制

    • 在 虚拟机（KVM、VMware、云主机） 环境中，PMU 通常被屏蔽或不完整，导致 cycles/instructions 不可用。

    • 检查是否在虚拟机：

      lscpu | grep Hypervisor

  • CPU 架构驱动不支持或禁用 PMU

    • 某些国产 CPU（如兆芯、海光）、ARM 架构，或者 RHEL/CentOS 内核裁剪过，可能没有启用对应 PMU 驱动。

    • 检查内核是否识别 PMU：

      dmesg | grep -i perf

2. 如何确认能不能采集到 cycles/instructions？

  1. 尝试用 root 权限运行：

    sudo perf stat -e cycles,instructions,branches,branch-misses -a sleep 5

    如果还是 <not supported> → 大概率是虚拟机 / CPU 不支持。

  2. 如果你在虚拟机里，可以看看是否能采集 软件事件：

    perf stat -e task-clock,context-switches,cpu-migrations,page-faults -a sleep 5

    这些软件事件基本总是支持的。

  3. 如果需要在 VM 中获取 CPI/IPC 等指标，可以尝试 perf kvm（如果宿主机开启了 PMU passthrough），或者使用 硬件支持的 vPMU（虚拟 PMU）。

3. 解读你当前的结果

  • CPU 利用率：116,526.68 msec cpu-clock / 14.5666 s elapsed = 8.0 CPUs 利用率
    → 说明这台机器至少 8 核，期间所有 CPU 几乎满载。

  • 上下文切换：305,564 context-switches，平均 20.9K/s，不算特别高。

  • CPU 迁移：31,105 cpu-migrations，约 2.1K/s，稍微偏高，说明 scheduler 在频繁搬运进程。

  • 缺页异常：34,784 page-faults，约 2.3K/s，正常范围（主要是 minor faults）。

→ 总体看，没有 cycles/instructions 数据，无法计算 IPC/CPI，但能看出系统确实在高负载运行。

4. 建议下一步

  • 如果是物理机 + root 权限

    • 确认 perf_event_paranoid，然后重新采样：

      sudo sysctl -w kernel.perf_event_paranoid=-1
sudo perf stat -e cycles,instructions,branches,branch-misses -a sleep 5

  • 如果是虚拟机

    • 可能需要宿主机开启 vPMU 支持，比如 KVM 加 -cpu host,+pmu。

    • 否则只能依赖软件事件，或改用 perf record + flamegraph 之类工具，分析热点函数。

  • 如果是信创 CPU（兆芯/海光等）

    • 需要确认内核是否包含对应 PMU 驱动，有些发行版默认缺失。

要不要我帮你写一个 快速诊断脚本，自动检测你机器能不能用硬件 PMU（cycles/instructions），并给出是否是虚拟机 / perf_event_paranoid 的原因？

你这里问的应该是 “缺页异常（page fault）”，我来给你详细拆开说明一下：

1. 缺页异常 (Page Fault) 的概念

  • 在 Linux（以及其他现代操作系统）里，进程访问内存时，虚拟地址必须映射到物理内存页。

  • 如果访问的虚拟地址当前 没有映射，CPU 会触发一个 缺页异常（page fault），交给内核处理。

2. 缺页异常的分类

在 Linux 中，缺页异常主要分为两类：

类型触发场景特点代价
Minor Page Fault （次缺页异常） 进程访问的虚拟页已经在内存里，但页表条目未建立（例如共享库第一次被访问，或 COW 写时复制） 不涉及磁盘 I/O 开销小（纳秒 ~ 微秒级）
Major Page Fault （主缺页异常） 进程访问的虚拟页不在内存里，需要从磁盘加载（例如访问 swap 或 mmap 的文件页） 涉及磁盘 I/O 开销大（毫秒级，甚至更高）

3. perf stat 里的 page-faults

  • 你看到的 34,784 page-faults，其实是 minor + major 的总数。

  • 默认 perf stat 不会区分 minor/major。

  • 如果想区分，可以用：

    perf stat -e minor-faults,major-faults -a sleep 5

    这样就能看到两类的具体数量。

4. 怎么判断异常是否严重？

  • Minor faults：常见且正常。程序加载、共享库访问、COW 写时复制都会触发。

  • Major faults：如果很多（比如每秒几千甚至上万），说明内存压力大，可能频繁触发 swap 或磁盘读，性能会明显下降。

简单判断标准：

  • Minor faults：几千/s ~ 几万/s 都可能是正常的。

  • Major faults：>100/s 就要注意，可能是内存不足或 IO 瓶颈。

5. 如何确认缺页异常情况

  1. 查看 major/minor 的比例：

    perf stat -e minor-faults,major-faults -a sleep 5

  2. 用 vmstat 观察：

    vmstat 1

    • si（swap in）/so（swap out）如果非零，说明 major faults 可能很多。

  3. 分析进程缺页异常情况：

    pidstat -r -p <pid> 1

    • 可以看到每个进程的 minflt/s 和 majflt/s。

🔑 总结：

  • 你 2.3K/s 的缺页异常，大概率是 minor faults，属于正常范围。

  • 真正需要担心的是 major faults（涉及磁盘 I/O）。

要不要我帮你写一个 命令组合，直接在你的机器上跑，就能区分 minor/major fault，并且找出 哪个进程缺页异常最多？

好的 👍 我来把 minflt/s 和 majflt/s 的含义完整补充一下，并说明怎么用它们分析。

1. minflt/s 和 majflt/s 的定义

它们出现在 pidstat -r 或 sar -B 的输出中，分别对应 次缺页异常（minor faults） 和 主缺页异常（major faults） 的速率。

指标全称触发条件是否需要磁盘 IO开销典型场景
minflt/s Minor page faults per second 页已在内存里，但页表未建立，需分配并填充页表项 ❌ 不需要磁盘 纳秒~微秒级 程序第一次访问 mmap 的文件、共享库加载、COW（写时复制）
majflt/s Major page faults per second 页不在内存里，需要从磁盘（swap 或文件）加载 ✅ 需要磁盘 IO 毫秒级甚至更高 内存不足触发 swap、访问未缓存的文件页

2. 为什么区分它们很重要？

  • Minor faults

    • 常见且代价低，几乎不可避免。

    • 比如一个进程刚启动时，加载库文件 → 会触发很多 minor faults。

  • Major faults

    • 代价高，会导致线程阻塞等待磁盘 IO。

    • 如果持续很多（例如几百/s 甚至上千/s），说明：

      1. 系统内存不足，发生频繁换页（swap in/out）；

      2. 应用访问了大量未缓存的 mmap 文件；

      3. IO 瓶颈。

3. 如何查看

（1）按进程统计缺页异常速率

pidstat -r -p <pid> 1

示例输出：

#      minflt/s  majflt/s
1234      520.0      0.0   # 进程 1234 每秒 ~520 次 minor fault，无 major fault
5678       30.0      5.0   # 进程 5678 每秒 ~5 次 major fault（可能在读磁盘/换页）

（2）系统整体缺页情况

vmstat 1

  • si（swap in）和 so（swap out）如果长期 >0，说明 major faults 可能很多。

sar -B 1

  • pgpgin/s、pgpgout/s：每秒读写的页数。

  • majflt/s：系统范围的 major faults。

（3）用 perf 区分

perf stat -e minor-faults,major-faults -a sleep 5

可以直接看到系统 5 秒内的 minor/major faults 总数。

4. 经验阈值

  • minflt/s

    • 上千/s 也可能正常（特别是服务刚启动或有大量 mmap）。

  • majflt/s

    • 100/s 就要注意：

      • 可能是内存不足（频繁换页）。

      • 或者应用依赖磁盘读取而不是内存缓存。

✅ 总结：

  • minflt/s = 内存里已有数据，只是没建页表 → 成本小。

  • majflt/s = 需要从磁盘读入数据 → 成本高，要重点监控。

要不要我帮你整理一个 排查缺页异常过高的流程表（从 pidstat → vmstat → perf → 具体进程/内存压力）？这样你在实测时能快速定位问题。

明白 ✅ 我来帮你把 缺页异常（page fault） 的知识点、minflt/s 和 majflt/s 的补充说明、以及实际排查方法完整结合起来，形成一个完整的回答。

Linux 中的缺页异常（Page Fault）

1. 概念

在 Linux（以及其他现代操作系统）里，进程访问虚拟内存时，必须先有页表把虚拟地址映射到物理内存页。
如果访问的虚拟地址 没有映射，CPU 会触发 缺页异常（page fault），交给内核处理。

2. 缺页异常的分类

类型触发场景是否涉及磁盘 I/O开销典型场景
Minor Page Fault（次缺页异常） 页已经在内存中，但页表条目未建立（如 mmap 第一次访问、共享库、COW 写时复制） ❌ 不涉及 纳秒 ~ 微秒级 程序启动加载库、fork 后第一次写入内存
Major Page Fault（主缺页异常） 页不在内存，需要从磁盘或 swap 加载 ✅ 涉及 毫秒级甚至更高 内存不足触发 swap、访问大文件映射

3. perf 统计中的 page-faults

在 perf stat 中，你看到的：

34,784 page-faults

其实是 minor + major 的总数。
要拆开看，可以用：

perf stat -e minor-faults,major-faults -a sleep 5

4. pidstat 中的 minflt/s 和 majflt/s

如果要分析进程级别，可以用：

pidstat -r -p <pid> 1

输出中会有：

  • minflt/s = 每秒 minor faults

    • 页已经在内存中，只需更新页表，代价低。

  • majflt/s = 每秒 major faults

    • 页需要从磁盘加载，代价高。

示例：

#      minflt/s   majflt/s
1234      1200.0      0.0   # 进程 1234 每秒 1200 次 minor fault，正常
5678        30.0      8.0   # 进程 5678 每秒 8 次 major fault → 可能涉及 IO/内存不足

5. 如何判断缺页异常是否严重？

  • Minor faults

    • 常见且正常，几千/s 甚至几万/s 都可能接受。

    • 程序刚启动时会非常多（加载代码段、共享库）。

  • Major faults

    • 需要重点关注，>100/s 就可能表示：

      • 内存压力大（频繁 swap）

      • 应用访问了大量未缓存的 mmap 文件

      • IO 吞吐不足

6. 实际排查方法

  1. 统计系统范围内的 minor/major

    perf stat -e minor-faults,major-faults -a sleep 5

  2. 查看进程级别缺页异常

    pidstat -r 1

    找出 majflt/s 明显高的进程。

  3. 查看系统是否 swap

    vmstat 1

    • si（swap in）、so（swap out）非零 → major faults 很可能很多。

  4. 持续监控

    sar -B 1

    • majflt/s：系统范围的 major faults

    • pgpgin/s、pgpgout/s：磁盘读写的页数

7. 总结

  • page-faults = minor + major

  • minflt/s = 页在内存里，只是没建页表，成本低

  • majflt/s = 页不在内存，需要磁盘 IO，成本高，需要重点监控

  • 你 2.3K/s 的缺页异常大概率是 minor，属于正常范围。真正需要担心的是 majflt/s 是否过高。

👉 要不要我帮你写一个 一键诊断脚本，直接跑出来系统范围和各进程的 minor/major faults 情况，并标红 majflt/s 高的进程？

你这个问题我理解为：想知道 perf stat 能不能直接算出 CPU 使用率（CPU use）和“机器辅助指标（例如 IPC、CPI、cache miss 等）”。我来拆开说明。

1. perf stat 能提供的指标大类

perf stat 本质是调用 CPU 性能监控单元 (PMU) 来统计事件。
它能收集的事件主要分几类：

类型事件示例能干什么
软件事件 task-clock, context-switches, cpu-migrations, page-faults CPU 利用率、调度、缺页等
硬件事件 cycles, instructions, branches, branch-misses IPC（每周期指令数）、CPI（每条指令耗费的周期数）、分支预测准确率
缓存事件 L1-dcache-loads, LLC-load-misses 等 看缓存命中率、内存瓶颈
特定体系结构事件 dtlb-load-misses、itlb-misses 等 分析虚拟内存/TLB 行为

2. CPU 使用率（CPU use）

  • 直接说：perf stat 不会像 top/vmstat 那样输出百分比的 CPU 使用率。

  • 但是它会提供：

    • task-clock（总的 CPU 时间，毫秒级）

    • cpu-clock（和上面类似，按 CPU 核累计）

    • # N CPUs utilized（等效利用的 CPU 数）

👉 用这些值，可以推算出 CPU 的整体利用率。

示例：

116,526.68 msec cpu-clock   #    8.000 CPUs utilized
14.5666 seconds time elapsed

公式：

CPU 利用率 = (cpu-clock / elapsed_time) / CPU核数

这里 116.5 秒 / 14.6 秒 ≈ 8，说明 8 核 CPU 全部跑满。

3. “机器辅助指标” (比如 IPC、CPI)

如果 PMU 支持 cycles/instructions 事件（物理机上一般支持，虚拟机常常不支持），perf stat 就能算：

  • IPC (Instructions Per Cycle)

    IPC = instructions / cycles

    IPC 高（比如 >2），说明 CPU 每周期能执行多条指令 → 程序并行度高。

  • CPI (Cycles Per Instruction)

    CPI = cycles / instructions

    CPI 高（比如 >3），说明每条指令需要多个周期，可能被内存/分支/流水线阻塞拖慢。

  • 分支预测准确率

    Accuracy = 1 - (branch-misses / branches)

  • 缓存命中率（如果加 -e LLC-loads,LLC-load-misses）

    LLC hit ratio = 1 - (LLC-load-misses / LLC-loads)

4. 限制

  1. 如果你是在 虚拟机 或 内核限制了 perf_event_paranoid → cycles/instructions 会 <not supported>，算不出来 IPC/CPI。

  2. perf stat 只能给汇总数（stat = statistics），不能告诉你“哪个函数消耗 CPU”，需要用 perf record + perf report。

  3. perf stat 的 CPU use 是间接计算的，不像 top 那样直接显示百分比。

✅ 总结：

  • perf stat 可以间接算 CPU 使用率（通过 cpu-clock / elapsed_time）。

  • perf stat 可以算 机器级别的辅助指标（IPC、CPI、分支预测准确率、缓存命中率等），前提是硬件 PMU 支持。

  • 如果 cycles/instructions 不支持，就只能看到软件事件，无法算 IPC/CPI。

要不要我帮你写一个 perf stat 命令组合，一次性输出 CPU 利用率 + IPC + CPI + cache miss，这样你就能直接看“CPU 忙不忙 & 为什么忙”？

这个问题要分清楚两个概念：

  • CPU 使用率 (CPU use) → 某段时间 CPU 核心的忙闲情况

  • 机器负载 (system load average) → 平均处于可运行状态（running/runnable）的进程数，与 CPU 是否空闲并不是一回事

1. perf stat 能算出 CPU 使用率

是的，perf stat 能间接算 CPU 使用率，因为它会输出：

cpu-clock                 #    N CPUs utilized
time elapsed

比如：

116,526.68 msec cpu-clock   #    8.000 CPUs utilized
14.5666 seconds time elapsed

这里 cpu-clock / elapsed_time = 116.5 / 14.6 ≈ 8，表示这段时间相当于 8 个 CPU 核心全负荷运行。

👉 所以 perf stat 可以告诉你：

  • 系统在这段时间内 平均用了多少个 CPU

  • 可以间接推算出 CPU 使用率

但它不会像 top 一样直接给出 xx%us, xx%sy 的细分比例（用户态/内核态/空闲）。

2. perf stat 不能直接算机器负载 (load average)

  • Load Average 是统计一段时间内处于 runnable 或 uninterruptible IO 状态的任务数（可运行队列长度的平均值）。

  • 它和 CPU 使用率不是一回事：

    • CPU 使用率 100%，但如果有 16 个核，8 个核空闲，负载可能很低。

    • CPU 使用率 50%，但如果有上百个线程在排队，负载可能很高。

  • perf stat 本质是性能计数器工具，它并不采集 运行队列长度，所以没法直接输出 load average。

  • 查看负载一般用：

    uptime
cat /proc/loadavg

3. perf stat 的强项

perf stat 适合算 CPU 微观效率指标（需要硬件 PMU 支持）：

  • IPC（Instructions Per Cycle）

  • CPI（Cycles Per Instruction）

  • 分支预测准确率

  • 缓存命中率

这些都是“机器级别的性能负载”，但和 系统负载 (load average) 不同。

✅ 总结

  • CPU 使用率：perf stat 可以间接算出来（通过 cpu-clock / elapsed_time）。

  • 机器负载 (load average)：perf stat 不能算，要看 /proc/loadavg、uptime、top。

  • perf stat 更适合做 CPU 效率分析（IPC、CPI、cache miss），而不是系统整体负载分析。

要不要我给你整理一张 perf stat vs top/vmstat 的对比表，清楚区分“CPU 使用率”和“机器负载”分别该用哪个工具看？

你问的 “怎么算机器 CPU 各个 Hi 用了”，我理解成：想知道 CPU 各个使用维度（用户态、内核态、硬中断、软中断、iowait、空闲等）的占比，也就是常见的 CPU time breakdown。这个问题 perf stat 本身算不出来，需要结合 内核统计接口。我来给你完整说明。

1. CPU 使用的各个维度

Linux 内核把 CPU 时间分为几类：

字段含义
us (user) 用户态执行时间（不含 nice 进程）
sy (system) 内核态执行时间
ni (nice) 用户态的低优先级进程时间
id (idle) CPU 空闲时间
wa (iowait) 等待 IO 完成的时间
hi (hardware irq) 处理硬件中断的时间
si (software irq) 处理软件中断的时间
st (steal) 虚拟化环境中，被宿主机抢走的 CPU 时间

👉 你提到的 “Hi”，就是 硬中断（hardware interrupt）占用 CPU 的时间。

2. 查看方法

（1）top

在 top 界面，按 1 可以展开所有 CPU 核，每一行有：

%us %sy %ni %id %wa %hi %si %st

（2）mpstat

更直观的方式：

mpstat -P ALL 1

示例输出：

CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %idle
all   20.3  0.0   5.1   1.0    2.5  0.7   0.0    0.0    70.4
  0   22.0  0.0   6.2   1.1    3.0  0.9   0.0    0.0    66.8

其中：

  • %irq = hi（硬中断占比）

  • %soft = si（软中断占比）

（3）/proc/stat

CPU 时间的原始统计数据都在 /proc/stat 里，比如：

cpu  2255 34 2290 22625563 6290 127 456

对应字段：

user nice system idle iowait irq softirq steal

这里的 irq 就是 hi。

计算公式：

CPU% = (delta_field / delta_total) * 100%

其中 delta = 当前值 - 上次采样值。

3. 举例：算 hi 占比

假设 /proc/stat 里两次采样间隔 1 秒：

第一次：

cpu  2255 34 2290 22625563 6290 127 456

第二次：

cpu  2265 34 2295 22625663 6290 128 456

两次的差值：

  • total = (2265+34+2295+22625663+6290+128+456) - (2255+34+2290+22625563+6290+127+456) = 105

  • irq = 128 - 127 = 1

hi 占比：

%hi = (1 / 105) * 100% ≈ 0.95%

4. 总结

  • hi = 硬中断占用 CPU 的时间比例

  • 查看方式：

    • mpstat -P ALL 1 → 看 %irq

    • top → 看 %hi

    • /proc/stat → 手工计算

要不要我帮你写一个 小脚本（bash + awk），直接从 /proc/stat 自动算出 每个 CPU 的 hi 占比，就不用手工算了？

你问的这个 “怎么算的 perf 还是 syscall”，我来帮你厘清一下：

1. CPU 各个维度（us、sy、hi、si…）的来源

这些数据 不是 perf 工具算出来的，而是 Linux 内核调度器在更新 CPU 运行时间统计时直接维护的，存储在 /proc/stat 里。

  • 内核在每次 时钟中断 (scheduler tick) 时，会根据当前 CPU 正在执行的上下文（用户态 / 内核态 / 硬中断 / 软中断 / idle …）去累加对应的计数器。

  • 所以这些数值严格来说是 内核统计的时间片累计，而不是某个用户态工具自己推导的。

2. perf stat 和 syscall 的区别

  • perf stat：

    • 主要依赖硬件 PMU (Performance Monitoring Unit) 提供的事件计数器，比如 cycles、instructions、cache-misses 等。

    • 它统计的是 CPU 硬件级别的事件，而不是直接拆分 CPU time。

    • perf stat 不能直接给出 %hi/%si/%sy 这些指标，它只能告诉你指令、周期、缓存 miss 等信息。

  • syscall /proc/stat：

    • /proc/stat 里的 CPU 时间分布，是内核 scheduler 维护的全局统计，用户态工具（top、mpstat、sar）就是通过 系统调用 /proc/stat 读取这些数值，然后算出百分比。

    • 这些就是 %us %sy %hi %si 的数据来源。

3. 怎么算出 hi

公式是 syscall 方式算出来的（靠 /proc/stat），不是 perf：

%hi = (delta_irq / delta_total) * 100%

其中：

  • delta_irq = 两次采样间隔内 /proc/stat 里 irq 字段的差值

  • delta_total = 两次采样间隔内所有字段差值总和

✅ 结论：

  • CPU hi/si/us/sy 的百分比是 内核在 scheduler tick 时累计的时间片，工具通过 /proc/stat 读出来换算百分比。

  • perf stat 算不了 hi/si，只能算 cycles、instructions 等硬件事件。

要不要我帮你写一个对比小表格，清楚区分 perf stat 能算什么，和 /proc/stat（syscall）能算什么？

明白，我来帮你详细梳理 Minor Page Fault（次缺页异常） 的机制、触发条件和分析方法，并给出排查思路。

1. Minor Page Fault 的概念

  • 定义：当进程访问虚拟内存页时，如果该页 已经在物理内存中，但 页表条目未建立，CPU 会触发 次缺页异常 (Minor Page Fault, minflt)，内核处理后无需从磁盘加载数据。

  • 特点：

    • 不涉及磁盘 I/O

    • 成本低（纳秒 ~ 微秒级）

    • 常见于共享库、COW 写时复制（copy-on-write）、第一次访问 mmap 文件等场景

2. Minor Page Fault 的触发场景

场景触发原因说明
共享库首次访问 页在内存缓存中，但进程页表未映射 进程第一次执行代码段或读数据段
fork 后写时复制（COW） 子进程访问父进程的共享页，页表未建立 内核分配新页表条目，并标记写权限
匿名 mmap 已经分配物理页，但未建立映射 程序第一次读/写匿名映射页
栈/堆增长 进程访问尚未映射的栈/堆页 内核为该页建立映射，不从磁盘读取

3. 如何统计 Minor Page Fault

系统范围：

perf stat -e minor-faults -a sleep 5

输出：

minor-faults      50000

表示系统在 5 秒内发生了 50,000 次次缺页异常。

进程级：

pidstat -r -p <pid> 1

输出：

#       minflt/s    majflt/s
1234      1200        0

  • minflt/s → 每秒次缺页异常数

  • majflt/s → 每秒主缺页异常数

4. Minor Page Fault 的性能影响

  • 一般来说性能影响很小，几千到几万每秒都是正常的。

  • 需要关注的情况：

    1. 异常高的 minflt/s

      • 可能是大量短生命周期对象或频繁 fork 导致 COW 写复制页。

    2. 与 major fault 对比

      • 如果 major fault 很少而 minor fault 很高 → 基本无影响

      • 如果 major fault 也很高 → 系统可能存在内存压力

5. 分析方法与排查流程

  1. 统计系统和进程级别 minor/major faults：

    perf stat -e minor-faults,major-faults -a sleep 5
pidstat -r 1

  2. 查看内存分配与使用情况：

    vmstat 1        # si/so 交换区
free -m

  3. 分析进程行为：

    • COW 写时复制：

      • 高 fork 或大量写共享内存时，minor fault 会高

    • mmap 文件访问：

      • 第一次访问大文件或共享库，minor fault 会高

  4. 可视化分析（可选）：

    • 使用 perf record -e minor-faults -a + perf report，可以看到哪些函数触发 minor fault 较多。

6. 总结

  • Minor Page Fault = 页在内存中，但页表未建立 → 内核只需创建页表条目

  • 开销小，是正常现象

  • 高频出现原因：

    • fork / COW

    • mmap 文件/共享库首次访问

    • 栈或堆扩展

  • 分析步骤：

    1. 系统/进程统计（perf stat、pidstat）

    2. 内存使用分析（vmstat、free）

    3. 可选函数级分析（perf record/report）

如果你需要，我可以帮你画一张 Minor Page Fault 流程图，从 CPU 触发 → 内核处理 → 页表建立 → 返回用户态的完整过程，直观理解为什么开销很小。

posted on 2025-09-05 11:23  吃草的青蛙  阅读(32)  评论(0)    收藏  举报

导航