unsubscribe

On Tue, Mar 9, 2021 at 3:50 PM Sripradeep <sriprad...@madstreetden.com>
wrote:

> Unsubscribe
>
>
>
> On Tue, Mar 9, 2021 at 3:10 PM Ashique <ashique....@gmail.com> wrote:
>
> > Unsubscribe please
> >
> > On Tuesday, March 9, 2021, Shawn Heisey <apa...@elyograg.org> wrote:
> >
> > > On 3/8/2021 8:18 PM, Hitesh Khamesra wrote:
> > >
> > >> We are getting OutOfMemoryError, while concurrently deleting and
> > updating
> > >> the data. Looks like we don't have a thread pool to merge
> segment/index.
> > >> Is
> > >> it possible to control this behavior?
> > >>
> > >
> > > Here's the important part from that massive exception stacktrace:
> > >
> > > Caused by: java.lang.OutOfMemoryError: unable to create native thread:
> > >
> > > There are exactly two ways you can fix OOME.  One is to increase the
> > > resource that has been depleted, the other is to change things so that
> > > fewer resources are required.
> > >
> > > In this case you're running into an OS limit on the number of processes
> > > that a user is allowed to start.  The default setting for this limit on
> > all
> > > Linux distros I have seen is 1024.  It's pretty easy to have a Solr
> > > instance with significantly more than a thousand threads.  On most
> > > operating systems, threads are handled by the kernel as processes.
> Some
> > > have separate entities for threads, but that's not very common.
> > >
> > > So what you're going to have to do is increase the number of processes
> > > that the user which is running Solr is allowed to have.
> > >
> > > On most Linux distros this is usually done with the following file:
> > >
> > > /etc/security/limits.conf
> > >
> > > If you're running with a different OS, you'll need to research how to
> > > increase the limit.
> > >
> > > Thanks,
> > > Shawn
> > >
> >
>


-- 
Thanks and Regards
Abhay Kumar Singh

Reply via email to