/proc/[pid]/stat第10列（minflt）和第12列（majflt）分别记录进程累计软缺页和硬缺页次数，需配合clock_gettime(CLOCK_MONOTONIC)计算单位时间频率，区分二者可精准定位I/O级性能瓶颈。
如何用 /proc/[pid]/stat 快速提取缺页中断计数
/proc/[pid]/stat 第 12 列（minflt）是次要缺页次数，第 13 列（majflt）是主要缺页次数——后者意味着必须从磁盘（如 swap 或 mmap 文件）加载页，延迟通常在毫秒级，是性能瓶颈的强信号。
实操时别直接 cat /proc/1234/stat 手动数字段，容易错位。用 awk 定位更稳：
awk '{print $12, $13}' /proc/1234/stat
注意：minflt 增长快不等于有问题（例如刚启动的进程大量分配零页），但 majflt 持续非零就值得警惕。每秒增长 > 10 次，基本可判定 I/O 级别卡顿源头。
用 perf stat -e page-faults,major-faults 抓实时采样
perf 是内核原生工具，比轮询 /proc 更准、开销更低，且能绑定到具体线程：
- 监控整个进程（含子线程）：
perf stat -p 1234 -e page-faults,major-faults -I 1000（每秒输出一次统计） - 只盯主线程：
perf stat -t $(ps -T -p 1234 | awk 'NR==2 {print $2}') -e major-faults -I 500 - 避免干扰业务：加
-a会捕获全系统事件，别乱用；-I间隔建议 ≥ 500ms，太密反而抬高 perf 自身开销
关键看 major-faults 的“per second”值。若该值和 perf record -e syscalls:sys_enter_read 捕获的磁盘读 syscall 频率接近，基本锁定是 mmap 文件或 swap 引发的抖动。
立即学习“C++免费学习笔记（深入）”；
为什么 mmap(MAP_POPULATE) 不能解决所有缺页问题
MAP_POPULATE 确实能预读物理页，但仅对匿名映射（MAP_ANONYMOUS）或普通文件映射有效；对设备文件（如 /dev/shm）、tmpfs 或已启用 THP（透明大页）的区域，行为不可控，甚至可能被内核忽略。
- 验证是否生效：预热后立刻查
/proc/[pid]/stat的majflt，应为 0；再触发实际访问，若majflt仍跳涨，说明预热失败 - 副作用明显：预热期间会阻塞调用线程，且可能触发内存回收（
kswapd），反而拖慢启动 - 真正可控的替代方案：对关键数据结构，用
mlock()锁住常驻内存（需RLIMIT_MEMLOCK权限），比依赖MAP_POPULATE更可靠
C++ 代码中嵌入轻量级缺页监控（不用外部工具）
想在程序内部感知缺页影响？别 hook signal(SIGSEGV)——现代 Linux 缺页由内核静默处理，不会发信号。正确做法是定期读取 /proc/self/stat 并差分：
struct rusage usage; getrusage(RUSAGE_SELF, &usage); // usage.ru_majflt 就是当前进程累计 major fault 数
但注意：getrusage 的精度取决于内核版本，老内核（ru_majflt 实时值；新内核虽支持，但调用本身有微秒级开销，高频采集（
更稳妥的做法：每 100–500ms 采一次 ru_majflt，结合 clock_gettime(CLOCK_MONOTONIC) 计算单位时间增长率。一旦连续 3 次超过阈值（比如 5 次/秒），就记录上下文并触发降级逻辑——比如暂停后台预加载，或切换到堆内缓冲。
缺页本身不可怕，可怕的是它暴露了内存布局与访问模式的深层矛盾：比如随机访问大数组却没预取、频繁 fork 后未重用子进程内存、或容器环境下 cgroup memory limit 设置过紧导致频繁 reclaim。这些点，比单纯看数字更难定位。
