Re: SolrCloud indexing triggers merges and timeouts

2019-07-12 Thread Rahul Goswami
Upon further investigation on this issue, I see the below log lines during the indexing process: 2019-06-06 22:24:56.203 INFO (qtp1169794610-5652) [c:UM_IndexServer_MailArchiv_Spelle_66AC8340-4734-438A-9D1D-A84B659B1623 s:shard22 r:core_node87 x:UM_IndexServer_MailArchiv_Spelle_66AC8340-4734-438A

Re: SolrCloud indexing triggers merges and timeouts

2019-07-04 Thread Rahul Goswami
Shawn,Erick, Thank you for the explanation. The merge scheduler params make sense now. Thanks, Rahul On Wed, Jul 3, 2019 at 11:30 AM Erick Erickson wrote: > Two more tidbits to add to Shawn’s explanation: > > There are heuristics built in to ConcurrentMergeScheduler. > From the Javadocs: > * If

Re: SolrCloud indexing triggers merges and timeouts

2019-07-03 Thread Erick Erickson
Two more tidbits to add to Shawn’s explanation: There are heuristics built in to ConcurrentMergeScheduler. From the Javadocs: * If it's an SSD, * {@code maxThreadCount} is set to {@code max(1, min(4, cpuCoreCount/2))}, * otherwise 1. Note that detection only currently works on * Linux; other p

Re: SolrCloud indexing triggers merges and timeouts

2019-07-03 Thread Shawn Heisey
On 7/2/2019 10:53 PM, Rahul Goswami wrote: Hi Shawn, Thank you for the detailed suggestions. Although, I would like to understand the maxMergeCount and maxThreadCount params better. The documentation mention

Re: SolrCloud indexing triggers merges and timeouts

2019-07-02 Thread Rahul Goswami
Hi Shawn, Thank you for the detailed suggestions. Although, I would like to understand the maxMergeCount and maxThreadCount params better. The documentation mentions that maxMergeCount : The maximum number of

Re: SolrCloud indexing triggers merges and timeouts

2019-06-13 Thread Shawn Heisey
On 6/6/2019 9:00 AM, Rahul Goswami wrote: *OP Reply* : Total 48 GB per node... I couldn't see another software using a lot of memory. I am honestly not sure about the reason for change of directory factory to SimpleFSDirectoryFactory. But I was told that with mmap at one point we started to see t

Re: SolrCloud indexing triggers merges and timeouts

2019-06-12 Thread Rahul Goswami
Updating the thread with further findings: So turns out that the nodes hosting Solr are VMs with Virtual disks. Additionally, a Windows system process (the infamous PID 4) is hogging a lot of disk. This is indicated by disk reponse times in excess of 100 ms and a disk drive queue length of 5 which

Re: SolrCloud indexing triggers merges and timeouts

2019-06-06 Thread Rahul Goswami
Thank you for your responses. Please find additional details about the setup below: We are using Solr 7.2.1 > I have a solrcloud setup on Windows server with below config: > 3 nodes, > 24 shards with replication factor 2 > Each node hosts 16 cores. 16 CPU cores, or 16 Solr cores? The info may n

Re: SolrCloud indexing triggers merges and timeouts

2019-06-05 Thread Shawn Heisey
On 6/5/2019 9:39 AM, Rahul Goswami wrote: I have a solrcloud setup on Windows server with below config: 3 nodes, 24 shards with replication factor 2 Each node hosts 16 cores. 16 CPU cores, or 16 Solr cores? The info may not be all that useful either way, but just in case, it should be clarifi

Re: SolrCloud indexing triggers merges and timeouts

2019-06-05 Thread Walter Underwood
Yes, set Xmx and Xms the same. We run an 8 GB heap for all our clusters. Unless you are doing some really memory-intensive stuff like faceting, 8 GB should be fine. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Jun 5, 2019, at 1:05 PM, Gus Heck wr

Re: SolrCloud indexing triggers merges and timeouts

2019-06-05 Thread Gus Heck
Probably not a solution, but so.ething I notice off the bat... generally you want Xmx and Xms set to the same value so the jvm doesn't have to spend time asking for more and more memory, and also reduce the chance that the memory is not available by the time solr needs it. On Wed, Jun 5, 2019, 11: