Do you really think running a profiler on 4.4 will be more effective than upgrading to 7.x?
wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Oct 28, 2018, at 8:53 PM, Erick Erickson <erickerick...@gmail.com> wrote: > > Put a profiler on it and see where the hot spots are? > On Sun, Oct 28, 2018 at 8:27 PM Walter Underwood <wun...@wunderwood.org> > wrote: >> >> Upgrade, so that indexing isn’t using as much CPU. That leaves more CPU for >> search. >> >> Make sure you are on a recent release of Java. Run the G1 collector. >> >> If you need more throughput, add more replicas or use instance with more >> CPUs. >> >> Has the index gotten bigger since the move? >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >>> On Oct 28, 2018, at 8:21 PM, Parag Shah <parags.li...@gmail.com> wrote: >>> >>> The original question though is about performance issue in the Searcher. >>> How would you improve that? >>> >>> On Sun, Oct 28, 2018 at 4:37 PM Walter Underwood <wun...@wunderwood.org> >>> wrote: >>> >>>> The original question is for a three-node Solr Cloud cluster with >>>> continuous updates. >>>> Optimize in this configuration won’t help, it will just cause expensive >>>> merges later. >>>> >>>> I would recommend updating from Solr 4.4. that is a very early release for >>>> Solr Cloud. We saw dramatic speedups in indexing with 6.x. In early >>>> releases, the >>>> replicas actually did more indexing work than the leader. >>>> >>>> wunder >>>> Walter Underwood >>>> wun...@wunderwood.org >>>> http://observer.wunderwood.org/ (my blog) >>>> >>>>> On Oct 28, 2018, at 2:13 PM, Erick Erickson <erickerick...@gmail.com> >>>> wrote: >>>>> >>>>> Well, if you optimize on the master you'll inevitably copy the entire >>>>> index to each of the slaves. Consuming that much network bandwidth can >>>>> be A Bad Thing. >>>>> >>>>> Here's the background for Walter's comment: >>>>> >>>> https://lucidworks.com/2017/10/13/segment-merging-deleted-documents-optimize-may-bad/ >>>>> >>>>> Solr 7.5 is much better about this: >>>>> >>>> https://lucidworks.com/2018/06/20/solr-and-optimizing-your-index-take-ii/ >>>>> >>>>> Even with the improvements in Solr 7.5, optimize is still a very >>>>> expensive operation and unless you've measured and can _prove_ it's >>>>> beneficial enough to be worth the cost you should avoid it. >>>>> >>>>> Best, >>>>> Erick >>>>> On Sun, Oct 28, 2018 at 1:51 PM Parag Shah <parags.li...@gmail.com> >>>> wrote: >>>>>> >>>>>> What would you do if your performance is degrading? >>>>>> >>>>>> I am not suggesting doing this for a serving index. Only one at the >>>> Master, >>>>>> which ones optimized gets replicated. Am I missing something here? >>>>>> >>>>>> On Sun, Oct 28, 2018 at 11:05 AM Walter Underwood < >>>> wun...@wunderwood.org> >>>>>> wrote: >>>>>> >>>>>>> Do not run optimize (force merge) unless you really understand the >>>>>>> downside. >>>>>>> >>>>>>> If you are continually adding and deleting documents, you really do not >>>>>>> want >>>>>>> to run optimize. >>>>>>> >>>>>>> wunder >>>>>>> Walter Underwood >>>>>>> wun...@wunderwood.org >>>>>>> http://observer.wunderwood.org/ (my blog) >>>>>>> >>>>>>>> On Oct 28, 2018, at 9:24 AM, Parag Shah <parags.li...@gmail.com> >>>> wrote: >>>>>>>> >>>>>>>> Hi Mugeesh, >>>>>>>> >>>>>>>> Have you tried optimizing indexes to see if performance improves? It >>>>>>> is >>>>>>>> well known that over time as indexing goes on lucene creates more >>>>>>> segments >>>>>>>> which will be searched over and hence take longer. Merging happens >>>>>>>> constantly but continuous indexing will still introduce smaller >>>> segments >>>>>>>> all the time. Have your tried running "optimize" periodically. Is it >>>>>>>> something that you can afford to run? If you have a Master-Slave setup >>>>>>> for >>>>>>>> Indexer v/s searchers, you can replicate on optimize in the Master, >>>>>>> thereby >>>>>>>> removing the optimize load on the searchers, but replicate to the >>>>>>> searcher >>>>>>>> periodically. That might help with reducing latency. Optimize merges >>>>>>>> segments and hence creates a more compact index that is faster to >>>> search. >>>>>>>> It may involve some higher latency temporarily right after the >>>>>>> replication, >>>>>>>> but will go away soon after in-memory caches are full. >>>>>>>> >>>>>>>> What is the search count/sec you are seeing? >>>>>>>> >>>>>>>> Regards >>>>>>>> Parag >>>>>>>> >>>>>>>> On Wed, Sep 26, 2018 at 2:02 AM Mugeesh Husain <muge...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We are running 3 node solr cloud(4.4) in our production >>>> infrastructure, >>>>>>> We >>>>>>>>> recently moved our SOLR server host softlayer to digital ocean server >>>>>>> with >>>>>>>>> same configuration as production. >>>>>>>>> >>>>>>>>> Now we are facing some slowness in the searcher when we index >>>> document, >>>>>>>>> when >>>>>>>>> we stop indexing then searches is fine, while adding document then it >>>>>>>>> become >>>>>>>>> slow. one of solr server we are indexing other 2 for searching the >>>>>>> request. >>>>>>>>> >>>>>>>>> >>>>>>>>> I am just wondering what was the reason searches become slow while >>>>>>> indexing >>>>>>>>> even we are using same configuration as we had in prod? >>>>>>>>> >>>>>>>>> at the time we are pushing 500 document at a time, this processing is >>>>>>>>> continuously running(adding & deleting) >>>>>>>>> >>>>>>>>> these are the indexing logs >>>>>>>>> >>>>>>>>> 65497339 [http-apr-8980-exec-45] INFO >>>>>>>>> org.apache.solr.update.processor.LogUpdateProcessor – [rn0] >>>>>>> webapp=/solr >>>>>>>>> path=/update >>>>>>>>> params={distrib.from= >>>>>>>>> >>>>>>> >>>> http://solrhost:8980/solr/rn0/&update.distrib=FROMLEADER&wt=javabin&version=2&update.chain=dedupe >>>>>>>>> } >>>>>>>>> {add=[E4751FCCE977BAC7 (1612655281518411776), 8E712AD1BE76AB63 >>>>>>>>> (1612655281527848960), 789AA5D0FB149A37 (1612655281538334720), >>>>>>>>> B4F3AA526506F6B7 (1612655281553014784), A9F29F556F6CD1C8 >>>>>>>>> (1612655281566646272), 8D15813305BF7417 (1612655281584472064), >>>>>>>>> DD13CFA12973E85B (1612655281596006400), 3C93BDBA5DFDE3B3 >>>>>>>>> (1612655281613832192), 96981A0785BFC9BF (1612655281625366528), >>>>>>>>> D1E52788A466E484 (1612655281636900864)]} 0 9 >>>>>>>>> 65497459 [http-apr-8980-exec-22] INFO >>>>>>>>> org.apache.solr.update.processor.LogUpdateProcessor – [rn0] >>>>>>> webapp=/solr >>>>>>>>> path=/update >>>>>>>>> params={distrib.from= >>>>>>>>> >>>>>>> >>>> http://solrhost:8980/solr/rn0/&update.distrib=FROMLEADER&wt=javabin&version=2&update.chain=dedupe >>>>>>>>> } >>>>>>>>> {add=[D8AA2E196967D241 (1612655281649483776), E73420772E3235B7 >>>>>>>>> (1612655281666260992), DFDCF1F8325A3EF6 (1612655281680941056), >>>>>>>>> 1B10EF90E7C3695F (1612655281689329664), 51CBD7F59644A718 >>>>>>>>> (1612655281699815424), 1D31EF403AF13E04 (1612655281714495488), >>>>>>>>> 68E1DC3A614B7269 (1612655281723932672), F9BF6A3CF89D74FB >>>>>>>>> (1612655281737564160), 419E017E1F360EB6 (1612655281749098496), >>>>>>>>> 50EF977E5E873065 (1612655281759584256)]} 0 9 >>>>>>>>> 65497572 [http-apr-8980-exec-40] INFO >>>>>>>>> org.apache.solr.update.processor.LogUpdateProcessor – [rn0] >>>>>>> webapp=/solr >>>>>>>>> path=/update >>>>>>>>> params={distrib.from= >>>>>>>>> >>>>>>> >>>> http://solrhost:8980/solr/rn0/&update.distrib=FROMLEADER&wt=javabin&version=2&update.chain=dedupe >>>>>>>>> } >>>>>>>>> {add=[B63AD0671A5E57B9 (1612655281772167168), 00B8A4CCFABFA1AC >>>>>>>>> (1612655281784750080), 9C89A1516C9166E6 (1612655281798381568), >>>>>>>>> 9322E17ECEAADE66 (1612655281803624448), C6DDB4BF8E94DE6B >>>>>>>>> (1612655281814110208), DAA49178A5E74285 (1612655281830887424), >>>>>>>>> 829C2AE38A3E78E4 (1612655281845567488), 4C7B19756D8E4208 >>>>>>>>> (1612655281859198976), BE0F7354DC30164C (1612655281869684736), >>>>>>>>> 59C4A764BB50B13B (1612655281880170496)]} 0 9 >>>>>>>>> 65497724 [http-apr-8980-exec-31] INFO >>>>>>>>> org.apache.solr.update.processor.LogUpdateProcessor – [rn0] >>>>>>> webapp=/solr >>>>>>>>> path=/update >>>>>>>>> params={distrib.from= >>>>>>>>> >>>>>>> >>>> http://solrhost:8980/solr/rn0/&update.distrib=FROMLEADER&wt=javabin&version=2&update.chain=dedupe >>>>>>>>> } >>>>>>>>> {add=[1F694F99367D7CE1 (1612655281895899136), 2AEAAF67A6893ABE >>>>>>>>> (1612655281911627776), 81E72DC36C7A9EBC (1612655281926307840), >>>>>>>>> AA71BD9B23548E6D (1612655281939939328), 359E8C4C6EC72AFA >>>>>>>>> (1612655281954619392), 7FEB6C65A3E23311 (1612655281972445184), >>>>>>>>> 9B5ED0BE7AFDD1D0 (1612655281991319552), 99FE8958F6ED8B91 >>>>>>>>> (1612655282009145344), 2BDC61DC4038E19F (1612655282023825408), >>>>>>>>> 5131AEC4B87FBFE9 (1612655282037456896)]} 0 10 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html >>>>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>
