应读取/proc/[pid]/stat第10（minflt）和第12（majflt）字段获取累计值，而非第15、16字段；因第2字段为括号包裹的进程名，会导致字段偏移，须跳过前9个字段后提取；推荐用std::istringstream或getrusage(rusage_self, &ru)更可靠。
直接读 /proc/[pid]/stat 获取累计值
Linux内核把每个进程的软缺页（minor）和硬缺页（major）次数，实时记录在 /proc/[pid]/stat 文件里，不是靠日志或命令临时计算出来的。关键字段是第10个（min_flt）和第12个（maj_flt），注意不是第15、16——因为第2个字段是括号包裹的进程名（如 (bash)），它会吃掉一个空格，导致后续字段整体右移。
实操时必须跳过前9个字段，再取第10和第12项。用 std::istringstream 配合 >> 提取最稳妥，它自动跳过多余空白；别用 strtok 或简单 split(' ')，遇到 (java -jar app.jar) 这种带空格的 comm 字段就直接错位。
-
min_flt：软缺页累计次数，页已在内存（如共享库、已缓存文件），只需建立映射 -
maj_flt：硬缺页累计次数，页不在内存，必须从磁盘加载（触发I/O） - 字段值是
unsigned long，运行数月也不会溢出，但做差值时要用无符号减法，避免回绕误判负增长
用 getrusage(RUSAGE_SELF, &ru) 更轻量可靠
比解析文本文件更推荐的方式是调用 POSIX 接口 getrusage，它直接返回结构体字段，无需字符串处理，也不依赖 /proc 是否挂载或权限。
头文件是 <sys></sys>，填入 struct rusage ru 后检查返回值是否为 0；ru.ru_minflt 和 ru.ru_majflt 就是你要的两个计数，类型为 long。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 该调用只反映“调用时刻之前”的累计值，不能替代采样差值——想算每秒速率，仍需自己缓存上一次值
- 查子进程要用
RUSAGE_CHILDREN，但仅对已wait()过的子进程有效 - 在容器或严格限制
/proc访问的环境中，getrusage是唯一可行路径
为什么不能只看一次读数？
所有这些接口返回的都是自进程启动以来的累计值，不是“每秒次数”。常见错误是读一次就除以1秒，以为得到速率——这是无效操作，数值毫无意义。
要获得真实每秒缺页频率，必须至少两次采样，并用单调时钟（如 clock_gettime(CLOCK_MONOTONIC)）精确计算时间差 dt，再做除法：(current - previous) / dt_sec。
- 别用
sleep(1)或std::this_thread::sleep_for(1s)控制间隔——调度延迟会导致实际间隔远超1秒，速率失真严重 - 字段变化可能极快（比如刚
mmap大文件），也可能长时间为 0；单次读数无法区分“安静”和“卡死” - 若两次读数相同，且
dt极小（如因调度卡顿落在同一时钟滴答），结果为 0 是合理行为，不是 bug
别被 /proc/meminfo 或 vmstat 带偏
/proc/meminfo 里的 Pgpgin/Pgpgout 是页输入/输出总量，和缺页中断无关；vmstat 的 si/so 是交换区换入/换出页数，只覆盖硬缺页中涉及 swap 的部分，漏掉文件映射、匿名页分配等大量场景。
它们适合系统级粗略观察，但定位具体进程的缺页行为时，精度和归属都不可靠——vmstat 不告诉你哪个 PID 在触发，/proc/meminfo 更不区分 minor/major。
- 想确认某进程是否频繁缺页，必须绑定到它的 PID，走
/proc/[pid]/stat或getrusage - 如果看到
min_flt暴涨而maj_flt几乎不动，大概率是堆分配、JIT 编译或 mmap 匿名页；maj_flt显著上升才真正提示 I/O 压力 - 字段偏移、括号解析、单调时钟、无符号差值——这四个点任何一个出错，数据就废了，不是“差不多”，而是完全不可信
