[ 
https://issues.apache.org/jira/browse/SOLR-12755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16608438#comment-16608438
 ] 

Shawn Heisey commented on SOLR-12755:
-------------------------------------

bq. Free disk space requirements: 1-2x size of ALL shards on the machine vs 
1-2x size of largest shard

Are you seeing SolrCloud do simultaneous optimizes of multiple shards?  It was 
my understanding that when you ask for an optimize, that SolrCloud will step 
through the shard replicas for that collection and optimize them one at a time 
until the entire collection is done.  Doing them simultaneously could cause 
serious I/O problems.

You are correct that distrib=false should restrict the optimize to one core, 
like it does for a query.  This has been brought up before.  See SOLR-10740.


> Force merge (optimize) should respect distrib=false
> ---------------------------------------------------
>
>                 Key: SOLR-12755
>                 URL: https://issues.apache.org/jira/browse/SOLR-12755
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud, update
>    Affects Versions: 7.4
>            Reporter: Daniel Lowe
>            Priority: Major
>
> It would be desirable in a Solr Cloud configuration if a request like:
> update?optimize=true&distrib=false
> only executed on the shard that received the request.
>  
> As is well known force merging is a very expensive/disk space hungry 
> operation and hence this increased control should address the following 
> issues:
> Free disk space requirements: 1-2x size of ALL shards on the machine vs 1-2x 
> size of largest shard
> I/O: High disk contention when a machine holds multiple shards as all shards 
> are being simultaneously rewritten
> Availability: All replicas will simultaneously have impaired performance
>  
> Relevant previous issue: SOLR-6264



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to