Solr
  1. Solr
  2. SOLR-6816 Review SolrCloud Indexing Performance.
  3. SOLR-6820

The sync on the VersionInfo bucket in DistributedUpdateProcesser#addDocument appears to be a large bottleneck when using replication.

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.2, 6.0
    • Component/s: SolrCloud
    • Labels:
      None
    1. SOLR-6820.patch
      2 kB
      Timothy Potter
    2. threads.png
      17 kB
      Mark Miller

      Activity

      Hide
      Mark Miller added a comment -

      In my simple testing for SOLR-6816, I can see that raising the number of buckets to 1024 from 256 seems to do nothing, but raising it to 65536 seem to give performance similar to removing the sync entirely.

      We should probably make the number of buckets configurable, consider our default, and review the hashing that is going on.

      Show
      Mark Miller added a comment - In my simple testing for SOLR-6816 , I can see that raising the number of buckets to 1024 from 256 seems to do nothing, but raising it to 65536 seem to give performance similar to removing the sync entirely. We should probably make the number of buckets configurable, consider our default, and review the hashing that is going on.
      Hide
      Yonik Seeley added a comment -

      That's pretty surprising... with a 6 core CPU, it's unclear how 256 buckets could cause that much contention. The id's are UUIDs, and they are hashed with murmur3... it should be well distributed. Is the occasional block causing something else bad to happen in the whole stack (sending clients, etc)?

      Show
      Yonik Seeley added a comment - That's pretty surprising... with a 6 core CPU, it's unclear how 256 buckets could cause that much contention. The id's are UUIDs, and they are hashed with murmur3... it should be well distributed. Is the occasional block causing something else bad to happen in the whole stack (sending clients, etc)?
      Hide
      Mark Miller added a comment -

      I'll collect the hot spots for each case shortly. Might be interesting to add some quick debug stats as well.

      Show
      Mark Miller added a comment - I'll collect the hot spots for each case shortly. Might be interesting to add some quick debug stats as well.
      Hide
      Mark Miller added a comment -

      In the instance I'm seeing, the hashing looks okay, but it seems that this can be hit and block for up almost a minute in this test. It will hold the bucket sync and the other threads appear to lock up as well, I assume as each quickly hits a doc that needs the lock held by the thread blocked below:

      qtp1204167249-19 [BLOCKED]
      org.apache.lucene.index.IndexWriter.publishFlushedSegment(SegmentCommitInfo, FrozenBufferedUpdates, FrozenBufferedUpdates) IndexWriter.java:2273
      org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.publishFlushedSegment(IndexWriter, DocumentsWriterPerThread$FlushedSegment, FrozenBufferedUpdates) DocumentsWriterFlushQueue.java:198
      org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.finishFlush(IndexWriter, DocumentsWriterPerThread$FlushedSegment, FrozenBufferedUpdates) DocumentsWriterFlushQueue.java:213
      org.apache.lucene.index.DocumentsWriterFlushQueue$SegmentFlushTicket.publish(IndexWriter) DocumentsWriterFlushQueue.java:249
      org.apache.lucene.index.DocumentsWriterFlushQueue.innerPurge(IndexWriter) DocumentsWriterFlushQueue.java:116
      org.apache.lucene.index.DocumentsWriterFlushQueue.tryPurge(IndexWriter) DocumentsWriterFlushQueue.java:149
      org.apache.lucene.index.DocumentsWriter.purgeBuffer(IndexWriter, boolean) DocumentsWriter.java:183
      org.apache.lucene.index.IndexWriter.purge(boolean) IndexWriter.java:4536
      org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(boolean, boolean) IndexWriter.java:4550
      org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(IndexWriter, boolean, boolean) DocumentsWriter.java:700
      org.apache.lucene.index.IndexWriter.processEvents(Queue, boolean, boolean) IndexWriter.java:4578
      org.apache.lucene.index.IndexWriter.processEvents(boolean, boolean) IndexWriter.java:4570
      org.apache.lucene.index.IndexWriter.updateDocument(Term, IndexDocument, Analyzer) IndexWriter.java:1394
      org.apache.solr.update.DirectUpdateHandler2.addDoc0(AddUpdateCommand) DirectUpdateHandler2.java:240
      org.apache.solr.update.DirectUpdateHandler2.addDoc(AddUpdateCommand) DirectUpdateHandler2.java:164
      org.apache.solr.update.processor.RunUpdateProcessor.processAdd(AddUpdateCommand) RunUpdateProcessorFactory.java:69
      org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(AddUpdateCommand) UpdateRequestProcessor.java:51
      org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(AddUpdateCommand) DistributedUpdateProcessor.java:931
      org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(AddUpdateCommand) DistributedUpdateProcessor.java:1085
      org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(AddUpdateCommand) DistributedUpdateProcessor.java:697
      org.apache.solr.update.processor.LogUpdateProcessor.processAdd(AddUpdateCommand) LogUpdateProcessorFactory.java:104

      Other intermittent times seem to lock up very briefly as all the threads hit the same bucket and one takes a moment to add the doc.

      Show
      Mark Miller added a comment - In the instance I'm seeing, the hashing looks okay, but it seems that this can be hit and block for up almost a minute in this test. It will hold the bucket sync and the other threads appear to lock up as well, I assume as each quickly hits a doc that needs the lock held by the thread blocked below: qtp1204167249-19 [BLOCKED] org.apache.lucene.index.IndexWriter.publishFlushedSegment(SegmentCommitInfo, FrozenBufferedUpdates, FrozenBufferedUpdates) IndexWriter.java:2273 org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.publishFlushedSegment(IndexWriter, DocumentsWriterPerThread$FlushedSegment, FrozenBufferedUpdates) DocumentsWriterFlushQueue.java:198 org.apache.lucene.index.DocumentsWriterFlushQueue$FlushTicket.finishFlush(IndexWriter, DocumentsWriterPerThread$FlushedSegment, FrozenBufferedUpdates) DocumentsWriterFlushQueue.java:213 org.apache.lucene.index.DocumentsWriterFlushQueue$SegmentFlushTicket.publish(IndexWriter) DocumentsWriterFlushQueue.java:249 org.apache.lucene.index.DocumentsWriterFlushQueue.innerPurge(IndexWriter) DocumentsWriterFlushQueue.java:116 org.apache.lucene.index.DocumentsWriterFlushQueue.tryPurge(IndexWriter) DocumentsWriterFlushQueue.java:149 org.apache.lucene.index.DocumentsWriter.purgeBuffer(IndexWriter, boolean) DocumentsWriter.java:183 org.apache.lucene.index.IndexWriter.purge(boolean) IndexWriter.java:4536 org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(boolean, boolean) IndexWriter.java:4550 org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(IndexWriter, boolean, boolean) DocumentsWriter.java:700 org.apache.lucene.index.IndexWriter.processEvents(Queue, boolean, boolean) IndexWriter.java:4578 org.apache.lucene.index.IndexWriter.processEvents(boolean, boolean) IndexWriter.java:4570 org.apache.lucene.index.IndexWriter.updateDocument(Term, IndexDocument, Analyzer) IndexWriter.java:1394 org.apache.solr.update.DirectUpdateHandler2.addDoc0(AddUpdateCommand) DirectUpdateHandler2.java:240 org.apache.solr.update.DirectUpdateHandler2.addDoc(AddUpdateCommand) DirectUpdateHandler2.java:164 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(AddUpdateCommand) RunUpdateProcessorFactory.java:69 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(AddUpdateCommand) UpdateRequestProcessor.java:51 org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(AddUpdateCommand) DistributedUpdateProcessor.java:931 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(AddUpdateCommand) DistributedUpdateProcessor.java:1085 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(AddUpdateCommand) DistributedUpdateProcessor.java:697 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(AddUpdateCommand) LogUpdateProcessorFactory.java:104 Other intermittent times seem to lock up very briefly as all the threads hit the same bucket and one takes a moment to add the doc.
      Hide
      Yonik Seeley added a comment - - edited

      In the instance I'm seeing, the hashing looks okay, but it seems that this can be hit and block for up almost a minute in this test.

      Hmmm, this looks like a lucene limitation, and perhaps should be considered a bug. It looks like the IndexWriter is "stealing" the thread used to add a document in order flush a complete segment (and hence a single add can sometimes take orders of magnitude longer?)

      Show
      Yonik Seeley added a comment - - edited In the instance I'm seeing, the hashing looks okay, but it seems that this can be hit and block for up almost a minute in this test. Hmmm, this looks like a lucene limitation, and perhaps should be considered a bug. It looks like the IndexWriter is "stealing" the thread used to add a document in order flush a complete segment (and hence a single add can sometimes take orders of magnitude longer?)
      Hide
      Mark Miller added a comment -

      This may be related to SOLR-6838. I have to do some investigation with Overwrite = false.

      Show
      Mark Miller added a comment - This may be related to SOLR-6838 . I have to do some investigation with Overwrite = false.
      Hide
      Timothy Potter added a comment -

      First pass ... raising this to 65536 as Mark indicated made a significant impact in overall indexing performance in my testing.

      Specifically, with branch_5x my baseline got:

      num docs         secs         docs/sec
      9992262          427	      23401.08 (no replication, leader only)
      9992262          758	      13182.40 (leader + 1 replica)
      

      with this patch applied and using 65536:

      9992262          382          26157.75
      9992262          710          14073.61
      

      that's a pretty significant bump in overall performance for an additional 0.5M of memory per collection IMO

      Show
      Timothy Potter added a comment - First pass ... raising this to 65536 as Mark indicated made a significant impact in overall indexing performance in my testing. Specifically, with branch_5x my baseline got: num docs secs docs/sec 9992262 427 23401.08 (no replication, leader only) 9992262 758 13182.40 (leader + 1 replica) with this patch applied and using 65536: 9992262 382 26157.75 9992262 710 14073.61 that's a pretty significant bump in overall performance for an additional 0.5M of memory per collection IMO
      Hide
      Timothy Potter added a comment -

      jfyi - my patch for SOLR-7332 includes the fix for this as well, but I'll probably separate the two before committing

      Show
      Timothy Potter added a comment - jfyi - my patch for SOLR-7332 includes the fix for this as well, but I'll probably separate the two before committing
      Hide
      Yonik Seeley added a comment -

      At first I couldn't understand why such a large number of buckets was needed... the math for two documents wanting to use the same bucket at the same time should be similar to the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem , with "n" being the number of indexing threads, and "d" being the number of buckets.

      But then I realized... if one add takes a long time because lucene used the thread to flush a segment, then other indexing threads will quickly pile up on the same bucket. Basically, and indexing thread quickly indexes documents into random slots until it accidentally hits the same bucket as the blocked thread, and then it stops.
      I guess having lots of buckets is the best work-around we can do for now (but it still doesn't cure the problem). The root cure would be a way for Lucene to not use client threads for long running index operations.

      Show
      Yonik Seeley added a comment - At first I couldn't understand why such a large number of buckets was needed... the math for two documents wanting to use the same bucket at the same time should be similar to the birthday problem: http://en.wikipedia.org/wiki/Birthday_problem , with "n" being the number of indexing threads, and "d" being the number of buckets. But then I realized... if one add takes a long time because lucene used the thread to flush a segment, then other indexing threads will quickly pile up on the same bucket. Basically, and indexing thread quickly indexes documents into random slots until it accidentally hits the same bucket as the blocked thread, and then it stops. I guess having lots of buckets is the best work-around we can do for now (but it still doesn't cure the problem). The root cure would be a way for Lucene to not use client threads for long running index operations.
      Hide
      Timothy Potter added a comment -

      Thanks for the nice description of this Yonik! I think this thread dump shows the problem nicely:

      "recoveryExecutor-7-thread-1" prio=10 tid=0x00007f0fe821e800 nid=0xbafc runnable [0x00007f1003c30000]
         java.lang.Thread.State: RUNNABLE
              at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc(Lucene41PostingsReader.java:440)
              at org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet(MultiTermQueryWrapperFilter.java:111)
              at org.apache.lucene.search.ConstantScoreQuery$ConstantWeight.scorer(ConstantScoreQuery.java:157)
              at org.apache.lucene.search.BooleanQuery$BooleanWeight.scorer(BooleanQuery.java:351)
              at org.apache.lucene.search.QueryWrapperFilter$1.iterator(QueryWrapperFilter.java:59)
              at org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:545)
              at org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:284)
              - locked <0x00000005d9e96768> (a org.apache.lucene.index.BufferedUpdatesStream)
              at org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3238)
              - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter)
              at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3229)
              - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter)
              at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:384)
              - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter)
              - locked <0x00000005dc1943a8> (a java.lang.Object)
              at org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:289)
              at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:274)
              at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:251)
              at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1465)
              at org.apache.solr.update.UpdateLog.add(UpdateLog.java:424)
              - locked <0x00000005dd011ab8> (a org.apache.solr.update.UpdateLog)
              at org.apache.solr.update.DirectUpdateHandler2.addAndDelete(DirectUpdateHandler2.java:449)
              - locked <0x00000005dc1943d8> (a java.lang.Object)
              at org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:216)
              at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
              at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
              at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
              at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:928)
              at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1082)
              - locked <0x00000005c2b560d0> (a org.apache.solr.update.VersionBucket)
              at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:695)
              at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
              at org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1343)
              at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1217)
              ...
      

      and

      "recoveryExecutor-7-thread-2" prio=10 tid=0x00007ec5b4003000 nid=0xc131 waiting for monitor entry [0x00007f1003aab000]
         java.lang.Thread.State: BLOCKED (on object monitor)
              at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:999)
              - waiting to lock <0x00000005c2b560d0> (a org.apache.solr.update.VersionBucket)
              at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:695)
              at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
              at org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1343)
              at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1217)
              at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
             ...
      
      Show
      Timothy Potter added a comment - Thanks for the nice description of this Yonik! I think this thread dump shows the problem nicely: "recoveryExecutor-7-thread-1" prio=10 tid=0x00007f0fe821e800 nid=0xbafc runnable [0x00007f1003c30000] java.lang. Thread .State: RUNNABLE at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc(Lucene41PostingsReader.java:440) at org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet(MultiTermQueryWrapperFilter.java:111) at org.apache.lucene.search.ConstantScoreQuery$ConstantWeight.scorer(ConstantScoreQuery.java:157) at org.apache.lucene.search.BooleanQuery$BooleanWeight.scorer(BooleanQuery.java:351) at org.apache.lucene.search.QueryWrapperFilter$1.iterator(QueryWrapperFilter.java:59) at org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:545) at org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:284) - locked <0x00000005d9e96768> (a org.apache.lucene.index.BufferedUpdatesStream) at org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3238) - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter) at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3229) - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter) at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:384) - locked <0x00000005d9a4f2a8> (a org.apache.solr.update.SolrIndexWriter) - locked <0x00000005dc1943a8> (a java.lang. Object ) at org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:289) at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:274) at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:251) at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1465) at org.apache.solr.update.UpdateLog.add(UpdateLog.java:424) - locked <0x00000005dd011ab8> (a org.apache.solr.update.UpdateLog) at org.apache.solr.update.DirectUpdateHandler2.addAndDelete(DirectUpdateHandler2.java:449) - locked <0x00000005dc1943d8> (a java.lang. Object ) at org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:216) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:928) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1082) - locked <0x00000005c2b560d0> (a org.apache.solr.update.VersionBucket) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:695) at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104) at org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1343) at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1217) ... and "recoveryExecutor-7-thread-2" prio=10 tid=0x00007ec5b4003000 nid=0xc131 waiting for monitor entry [0x00007f1003aab000] java.lang. Thread .State: BLOCKED (on object monitor) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:999) - waiting to lock <0x00000005c2b560d0> (a org.apache.solr.update.VersionBucket) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:695) at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104) at org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1343) at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1217) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ...
      Hide
      ASF subversion and git services added a comment -

      Commit 1680586 from Timothy Potter in branch 'dev/trunk'
      [ https://svn.apache.org/r1680586 ]

      SOLR-6820: Make the number of version buckets used by the UpdateLog configurable as increasing beyond the default 256 has been shown to help with high volume indexing performance in SolrCloud

      Show
      ASF subversion and git services added a comment - Commit 1680586 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1680586 ] SOLR-6820 : Make the number of version buckets used by the UpdateLog configurable as increasing beyond the default 256 has been shown to help with high volume indexing performance in SolrCloud
      Hide
      ASF subversion and git services added a comment -

      Commit 1680593 from Timothy Potter in branch 'dev/branches/branch_5x'
      [ https://svn.apache.org/r1680593 ]

      SOLR-6820: Make the number of version buckets used by the UpdateLog configurable as increasing beyond the default 256 has been shown to help with high volume indexing performance in SolrCloud

      Show
      ASF subversion and git services added a comment - Commit 1680593 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1680593 ] SOLR-6820 : Make the number of version buckets used by the UpdateLog configurable as increasing beyond the default 256 has been shown to help with high volume indexing performance in SolrCloud
      Hide
      Shalin Shekhar Mangar added a comment -

      Shouldn't we increase the default numBuckets to 65536? It doesn't look very expensive to do so – the numBuckets are used to create an array of VersionBucket objects each of which contains a single long value. The benefit is quite significant for such a small cost.

      Show
      Shalin Shekhar Mangar added a comment - Shouldn't we increase the default numBuckets to 65536? It doesn't look very expensive to do so – the numBuckets are used to create an array of VersionBucket objects each of which contains a single long value. The benefit is quite significant for such a small cost.
      Hide
      Timothy Potter added a comment -

      Shalin Shekhar Mangar good point! I'm happy to make the default 65536 ... Yonik Seeley Mark Miller any objections to changing the default setting from 256 to 65536? Thanks.

      Show
      Timothy Potter added a comment - Shalin Shekhar Mangar good point! I'm happy to make the default 65536 ... Yonik Seeley Mark Miller any objections to changing the default setting from 256 to 65536? Thanks.
      Hide
      Erick Erickson added a comment -

      Should we put the 65K bucket default into 5.2? I don't see a good reason not to.

      Show
      Erick Erickson added a comment - Should we put the 65K bucket default into 5.2? I don't see a good reason not to.
      Hide
      Yonik Seeley added a comment -

      I don't like that it's a band-aid around the real problem, but it's the best pseudo-workaround we currently have I guess (it's based on luck... we're just lowering the likelihood of a different thread hitting the blocked bucket).

      +1 for raising to 65536 for 5.2

      Show
      Yonik Seeley added a comment - I don't like that it's a band-aid around the real problem, but it's the best pseudo-workaround we currently have I guess (it's based on luck... we're just lowering the likelihood of a different thread hitting the blocked bucket). +1 for raising to 65536 for 5.2
      Hide
      ASF subversion and git services added a comment -

      Commit 1681169 from Timothy Potter in branch 'dev/trunk'
      [ https://svn.apache.org/r1681169 ]

      SOLR-6820: Increase the default number of buckets to 65536 instead of 256

      Show
      ASF subversion and git services added a comment - Commit 1681169 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1681169 ] SOLR-6820 : Increase the default number of buckets to 65536 instead of 256
      Hide
      ASF subversion and git services added a comment -

      Commit 1681171 from Timothy Potter in branch 'dev/branches/branch_5x'
      [ https://svn.apache.org/r1681171 ]

      SOLR-6820: Increase the default number of buckets to 65536 instead of 256

      Show
      ASF subversion and git services added a comment - Commit 1681171 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1681171 ] SOLR-6820 : Increase the default number of buckets to 65536 instead of 256
      Hide
      Timothy Potter added a comment - - edited

      This has been committed to 5.2 but I forgot to include the ticket # in the commit message for the 5.2 branch

      Commit on 5.2 branch was: revision 1681229.

      Show
      Timothy Potter added a comment - - edited This has been committed to 5.2 but I forgot to include the ticket # in the commit message for the 5.2 branch Commit on 5.2 branch was: revision 1681229.
      Hide
      Timothy Potter added a comment -

      Copy-and-paste error in the configset solrconfig.xml files, the int parameter is missing the name!

          <updateLog>
            <str name="dir">${solr.ulog.dir:}</str>
            <int name="">${solr.ulog.numVersionBuckets:65536}</int>
          </updateLog>
      

      but should be:

          <updateLog>
            <str name="dir">${solr.ulog.dir:}</str>
            <int name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int>
          </updateLog>
      

      It doesn't look like this causes any failures but looks bad.

      Show
      Timothy Potter added a comment - Copy-and-paste error in the configset solrconfig.xml files, the int parameter is missing the name! <updateLog> <str name= "dir" >${solr.ulog.dir:}</str> < int name="">${solr.ulog.numVersionBuckets:65536}</ int > </updateLog> but should be: <updateLog> <str name= "dir" >${solr.ulog.dir:}</str> < int name= "numVersionBuckets" >${solr.ulog.numVersionBuckets:65536}</ int > </updateLog> It doesn't look like this causes any failures but looks bad.
      Hide
      ASF subversion and git services added a comment -

      Commit 1682288 from Timothy Potter in branch 'dev/trunk'
      [ https://svn.apache.org/r1682288 ]

      SOLR-6820: fix numVersionBuckets name attribute in configsets

      Show
      ASF subversion and git services added a comment - Commit 1682288 from Timothy Potter in branch 'dev/trunk' [ https://svn.apache.org/r1682288 ] SOLR-6820 : fix numVersionBuckets name attribute in configsets
      Hide
      ASF subversion and git services added a comment -

      Commit 1682291 from Timothy Potter in branch 'dev/branches/branch_5x'
      [ https://svn.apache.org/r1682291 ]

      SOLR-6820: fix numVersionBuckets name attribute in configsets

      Show
      ASF subversion and git services added a comment - Commit 1682291 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1682291 ] SOLR-6820 : fix numVersionBuckets name attribute in configsets
      Hide
      ASF subversion and git services added a comment -

      Commit 1682293 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2'
      [ https://svn.apache.org/r1682293 ]

      SOLR-6820: fix numVersionBuckets name attribute in configsets

      Show
      ASF subversion and git services added a comment - Commit 1682293 from Timothy Potter in branch 'dev/branches/lucene_solr_5_2' [ https://svn.apache.org/r1682293 ] SOLR-6820 : fix numVersionBuckets name attribute in configsets
      Hide
      Timothy Potter added a comment -

      Fixed solrconfig.xmls - ready to go for 5.2

      Show
      Timothy Potter added a comment - Fixed solrconfig.xmls - ready to go for 5.2
      Hide
      Anshum Gupta added a comment -

      Bulk close for 5.2.0.

      Show
      Anshum Gupta added a comment - Bulk close for 5.2.0.

        People

        • Assignee:
          Timothy Potter
          Reporter:
          Mark Miller
        • Votes:
          0 Vote for this issue
          Watchers:
          11 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development