1

我有一个程序，它大量使用内存映射文件到虚拟内存，特别是比物理内存大得多的文件。

该程序的性能并不十分出色。鉴于设置，主要的页面错误可能是罪魁祸首。

所以我想知道这有多糟糕，并编写了一个程序来估计一个主要页面错误的影响。基本上，我映射一个几 GB 大小的文件并读取一些随机字节，同时测量读取字节所需的时间。

我可以很好地看到总体运行时间以及累积或直方图分析访问时间的巨大差异，具体取决于文件是否可能不在缓存中（echo 3 > /proc/sys/vm/drop_caches），以及何时在测试程序的第二次运行中已经在缓存中。

此外，我查看了以下数字的输出，/usr/bin/time -v但这些数字令人困惑（为简洁起见，剪掉了一些行）：

User time (seconds): 0.66
System time (seconds): 3.66
Percent of CPU this job got: 3%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:17.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1593920
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 7672
Minor (reclaiming a frame) page faults: 93641
File system inputs: 5094600
File system outputs: 200
Page size (bytes): 4096
Exit status: 0

任何人都可以回答以下问题：

  1. 一个页面有 4k，我有 7672 个主要页面错误。这些是微不足道的 30MB。即使在（否则非常快的）smb 文件系统上，将它们分页也不应该超过 2 分钟。
  2. “文件系统输入”是什么意思？该程序不执行任何文件系统输入。它已经映射了这个 2.8 GB 的文件，但它没有 read()。这是读取次数还是以 kB 为单位？它是否与主要的页面错误有任何关系？
  3. 接近 100k 的次要页面错误与程序进行的 100k 探测（单字节读取）很好地对齐。在这台机器上我实际上不能drop_caches，我必须在不同的文件上运行程序来尝试推出数据。我可能没有工作。这可以解释我的页面错误大多是轻微的。但是为什么这需要这么长时间。100k 探测器对 2:17 分钟的粗略估计产生 1.37 毫秒。这是轻微页面错误的“正常”数量级吗？

编辑：我又尝试了一件事。我再次运行测试程序并用 strace 记录所有系统调用。我在探测期间看到的只是clock_gettime、gettimeofday、futex。根本没有 read(2)，所以我更想知道 /usr/bin/time 提供的“文件系统输入”、主要和次要故障编号是如何相互关联的。

4

0 回答 0