This isn’t a support list, so nobody looks at issues. We do try to help. It looks like you have 1 TB of index on a system with 320 GB of RAM. I don’t know what "Shard1 Allocated memory” is, but maybe half of that RAM is used by JVMs or some other process, I guess. Are you running multiple huge JVMs?
The servers will be doing a LOT of disk IO, so look at the read and write iops. I expect that the solr processes are blocked on disk reads almost all the time. "-Dsolr.autoSoftCommit.maxTime=100” is way too short (100 ms). That is probably causing your outages. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Jul 7, 2020, at 5:18 AM, vishal patel <vishalpatel200...@outlook.com> > wrote: > > Any one is looking my issue? Please guide me. > > Regards, > Vishal Patel > > > ________________________________ > From: vishal patel <vishalpatel200...@outlook.com> > Sent: Monday, July 6, 2020 7:11 PM > To: solr-user@lucene.apache.org <solr-user@lucene.apache.org> > Subject: Replica goes into recovery mode in Solr 6.1.0 > > I am using Solr version 6.1.0, Java 8 version and G1GC on production. We have > 2 shards and each shard has 1 replica. We have 3 collection. > We do not use any cache and also disable in Solr config.xml. Search and > Update requests are coming frequently in our live platform. > > *Our commit configuration in solr.config are below > <autoCommit> > <maxTime>600000</maxTime> > <maxDocs>20000</maxDocs> > <openSearcher>false</openSearcher> > </autoCommit> > <autoSoftCommit> > <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> > </autoSoftCommit> > > *We used Near Real Time Searching So we did below configuration in solr.in.cmd > set SOLR_OPTS=%SOLR_OPTS% -Dsolr.autoSoftCommit.maxTime=100 > > *Our collections details are below: > > Collection Shard1 Shard1 Replica Shard2 Shard2 Replica > Number of Documents Size(GB) Number of Documents Size(GB) > Number of Documents Size(GB) Number of Documents Size(GB) > collection1 26913364 201 26913379 202 26913380 > 198 26913379 198 > collection2 13934360 310 13934367 310 13934368 > 219 13934367 219 > collection3 351539689 73.5 351540040 73.5 351540136 > 75.2 351539722 75.2 > > *My server configurations are below: > > Server1 Server2 > CPU Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz, 2301 Mhz, 10 Core(s), 20 > Logical Processor(s) Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz, 2301 > Mhz, 10 Core(s), 20 Logical Processor(s) > HardDisk(GB) 3845 ( 3.84 TB) 3485 GB (3.48 TB) > Total memory(GB) 320 320 > Shard1 Allocated memory(GB) 55 > Shard2 Replica Allocated memory(GB) 55 > Shard2 Allocated memory(GB) 55 > Shard1 Replica Allocated memory(GB) 55 > Other Applications Allocated Memory(GB) 60 22 > Other Number Of Applications 11 7 > > > Sometimes, any one replica goes into recovery mode. Why replica goes into > recovery? Due to heavy search OR heavy update/insert OR long GC pause time? > If any one of them then what should we do in configuration? > Should we increase the shard for recovery issue? > > Regards, > Vishal Patel >
