使用 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 统计信息时没有待处理的任务。
这个问题几乎是逐字逐句的问题，我是故意这样做的，因为（a）这似乎仍然是一个问题，并且（b）我无法对这个问题发表评论。
我认为值得在这里发布答案，尽管我也以几乎相同的方式回答了以下问题：
当 Solr 节点摄取记录时，它不仅必须摄取到正常的 Cassandra 写入路径，还必须将记录摄取到 Solr 写入路径。Cassandra 压缩以及 Solr 的等价物（Lucene 合并）正在发生。压缩和合并在磁盘 i/o 上都非常昂贵。
默认情况下，dse.yaml该设置会被max_solr_concurrency_per_core注释掉，这可能意味着在你的 solr core(s) 上为你的索引分配了太多线程。
@phact 在上面的博客中链接的帖子确实是一个不错的起点。监视IndexPoolmBean 是开始检查的好地方。检查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