Re: ConcurrentMergeScheduler options not exposed

2016-06-17 Thread Michael McCandless
Really we need the infoStream output, to see what IW is doing, to take so long merging. Likely only one merge thread is running (CMS tries to detect if your IO system "spins" and if so, uses 1 merge thread) ... maybe try configuring this to something higher since your RAID array can probably

Re: ConcurrentMergeScheduler options not exposed

2016-06-16 Thread Shawn Heisey
On 6/16/2016 2:35 AM, Michael McCandless wrote: > > Hmm, merging can't read at 800 MB/sec and only write at 20 MB/sec for > very long ... unless there is a huge percentage of deletes. Also, by > default CMS doesn't throttle forced merges (see > CMS.get/setForceMergeMBPerSec). Maybe capture >

Re: ConcurrentMergeScheduler options not exposed

2016-06-16 Thread Michael McCandless
Hmm, merging can't read at 800 MB/sec and only write at 20 MB/sec for very long ... unless there is a huge percentage of deletes. Also, by default CMS doesn't throttle forced merges (see CMS.get/setForceMergeMBPerSec). Maybe capture IndexWriter.setInfoStream output? Mike McCandless

ConcurrentMergeScheduler options not exposed

2016-06-15 Thread Shawn Heisey
On the IRC channel, I ran into somebody who was having problems with optimizes on their Solr indexes taking a really long time. When investigating, they found that during the optimize, *reads* were happening on their SSD disk at over 800MB/s, but *writes* were proceeding at only 20 MB/s. Looking