使用DSE 4.8.7，我们能够将〜1,000条记录/秒插入到cassandra表中，该表由Solr索引。吞吐量可以持续一段时间（可能是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记录/秒。 重新启动节点可以解决问题。对于群集中的所有节点，OS负载和IO都是低的。此外，查看nodetool统计信息时没有待处理的任务。
这个问题几乎完全是here这个问题的逐字逐句，因为（a）这看起来仍然是一个问题，而且（b）我不能评论这个问题。
答案 0 :(得分：0)
我认为值得在这里发布答案，尽管我也以几乎相同的方式回答了以下问题：
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