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

Question

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

我有5个集合,但只有一个集合(主要用于)变慢.总数据大小144G包括tlogs.

所说的核心/集合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个线程,大部分时间都可以正常工作,但有时会变得很慢.偶尔有来自其他来源的更新/索引调用,但它不到百分之一.

UPDATE

完整配置(来自Config API的输出)是http://pastebin.com/GtUdGPLG

更新2

这些是命令行参数:

-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仪表板:

中学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作为索引过程的一部分（并且您应该确保它不是），Solr 将根据您当前的设置定期合并磁盘上的索引段（默认合并策略）：

• mergeFactor: 10，或者大约每次磁盘上索引段的数量超过 10 时。

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

每个线程 2500 个文档批次x 10 个并行线程

...您可能可以使用更大的 RAM 缓冲区，以产生更大的初始索引段（然后刷新到磁盘的频率较低）。

然而事实上你的索引过程

大部分时间都工作得很好，但有时会变得很慢

...让我想知道您是否只是看到后台发生的大型合并的效果，并蚕食了当时快速索引所需的系统资源。

想法

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

• 在 indexConfig 中，您可以尝试覆盖默认设置，以ConcurrentMergeScheduler限制可同时运行的合并数量 ( )，和/或根据系统maxMergeCount限制可用于合并的线程数量 ( )maxThreadCount您愿意提供的资源。

• 你可以增加你的ramBufferSizeMB. 这将减少内存中索引段刷新到磁盘的频率，也有助于减慢合并节奏。

• 如果您不依赖 Solr 来实现持久性，则需要/var/solr/data指向本地SSD 卷。如果您要通过网络挂载（这已在 Amazon 的 EBS 中记录），则会出现显着的写入吞吐量损失，最多比写入临时/本地存储少 10 倍。