SolrCloud随着时间的推移变得缓慢

Question

我有一个3 node SolrCloud设置（replication factor 3），在SSD上的Ubuntu 14.04 Solr 6.0上运行。很多索引都在发生，只有softCommits。一段时间后，索引速度变得非常慢，但是当我重新启动变慢的节点上的solr服务时，一切都恢复正常。问题是我需要猜测哪个节点变慢。

我有5个系列，但只有一个系列（主要用于）变慢。总数据大小为144G，包括tlog。

所说的核心/集合是99G，包括tlogs，tlog只有313M。堆大小为16G，总内存为32G，数据存储在SSD上。每个节点的配置都相同。

看起来很奇怪的是，当这次点击时，我在这两个奴隶上每秒有几百或几千条日志行：

2016-09-16 10:00:30.476 INFO  (qtp1190524793-46733) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[ka2PZAqO_ (1545622027473256450)]} 0 0
2016-09-16 10:00:30.477 INFO  (qtp1190524793-46767) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[nlFpoYNt_ (1545622027474305024)]} 0 0
2016-09-16 10:00:30.477 INFO  (qtp1190524793-46766) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[tclMjXH6_ (1545622027474305025), 98OPJ3EJ_ (1545622027476402176)]} 0 0
2016-09-16 10:00:30.478 INFO  (qtp1190524793-46668) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[btceXK4M_ (1545622027475353600)]} 0 0
2016-09-16 10:00:30.479 INFO  (qtp1190524793-46799) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[3ndK3HzB_ (1545622027476402177), riCqrwPE_ (1545622027477450753)]} 0 1
2016-09-16 10:00:30.479 INFO  (qtp1190524793-46820) [c:mycollection s:shard1 r:core_node2 x:mycollection_shard1_replica1] o.a.s.u.p.LogUpdateProcessorFactory [mycollection_shard1_replica1]  webapp=/solr path=/update params={update.distrib=FROMLEADER&update.chain=add-unknown-fields-to-the-schema&distrib.from=http://192.168.0.3:8983/solr/mycollection_shard1_replica3/&wt=javabin&version=2}{add=[wr5k3mfk_ (1545622027477450752)]} 0 0

在这种情况下，192.168.0.3是主人。

我的工作流程是我同时插入大约2500个docs和~10个线程，大部分时间都可以正常工作，但有时会变得很慢。偶尔有来自其他来源的更新/索引调用，但它不到百分之一。

更新

完整配置（来自Config API的输出）为http://pastebin.com/GtUdGPLG

更新2

这些是命令行args：

-DSTOP.KEY=solrrocks
-DSTOP.PORT=7983
-Dhost=192.168.0.1
-Djetty.home=/opt/solr/server
-Djetty.port=8983
-Dlog4j.configuration=file:/var/solr/log4j.properties
-Dsolr.install.dir=/opt/solr
-Dsolr.solr.home=/var/solr/data
-Duser.timezone=UTC
-DzkClientTimeout=15000
-DzkHost=192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181
-XX:+CMSParallelRemarkEnabled
-XX:+CMSScavengeBeforeRemark
-XX:+ParallelRefProcEnabled
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:CMSInitiatingOccupancyFraction=50
-XX:CMSMaxAbortablePrecleanTime=6000
-XX:ConcGCThreads=4
-XX:MaxTenuringThreshold=8
-XX:NewRatio=3
-XX:OnOutOfMemoryError=/opt/solr/bin/oom_solr.sh 8983 /var/solr/logs
-XX:ParallelGCThreads=4
-XX:PretenureSizeThreshold=64m
-XX:SurvivorRatio=4
-XX:TargetSurvivorRatio=90-Xloggc:/var/solr/logs/solr_gc.log
-Xms16G
-Xmx16G
-Xss256k
-verbose:gc

更新3

再次发生，这些是一些Sematext图表：

Master的Sematext Dashboard：

中学1的Sematext仪表板：

中学2的Sematext仪表板：

Master的Sematext GC：

中学1的Sematext GC：

中学2的Sematext GC：

更新4（2018-01-10）

这是一个相当古老的问题，但我最近发现有人使用CVE-2017-12629在我的所有solr机器上安装了一个cryptocoin矿工，我将其升级到6.6.2。

如果您不确定系统是否已渗透，请使用solr检查用户ps aux | grep solr的流程。如果您看到两个或更多进程，尤其是非Java进程，则可能正在运行一个矿工。

Answer 1

因此，您在使用高写入吞吐量应用程序进行索引编制期间看到磁盘I / O达到100％。

使用Solr索引的磁盘I / O有两个主要驱动因素：

1. 将内存中的索引段刷新到磁盘。
2. 将磁盘段合并为新的更大的段。

如果您的索引器没有直接调用commit作为索引过程的一部分（并且您应该确保它不是），那么Solr将根据您当前的设置将索引段刷新到磁盘：

• 每次RAM缓冲区填满（"ramBufferSizeMB":100.0）
• 根据您的3分钟硬提交政策（"maxTime":180000）

如果您的索引器没有直接调用optimize作为索引过程的一部分（并且您应该确保它不是），{{3} }根据您当前的设置（默认合并策略）：

• mergeFactor: 10，或大致每次磁盘索引段数超过10。

根据您描述索引过程的方式：

  

每个线程2500个doc批次 x 10个并行线程

...你可能会使用更大的RAM缓冲区，以产生更大的初始索引段（然后不那么频繁地刷新到磁盘）。

然而，您的索引过程

  

在大多数情况下都能很好地工作，但有时它变得很慢

...让我想知道你是否只是看到后台发生了大量合并的影响，并且正在蚕食当时快速索引所需的系统资源。

<强>观

• 您可以尝试使用更大的mergeFactor（例如25）。这将减少后台索引段合并的频率，但不会降低资源消耗。 （另外，请注意，更多的索引段通常会导致查询性能下降）。

• 在indexConfig中，您可以尝试覆盖ConcurrentMergeScheduler的默认设置，以限制一次可以运行的合并次数（maxMergeCount），和/或限制可以用于合并的线程数（maxThreadCount），基于您愿意提供的系统资源。

• 您可以增加ramBufferSizeMB。这将减少内存索引段被刷新到磁盘的频率，也会降低合并节奏的速度。

• 如果您不依赖Solr的持久性，那么您希望/var/solr/data指向本地 SSD卷。如果您要通过网络装载（这已在亚马逊的EBS中记录），则有Solr will periodically merge index segments on disk，比写入短暂/本地存储空间少10倍。

  < / LI>

Answer 2

您是否拥有主站每个核心的CPU负载，而不仅仅是组合CPU图形？我注意到当我使用Solr索引Xmx太小时（如果你有144GB数据和Xmx = 16GB可能就是这种情况），当索引进行时，合并将花费越来越多的时间。 在合并期间，通常一个核心= 100％CPU，而其他核心不执行任何操作。 您的主组合CPU图形看起来像这样：序列中只有20％的组合负载。 因此，检查合并因子是否合理（10到20之间），并可能提高Xmx。 这是我开始玩的两件事。 问题：您的分析器（自定义标记器等）没有任何特殊之处吗？