Try to update with Latest version of solrcloud.

Note: There are massive changes.

On Wed, 4 May 2022 at 07:08, Shawn Heisey <apa...@elyograg.org> wrote:

> On 5/3/2022 5:01 PM, Vincenzo D'Amore wrote:
> > I'm tuning a solrcloud 5.4.1 deployment (3 nodes, 12 cores each, 18GB
> ram)
> > that is experiencing frequent OutOfMemoryError (20 a day in total)
> > exceptions during the execution of a group query.
> >
> > Looking at query group.limit=1 but the rows range between 1000 and 10000.
> > I'm analyzing the solr query, and I've added a few JVM parameters to dump
> > the active threads and the allocated memory to better analyze the OOM.
> > But I was curious to ask in your experience how I should be preoccupied
> by
> > the OOM(s).
> > In other words, I'm working to remove them ASAP, but when an OOM happens
> > the Solr behaviour is completely compromised or Solr returns seamlessly
> to
> > work normally?
>
> As others have said, Java program state when OOME occurs is completely
> unpredictable.  For Solr, anything could happen, including index
> corruption.
>
> This is why when Solr is started via the bin/solr shell script, it is
> started with a java parameter that will cause it to commit suicide
> whenever OOME occurs.  This functionality has not yet been implemented
> on Windows.  Starting in 9.0, because the minimum Java version will be
> 11, I think we can alter the way that works so equivalent functionality
> will exist on Windows.
>
> Solr does NOT come with anything that will restart after OOME ...
> because chances are that if you encounter OOME once, it will continue to
> happen until you fix the problem.  Anything that anyone has which
> restarts Solr automatically is something they implemented -- Solr will
> not do this out of the box.  I don't recommend implementing anything
> like that.  Solr normally does NOT crash.  If it does crash, there is
> usually something VERY wrong that needs to be fixed.
>
> There are precisely two ways to deal with OOME.  One is to increase the
> available amount of the resource that has been depleted, which might not
> actually be memory.  The other is to change things so less of that
> resource is required -- reduce the index size, modify queries, etc.
>
> Thanks,
> Shawn
>
>

Reply via email to