使用 DSE 4.8.7，我们能够每秒将约 1,000 条记录插入到由 Solr 索引的 cassandra 表中。吞吐量有一段时间(可能 30-60 分钟)，直到 2-3 个节点(在 5 节点集群中)开始在日志中显示这些消息:
INFO [datastore.data Index WorkPool work thread-0] 2016-05-17 19:28:26,183 AbstractMetrics.java:114 - Cannot record QUEUE latency of 29 minutes because higher than 10 minutes.
此时，插入吞吐量下降到 2-10 条记录/秒。 重启节点解决问题。集群中所有节点的操作系统负载和 IO 都很低。此外，在查看 nodetool 统计信息时没有待处理的任务。
这个问题几乎是字面上的问题 here ，我是故意这样做的，因为 (a) 这似乎仍然是一个问题，并且 (b) 我无法对这个问题发表评论。
最佳答案
我认为值得在这里发布一个答案，尽管我也以几乎相同的方式回答了以下问题:
Cannot record QUEUE latency of n minutes - DSE
当 Solr 节点在摄取记录时，它不仅要摄取到正常的 Cassandra 写入路径中，还必须将记录摄取到 Solr 写入路径中。 Cassandra 压缩以及 Solr 的等效(Lucene 合并)正在发生。压缩和合并在磁盘 i/o 上都非常昂贵。
默认情况下，dse.yaml 会将设置 max_solr_concurrency_per_core 注释掉，这可能意味着为您的 solr 核心索引分配了太多线程。
@phact 在上面的博客中链接的帖子确实是一个很好的起点。监视 IndexPool mBean 是开始检查的好地方。检查 QueueDepth 并查看其是否增加，如果增加，则节点无法跟上索引吞吐量，以及查看 CPU 和 I/O 的时间。如果您没有看到高 CPU，那么您可能会增加并发性。
在大型集群中，通常高速率的摄取是在具有 Cassandra 节点的 DC 中完成的，这些节点复制到它们自己的 DC 中的 Solr 节点。像这样的拆分工作负载也可能是您的一个不错的考虑因素。
另一件事也是索引的大小，通过在架构中设置 omitNorms=true 来减少文本字段等内容的大小也可以大大减少索引的大小。
我会在下面发布一些可能对您有帮助的文档链接。
https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchTune.html
https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchCmtQryMbeans.html
关于solr - DSE/Solr : Cannot record QUEUE latency，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37285551/