SolrCloud 随着时间的推移变得越来越慢
SolrCloud becoming slow over time
我有一个 3 node SolrCloud 设置 (replication factor 3)，运行 在 Ubuntu 14.04 Solr 6.0 SSD 上。发生了很多索引，只有 softCommits。一段时间后，索引速度变得非常慢，但是当我在变慢的节点上重新启动 solr 服务时，一切都恢复正常。问题是我需要猜测哪个节点变慢了。
我有 5 个集合，但只有一个集合（主要使用）变慢了。总数据大小为 144G，包括 tlog。
说core/collection是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 仪表板：
中学 1 的 Sematext 仪表板：
中学 2 的 Sematext 仪表板：
Master 的 Sematext GC：
中学 1 的 Sematext GC：
中学 2 的 Sematext GC：
更新 4 (2018-01-10)
这是一个很老的问题，但我最近发现有人使用 CVE-2017-12629 在我所有的 solr 机器上安装了一个 cryptocoin miner，我通过升级到 6.6.2 解决了这个问题。
如果您不确定您的系统是否被渗透，请使用 ps aux | grep solr 检查用户 solr 的进程。如果您看到两个或更多进程，尤其是非 java 进程，您可能是 运行 矿工。
所以您看到磁盘 I/O 在使用高写入吞吐量应用程序进行索引期间达到 100%。
Solr 索引的磁盘 I/O 有两个主要驱动程序：
- 正在将内存中的索引段刷新到磁盘。
- 将磁盘段合并为新的更大的段。
如果您的索引器没有直接调用 commit 作为索引过程的一部分 （您应该确保它不是），Solr 将 flush 根据您当前的设置将索引段写入磁盘：
- 每次您的 RAM 缓冲区填满时 (
"ramBufferSizeMB":100.0)
- 基于您的 3 分钟硬提交政策 (
"maxTime":180000)
如果您的索引器没有直接调用 optimize 作为索引过程的一部分 （您应该确保它不是），Solr will periodically merge index segments on disk 基于您当前的设置（默认合并策略）：
mergeFactor: 10，或者大致每次磁盘索引段数超过10个时。
根据您描述索引过程的方式：
2500 doc batches per thread x 10 parallel threads
...您可以使用更大的 RAM 缓冲区，以产生更大的初始索引段（然后刷新到磁盘的频率降低）。
然而事实上你的索引进程
works perfectly fine for most of the time but sometimes it becomes slow
... 让我想知道您是否只是看到了后台发生的大型 merge 的影响，并蚕食了当时快速索引所需的系统资源。
想法
您可以试验更大的 mergeFactor（例如 25）。这将减少后台索引段合并的频率，但不会减少它们发生时的资源消耗。 （另外，请注意更多的索引段通常会转化为更差的查询性能）。
在 indexConfig 中，您可以尝试覆盖 ConcurrentMergeScheduler 的默认设置以限制一次可以 运行 的合并数量（maxMergeCount), and/or 根据您愿意提供的系统资源限制可用于合并的线程数 (maxThreadCount)。
您可以增加 ramBufferSizeMB。这将减少内存中索引段被刷新到磁盘的频率，也有助于减慢合并节奏。
如果您不依赖 Solr 的持久性，您将希望 /var/solr/data 指向 local SSD 卷。如果您要通过网络挂载（这已在 Amazon 的 EBS 中记录），则 a significant write throughput penalty 比写入 ephemeral/local 存储少 10 倍。
您是否有主控每个内核的 CPU 负载，而不仅仅是组合的 CPU 图表？我注意到当我使用 Solr 索引时 Xmx 太小（如果您有 144GB 数据并且 Xmx=16GB 可能是这种情况），当索引进行时，合并将花费越来越多的时间。
在合并过程中，通常一个核心=100% CPU 而其他核心什么都不做。
您的主组合 CPU 图看起来像这样：序列期间只有 20% 的组合负载。
因此，检查合并因子是否是一个合理的值（在 10 到 20 之间或其他值）并可能提高 Xmx。
这是我开始玩的两件事。
问题：您的分析器（自定义分词器等）没有任何特殊之处吗？
我有一个 3 node SolrCloud 设置 (replication factor 3)，运行 在 Ubuntu 14.04 Solr 6.0 SSD 上。发生了很多索引，只有 softCommits。一段时间后，索引速度变得非常慢，但是当我在变慢的节点上重新启动 solr 服务时，一切都恢复正常。问题是我需要猜测哪个节点变慢了。
我有 5 个集合，但只有一个集合（主要使用）变慢了。总数据大小为 144G，包括 tlog。
说core/collection是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 仪表板：
中学 1 的 Sematext 仪表板：
中学 2 的 Sematext 仪表板：
Master 的 Sematext GC：
中学 1 的 Sematext GC：
中学 2 的 Sematext GC：
更新 4 (2018-01-10)
这是一个很老的问题，但我最近发现有人使用 CVE-2017-12629 在我所有的 solr 机器上安装了一个 cryptocoin miner，我通过升级到 6.6.2 解决了这个问题。
如果您不确定您的系统是否被渗透，请使用 ps aux | grep solr 检查用户 solr 的进程。如果您看到两个或更多进程，尤其是非 java 进程，您可能是 运行 矿工。
所以您看到磁盘 I/O 在使用高写入吞吐量应用程序进行索引期间达到 100%。
Solr 索引的磁盘 I/O 有两个主要驱动程序：
- 正在将内存中的索引段刷新到磁盘。
- 将磁盘段合并为新的更大的段。
如果您的索引器没有直接调用 commit 作为索引过程的一部分 （您应该确保它不是），Solr 将 flush 根据您当前的设置将索引段写入磁盘：
- 每次您的 RAM 缓冲区填满时 (
"ramBufferSizeMB":100.0) - 基于您的 3 分钟硬提交政策 (
"maxTime":180000)
如果您的索引器没有直接调用 optimize 作为索引过程的一部分 （您应该确保它不是），Solr will periodically merge index segments on disk 基于您当前的设置（默认合并策略）：
mergeFactor: 10，或者大致每次磁盘索引段数超过10个时。
根据您描述索引过程的方式：
2500 doc batches per thread x 10 parallel threads
...您可以使用更大的 RAM 缓冲区，以产生更大的初始索引段（然后刷新到磁盘的频率降低）。
然而事实上你的索引进程
works perfectly fine for most of the time but sometimes it becomes slow
... 让我想知道您是否只是看到了后台发生的大型 merge 的影响，并蚕食了当时快速索引所需的系统资源。
想法
您可以试验更大的
mergeFactor（例如 25）。这将减少后台索引段合并的频率，但不会减少它们发生时的资源消耗。 （另外，请注意更多的索引段通常会转化为更差的查询性能）。在 indexConfig 中，您可以尝试覆盖
ConcurrentMergeScheduler的默认设置以限制一次可以 运行 的合并数量（maxMergeCount), and/or 根据您愿意提供的系统资源限制可用于合并的线程数 (maxThreadCount)。您可以增加
ramBufferSizeMB。这将减少内存中索引段被刷新到磁盘的频率，也有助于减慢合并节奏。如果您不依赖 Solr 的持久性，您将希望
/var/solr/data指向 local SSD 卷。如果您要通过网络挂载（这已在 Amazon 的 EBS 中记录），则 a significant write throughput penalty 比写入 ephemeral/local 存储少 10 倍。
您是否有主控每个内核的 CPU 负载，而不仅仅是组合的 CPU 图表？我注意到当我使用 Solr 索引时 Xmx 太小（如果您有 144GB 数据并且 Xmx=16GB 可能是这种情况），当索引进行时，合并将花费越来越多的时间。 在合并过程中，通常一个核心=100% CPU 而其他核心什么都不做。 您的主组合 CPU 图看起来像这样：序列期间只有 20% 的组合负载。 因此，检查合并因子是否是一个合理的值（在 10 到 20 之间或其他值）并可能提高 Xmx。 这是我开始玩的两件事。 问题：您的分析器（自定义分词器等）没有任何特殊之处吗？