Recently we had modified `noCFSRatio` parameter of merge policy.
<mergePolicyFactory
class="org.apache.solr.index.TieredMergePolicyFactory">
<int name="maxMergeAtOnce">8</int>
<int name="segmentsPerTier">5</int>
<double name="FloorSegmentMB">50.0</double>
<double name="maxMergedSegmentMB">4000</double>
<double name="noCFSRatio">0.0</double>
</mergePolicyFactory>
This is our current merge policy. Earlier `noCFSRatio` was set to `0.1`.
generally to reflect any changes of solrconfig we reload the collection. But
we stop doing this because we observe that during reload operation some of
the replicas go under-recovery after reloading operation.
So instead of reload, we restart each replica one by one.
Our restart procesdure:
1. Indexing was stopped on the collection and issued a hard commit
2. First restarted are the non leader replica and in the end restarted
leader replica
*Question:*
Since reload is not done, none of the replica (including leader) will have
updated solrconfig. And if we restart replica and if it trys to sync up with
leader will it reflect the latest changes of solrconfig or it will be the
same as leader.
Also after this exercise, we have seen a sudden spike in CPU utilization on
a few replicas though there is not much increase in our system load.
System config of VM:
disk size: 250 GB
cpu: (8 vcpus, 64 GiB memory)
Solr Collection detail:
single collection having 6 shard. each Vm is hosting single replica.
Collection size: 60 GB (each shard size is 10 GB)
Average doc size: 1.0Kb
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
