对mmap和/ usr / bin / time,htop等的输出进行基准测试

时间:2014-07-18 12:41:06

标签: linux benchmarking memory-mapped-files page-fault

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

该计划的表现并不完美。鉴于设置,主要页面错误可能是罪魁祸首。

所以我想知道这有多糟糕,并编写了一个程序来估计主要页面错误的影响。基本上我会绘制几个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毫秒。这是"正常"小页面错误的数量级?
  4. 编辑:我刚试了一件事。我再次运行测试程序并用strace记录所有系统调用。我所看到的只是在探测期间的clock_gettime,gettimeofday,futex。根本没有读取(2),所以我更想知道&us文件系统输入',/ usr / bin / time提供的主要和次要故障编号是如何相互关联的。

0 个答案:

没有答案