4

我正在编写一些代码来访问倒排索引。我有两个可互换的类,它们对索引执行读取。一个从磁盘读取索引,缓冲其中的一部分。另一个将索引完全加载到内存中,作为 byte[][](索引大小约为 7Gb)并从这个多维数组中读取。人们期望在将整个数据保存在内存中的同时具有更好的性能。但我的测量表明,使用磁盘上的索引与在内存中使用索引一样快。(在内存中加载索引所花费的时间不计入性能)

为什么会这样?有任何想法吗?

更多信息:我已经运行了启用 HPROF 的代码。无论是“在磁盘上”还是“在内存中”工作,最常用的代码并不是与读取直接相关的代码。此外,就我的(有限)理解而言,gc 分析器没有显示任何与 gc 相关的问题。

更新#1:我已经检测了我的代码来监控 I/O 时间。似乎大多数内存寻道需要 0-2000ns,而大多数磁盘寻道需要 1000-3000ns。第二个指标对我来说似乎有点太低了。是由于Linux的磁盘缓存吗?有没有办法排除磁盘缓存以进行基准测试?

更新#2:我已经绘制了对索引的每个请求的响应时间。内存线和磁盘线几乎完全匹配。我已经使用 O_DIRECT 标志进行了一些其他测试来打开文件(感谢 JNA!),在这种情况下,代码的磁盘版本(显然)比内存慢。所以,我的结论是“问题”是因为激进的 Linux 磁盘缓存,这非常了不起。

更新#3http ://www.nicecode.eu/java-streams-for-direct-io/

4

2 回答 2

5

三种可能性在我脑海中浮现:

  • 操作系统已经通过其文件系统缓存将所有索引文件保存在内存中。(请注意,我仍然希望有开销。)
  • 索引不是您正在测试的代码的瓶颈。
  • 您的基准测试方法不太正确。(很难做好基准测试。)

对我来说,中间选项似乎最有可能。

于 2013-03-19T18:02:16.677 回答
2

不,磁盘永远不会像 RAM 一样快(RAM 实际上比磁盘快 100,000 倍)。操作系统很可能正在为您将文件映射到内存中。

于 2013-03-19T18:02:12.420 回答