我们有一个由8个节点组成的航空突刺集群。我们看到，在高峰时段，其中一个节点的平均负载量明显高于其他节点。同样在AMC仪表板中，我们看到该节点只有30％的读取成功。在跟踪了Aerospike社区中发布的一些类似问题之后，我们认为可能存在热键。
遵循（https://discuss.aerospike.com/t/how-to-identify-read-hotkeys/4193）之后，我们使用TCPdump实时发现了一些热键摘要。在十大摘要中，有趣的是，一个密钥在90％的时间内都存在。 然后，我们遵循（https://discuss.aerospike.com/t/faq-how-keys-and-digests-are-used-in-aerospike/4663）从这些摘要中找出UserKey /记录。我们能够映射所有密钥中的用户密钥，只有90％的时间存在一个密钥。
有什么方法可以识别该热键吗？
答案 0 :(得分：3)
根据您的Aerospike版本，您还可以更改rw-client模块的日志记录级别，这还将在日志中打印摘要。这可能会删除tcpdump方法中的任何误报。
asinfo -v“ set-log：id = 0; rw-client = detail”
asinfo -v“ set-log：id = 0; rw-client = info”
您还尝试了以上文章中的UDF来确定集合和密钥吗？ （它们的原始密钥仅在客户端显式启用了SendKEY策略时才会存储）。是否有相应的记录写入失败，例如记录太大？或者可能试图读取不存在的记录。 （未找到读取）记录太大的写入失败将对您的网络基础结构产生最大影响。在这两种情况下，摘要和记录都不会进入存储，摘要也不会与现有记录匹配。
答案 1 :(得分：2)
带有胭脂摘要的频繁读取请求可能会因“未找到”错误而失败（因此只有30％的读取成功）。但是Aerospike将花费其资源（CPU）在索引树中搜索此摘要。如果是这样，则数据库中将没有与您通过tcpdump找到的摘要相对应的记录。因此，您将不会在数据库中获得有关该数据库的任何详细信息。您如何识别其他摘要的关键字？您将面对什么问题来找到与胭脂摘要相对应的密钥？
另一个选项是追溯到该应用程序。一种选择是在tcpdump中查看是否所有针对此胭脂摘要的请求都来自一台计算机。那将大大缩小您的搜索范围。过去我们已经看到机器人在制造这样的混乱局面。