我正在尝试使用内置
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
最佳答案 那里有很多钥匙(100万个钥匙,或10 ^ 15)……并且做RU工作量…
事实上,您的阅读失败“未找到”.我不是统计学家,但我希望随机读取已从这么大样本中插入的密钥的机会很长时间都非常低.您可以检查统计数据并验证所有这些读取确实“未找到”.这些在技术上是与基准测试工具中的错误分开报告的,我告诉你,这是误导,因为你不会注意到.
我也不确定你在3节点集群上有什么类型的RAM /存储来处理那么多的记录,尽管它们很小.
要进行适当的基准测试,首先应使用仅插入工作负载(-w I)加载所有密钥,然后触发读取更新工作负载.