Hello everyone.
I'm a little confused: replayUpdatesExecutor, only one thread is always
running?
OrderedExecutor limits the cfg.getReplayUpdatesThreads() number of tasks to be
submitted, and the newMDCAwareCachedThreadPool thread queue are up to
cfg.getReplayUpdatesThreads() queues, the thre
Well, you mentioned that the segments you’re concerned were merged a year ago.
If segments aren’t being merged, they’re pretty static.
There’s no real harm in optimizing _occasionally_, even in an NRT index. If you
have
segments that were merged that long ago, you may be indexing continually but
Thanks Eric.
My index is near real time and frequently updated.
I checked this page
https://lucene.apache.org/solr/guide/8_1/uploading-data-with-index-handlers.html#xml-update-commands
and using forceMerge/expungeDeletes are NOT recommended.
So I was hoping that the change in mergePolicyFactory w
Just go ahead and optimize/forceMerge, but do _not_ optimize to one
segment. Or you can expungeDeletes, that will rewrite all segments with
more than 10% deleted docs. As of Solr 7.5, these operations respect the 5G
limit.
See: https://lucidworks.com/post/solr-and-optimizing-your-index-take-ii/
B
Hi,
I am using solr 8.1 in production. We have about 30%-50% of deleted
documents in some old segments that were merged a year ago.
These segments size is about 5GB.
I was wondering why these segments have a high % of deleted docs and found
out that they are NOT being candidates for merging beca
Hi All
I've been trying to get a metric trigger set up in SolrCloud 8.4.1, but
it's not working, and was hoping for some help.
I've created a metric trigger using this:
```
POST /solr/admin/autoscaling {
"set-trigger": {
"name": "metric_trigger",
"event": "metric",
"waitFor": "10s"