AMC 不报告任何成功的读取答案

【问题标题】：AMC does not report any successful readsAMC 不报告任何成功的读取
【发布时间】：2016-12-16 14:40:18
【问题描述】：

我正在尝试使用内置 Java 基准测试工具对我们的 3 个节点的 Aerospike 集群进行基准测试。

当我检查 AMC（Aerospike 管理控制台）时，我发现没有成功读取。 Benchmark 报告一切正常，这就是问题所在。

2016-12-16 15:34:21.674 write(tps=14851 timeouts=0 errors=0) read(tps=15030 timeouts=0 errors=0) total(tps=29881 timeouts=0 errors=0)
2016-12-16 15:34:22.674 write(tps=21160 timeouts=0 errors=0) read(tps=21284 timeouts=0 errors=0) total(tps=42444 timeouts=0 errors=0)
2016-12-16 15:34:23.675 write(tps=22868 timeouts=0 errors=0) read(tps=22312 timeouts=0 errors=0) total(tps=45180 timeouts=0 errors=0)
2016-12-16 15:34:24.676 write(tps=22443 timeouts=0 errors=0) read(tps=22795 timeouts=0 errors=0) total(tps=45238 timeouts=0 errors=0)

您知道为什么 AMC 没有将这些读取请求显示为成功，因为基准报告读取没有错误或超时？

我的基准配置（修改example 3）如下。

./run_benchmarks -h aero1.db.test.env -p 3000 -n namespace -k 1000000000000000 -S 1 -o S:50 -w RU,50 -z 1 -async -asyncMaxCommands 300 -asyncSelectorThreads 8 -e 1 -T 500

【问题讨论】：

标签： java benchmarking aerospike

【解决方案1】：

那里有很多密钥（100 亿个密钥，或 10^15 个）...并且正在执行 RU 工作负载...

您的读取失败实际上是“未找到”。我不是统计学家，但我希望在很长一段时间内随机读取已经从如此大的样本中插入的密钥的机会非常低。您可以检查统计数据并验证所有这些读取确实“未找到”。这些在技术上与基准工具中的错误是分开报告的，也就是说，我给你的，充其量是误导，因为你不会注意到。

我也不确定您在 3 节点集群上使用什么类型的 RAM/存储来处理这么多的记录，无论它们多么小。

为了进行适当的基准测试，您应该首先使用仅插入工作负载 (-w I) 加载所有键，然后触发读取更新工作负载。

【讨论】：

集群只是内存。
仅内存会使存储所有这些内容变得更加昂贵，仅索引的要求约为 58 PetaBytes（每条记录 64 字节），因此索引每个节点的 RAM 接近 20PetaByte。顺便说一句，Aerospike 目前有一个限制（希望不会太长），每个命名空间的每个节点最多可以存储 2^32 个（约 40 亿个）键。
所以你说的是我放在基准中的巨大数字？它只是随机（高）数字，使其几乎永远运行。我认为基准测试有来自 aerospike 的数据但 aerospike 报告 0 次成功读取的原因没有任何共同之处。
啊，是的，如果不清楚，抱歉。 -k 选项是用于基准测试的记录数。 -w RU（读取更新）的工作负载将始终运行直到终止，因此您不必担心它会运行多长时间。您可能通常希望首先为您的用例（-k 选项）执行具有大量记录的仅插入工作负载 -w I（大写 i），然后在加载完成后，您可以运行读取更新基准相同的 -k 选项以确保在读取时会找到所有键。