我正在尝试使用内置 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
最佳答案
那里有很多 key (100 万十亿个 key ，或 10^15)...并执行 RU 工作负载...
您的读取失败实际上是“未找到”。我不是统计学家，但我希望在很长一段时间内随机读取已经从如此大的样本中插入的 key 的机会非常非常低。您可以检查统计数据并验证所有这些读取是否确实“未找到”。从技术上讲，这些是与基准工具中的错误分开报告的，也就是说，我告诉你，充其量只是误导，因为你不会注意到。
我也不确定您在 3 节点集群上有什么类型的 RAM/存储来处理这么多记录，尽管它们很小。
为了进行适当的基准测试，您应该首先使用仅插入工作负载 (-w I) 加载所有 key ，然后触发读取更新工作负载。
关于java - AMC 不报告任何成功读取，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41186760/