So is there anything that can be done from a tuning perspective, to recover a shard that is 75%-90% full, other that get rid of the index and rebuild the data? Also to prevent this issue from re-occurring, looks like we need make our system aggressive with segment merges using lower merge factor
Thanks, Rishi. -----Original Message----- From: Shawn Heisey <apa...@elyograg.org> To: solr-user <solr-user@lucene.apache.org> Sent: Mon, Apr 20, 2015 11:25 am Subject: Re: Solr Cloud reclaiming disk space from deleted documents On 4/20/2015 8:44 AM, Rishi Easwaran wrote: > Yeah I noticed that. Looks like optimize won't work since on some disks we are already pretty full. > Any thoughts on increasing/decreasing <mergeFactor>10</mergeFactor> or ConcurrentMergeScheduler to make solr do merges faster. You don't have to do an optimize to need 2x disk space. Even normal merging, if it happens just right, can require the same disk space as a full optimize. Normal Solr operation requires that you have enough space for your index to reach at least double size on occasion. Higher merge factors are better for indexing speed, because merging happens less frequently. Lower merge factors are better for query speed, at least after the merging finishes, because merging happens more frequently and there are fewer total segments at any given moment. During a merge, there is so much I/O that query speed is often negatively affected. Thanks, Shawn
