6

我确信：

  • 我正在 Linux 上使用 Java/Eclipse，并尝试在磁盘上分别存储大量 16/32 字节的键/值对。密钥是完全随机的，由 SecureRandom 生成。
  • 速度保持在约 50000 次插入/秒，直到达到约 100 万个条目。
  • 一旦达到此限制，java 进程每 1-2 秒从 0% CPU 到 100%、从 150MB 内存到 400MB、从 10 次插入/秒到 100 次振荡。
  • 我尝试了 Berkeley DB 和 Kyoto Cabinet 以及 Btrees 和 Hashtables。结果相同。

什么可能有助于：

  • 写在SSD上。
  • 对于每个插入，平均有 1.5 次读取 - 不断交替读取和写入。

我怀疑在达到某个缓存/缓冲区限制之前，不错的 50000 速率会上升。那么大的减速可能是由于 SSD 没有处理混合的读/写，正如这个问题所建议的那样：SSD 的低延迟键值存储。

问题是：
这种极端减速可能来自哪里？不可能都是 SSD 的错。很多人都乐于使用 SSD 进行高速 DB 进程，我敢肯定他们经常混合读写。

谢谢。

编辑：我已经确保删除任何内存限制，并且 java 进程总是有空间分配更多内存。
编辑：仅删除读数和插入不会改变问题。

最后编辑：为了记录，对于哈希表，它似乎与初始数字桶有关。在京都机柜上，该数字无法更改，默认为约 100 万，因此最好在创建时获取正确的数字（要存储的最大记录数的 1 到 4 倍）。对于 BDB，它旨在逐步增加存储桶的数量，但由于它消耗资源，因此最好提前预定义数量。

4

1 回答 1

4

您的问题可能与您正在使用的数据库的强持久性保证有关。

基本上，对于任何符合 ACID 的数据库，每次数据库提交至少需要一次 fsync() 调用。这样做是为了保证持久性（否则，更新可能会在系统故障的情况下丢失），同时也是为了保证磁盘上数据库的内部一致性。在 fsync() 调用完成之前，数据库 API 不会从插入操作返回。

fsync()在许多操作系统和磁盘硬件上可能是一个非常重量级的操作，甚至在 SSD 上也是如此。（电池或电容器支持的企业 SSD 是一个例外——它们基本上可以将缓存刷新操作视为无操作，以避免您可能遇到的延迟。）

一个解决方案是在一次大交易中完成所有商店。我不了解 Berkeley DB，但对于 sqlite，性能可以通过这种方式大大提高。

要确定这是否是您的问题，您可以尝试使用 strace 观察您的数据库写入过程，并寻找频繁的 fsync() 调用（每秒多次调用将是一个非常强烈的提示）。

更新： 如果您绝对确定不需要持久性，可以尝试Optimizing Put Performance in Berkeley DB 中的答案；如果你这样做了，你应该研究一下 Berkeley DB 的 TDS（事务数据存储）特性。

于 2012-10-23T12:58:03.573 回答