Hi Deepak, We actually tried with 128 GB machine, Didn't help in response time. So we moved back to 96GB.
On Tue, Aug 3, 2021 at 2:11 PM Deepak Goel <deic...@gmail.com> wrote: > I am confused a bit about the maths: > > Heap-30 GB & Index Size-95 GB is equal to 125GB. And the RAM is 96GB. > > > > > Deepak > "The greatness of a nation can be judged by the way its animals are treated > - Mahatma Gandhi" > > +91 73500 12833 > deic...@gmail.com > > Facebook: https://www.facebook.com/deicool > LinkedIn: www.linkedin.com/in/deicool > > "Plant a Tree, Go Green" > > Make In India : http://www.makeinindia.com/home > > > On Tue, Aug 3, 2021 at 12:10 PM Satya Nand <satya.n...@indiamart.com > .invalid> > wrote: > > > Hi, > > > > We have recently upgraded solr from version 6.5 to version 8.7. But > > opposite to our expectations, the response time increased by 40 %. > > > > On solr 8.7 the difference between optimized and unoptimized index is > also > > very huge. 350 ms on optimized and 650 ms on unoptimized. The difference > is > > only 5 GB in size in cores of optimized and unoptimized. The segment > count > > in the optimized index is 1 and 20 in the unoptimized index. > > > > I wanted to ask, Is this normal behavior on solr 8.7, or was there some > > setting that we forgot to add? Pleas also tell us how can we reduce the > > response time in unoptimzed core. > > > > *Specifications* > > We are using master slave architecture, Polling interval is 3 hours > > RAM- 96 GB > > CPU-14 > > Heap-30 GB > > Index Size-95 GB > > Segments size-20 > > Merge Policy : > > > > <mergePolicyFactory > class="org.apache.solr.index.TieredMergePolicyFactory"> > > <int name="maxMergeAtOnce">5</int> <int name="segmentsPerTier">3</int> </ > > mergePolicyFactory> > > > > -- > > > > > --
