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

Question

我有一个 3 node SolrCloud 设置 (replication factor 3)，在 SSD 上运行 Ubuntu 14.04 Solr 6.0。许多索引发生，只有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 个文档和大约 10 个线程，这在大多数情况下工作得非常好，但有时它会像描述的那样变慢。偶尔会有来自其他来源的更新/索引调用，但不到百分之一。

更新

完整的配置（来自 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 Graphs：

Master 的 Sematext 仪表板：

中学 1 的 Sematext 仪表板：

中学 2 的 Sematext 仪表板：

Master 的 Sematext GC：

Secondary 1 的 Sematext GC：

中学 2 的 Sematext GC：

更新 4 (2018-01-10)

这是一个很老的问题，但我最近发现有人使用CVE-2017-12629 在我所有的 solr 机器上安装了一个加密币矿工，我通过升级到 6.6.2 解决了这个问题。

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

Answer 1

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

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

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

---

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

• 每次 RAM 缓冲区填满时 ("ramBufferSizeMB":100.0)
• 基于您的 3 分钟硬提交策略 ("maxTime":180000)

---

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

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

---

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

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

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

然而事实上你的索引过程

大部分时间都可以正常工作，但有时会变慢

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

---

想法

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

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

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

• 如果您不依赖 Solr 来实现持久性，则需要 /var/solr/data 指向 本地 SSD 卷。如果您要通过网络挂载（Amazon 的 EBS 已对此进行了记录），则有 a significant write throughput penalty，比写入临时/本地存储最多少 10 倍。

Answer 2

您是否有主控每个核心的 CPU 负载，而不仅仅是组合的 CPU 图？我注意到的是，当我在 Xmx 太小时（如果您有 144GB 数据且 Xmx=16GB 的情况下）使用 Solr 进行索引时，当索引进行时，合并将花费越来越多的时间。 在合并期间，通常一个核心 = 100% CPU，而其他核心什么也不做。 您的主 CPU 组合图如下所示：序列期间只有 20% 的组合负载。 因此，请检查合并因子是否是一个合理的值（在 10 到 20 或其他值之间）并可能提高 Xmx。 这是我开始玩的两件事。 问题：您的分析器（自定义标记器等）没有什么特别之处？