Hi Shawn, Thanks for the help.
Now that you mention it..... Just after I sent the email I did start looking at top and I was seeing 100%, 200%, 300% CPU usage (and the VM only has 4 cores so I was looking at maxed out cores). I've grabbed screenshots now and I'm not seeing those high numbers but I've also grabbed a screenshot of the VM CPU usage (it's a VM in proxmox). I'm not sure how to understand the solr_gc.log file (but I'd like to) Latest SOLR gc log file: https://storage.snaplocal.co.uk/solr_debug/solr_gc_log.txt Top screen shot # 1: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.00.45.png Top screen shot # 2: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.00.55.png Top screen shot # 3: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.01.19.png Top screen shot # 4: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.01.35.png CPU Usage [max 1 hour] Proxmox: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.02.18.png CPU Usage [max 1 day] Proxmox: https://storage.snaplocal.co.uk/solr_debug/Top-Screenshot%202021-11-17%20at%2015.02.25.png Derek On Wed, Nov 17, 2021 at 2:44 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 11/17/21 7:05 AM, Derek C wrote: > > Hi all, > > > > I'm trying to get Near Real Time searching working with SOLR (so that > > documents I insert, or documents I update, are visible in a SOLR query as > > quickly as possible). > <snip> > > I have about 2.2 million documents in a SOLR core (quite a lot of fields > > too - maybe 40 and a lot are indexed=true as well). I'm using > > ClassicIndexSchemaFactory rather than ManagedIndexSchemaFactory. > > > > Right now I'm running on a single VM with 16Gbytes of memory and 12GB > given > > to SOLR (displayed as JVM-Memory on the Dashboard page - right now it's > > saying 74.3% / 8.92GB of 12.00GB in use). > <snip> > > <autoCommit> > > > > <maxDocs>100000000</maxDocs> > > <maxTime>86400000</maxTime> > > <openSearcher>false</openSearcher> > > </autoCommit> > > > > <autoSoftCommit> > > <maxTime>1000</maxTime> > > </autoSoftCommit> > > > The first thing I would change is autoCommit. Go with something like this: > > <autoCommit> > <maxTime>60000</maxTime> > <openSearcher>false</openSearcher> > </autoCommit> > > A value of 24 hours or 100 million documents might as well not be > configured at all. > > One second is FAR too aggressive for autoSoftCommit. Unless your index > is super tiny, which is not a description I would apply to 2.2 million > documents, a timeframe that low will tend to CAUSE problems. For it to > take 10 minutes is extremely odd, and probably indicates that there is a > very large performance problem with your setup. > > You did not indicate what version of Solr you have, or how large that > index is on disk. > > Can you gather a screenshot from the server, put it on a file sharing > site, and provide a URL for it? Sending it as an email attachment is > unlikely to succeed. This wiki page describes what I am looking for: > > > https://cwiki.apache.org/confluence/display/SOLR/SolrPerformanceProblems#SolrPerformanceProblems-Askingforhelponamemory/performanceissue > > It would also be useful for us to have solr.log and solr_gc.log covering > the time period from when you index a change to when the document > becomes visible. The whole unedited file, not an excerpt. > > Dropbox and gist are two good choices for sharing files. There are many > others. > > The fact that you have Solr in a VM means that if there are any > performance issues relating to the VM host, they could be translating > into problems for Solr. The possibilities for problems at the VM host > level are numerous. > > Thanks, > Shawn > > > -- -- Derek Conniffe Harvey Software Systems Ltd T/A HSSL Telephone (IRL): 086 856 3823 Telephone (US): (650) 443 8285 Skype: dconnrt Email: de...@hssl.ie *Disclaimer:* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please delete it (if you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited). *Warning*: Although HSSL have taken reasonable precautions to ensure no viruses are present in this email, HSSL cannot accept responsibility for any loss or damage arising from the use of this email or attachments. P For the Environment, please only print this email if necessary.
