Thank you.
Regards, Moshe Recanati SVP Engineering Office + 972-73-2617564 Mobile + 972-52-6194481 Skype : recanati More at: www.kmslh.com | LinkedIn | FB -----Original Message----- From: Mikhail Khludnev [mailto:mkhlud...@griddynamics.com] Sent: Sunday, February 22, 2015 6:16 PM To: solr-user Subject: Re: FW: NRTCachingDirectory threads stuck On Sun, Feb 22, 2015 at 1:54 PM, Moshe Recanati <mos...@kmslh.com> wrote: > Hi Mikhail, > Thank you. > 1. Regarding jetty threads - How I can reduce them? > https://wiki.eclipse.org/Jetty/Howto/High_Load#Thread_Pool note, you'll get 503 or something when pool size is exceeded. > 2. Is it related to the fact we're running Solr 4.0 in parallel on > this machine? > are their index dirs different? Nevertheless, running something at same machine leads to resource contention. What does `top` say? > > Thank you > > > Regards, > Moshe Recanati > SVP Engineering > Office + 972-73-2617564 > Mobile + 972-52-6194481 > Skype : recanati > > More at: www.kmslh.com | LinkedIn | FB > > > -----Original Message----- > From: Mikhail Khludnev [mailto:mkhlud...@griddynamics.com] > Sent: Sunday, February 22, 2015 11:18 AM > To: solr-user > Subject: Re: FW: NRTCachingDirectory threads stuck > > Hello, > > I checked 20020.tdump. From the update perspective, it's ok, I see the > single thread committed and awaits for opening a searcher. There are a > few very bad evidences: > - there are many threads executing search requests in parallel. let;s > say it's roughly hundred of them. This is dead end. Consider to limit > number of jetty threads, start from number of cores available; > - heap is full, it's no-way for java. Either increase it, or reduce > load or make sure that there are no any leak; > - i see many threads executing Luke handler code, it might be really > wrong setup, or regular approach for Solr replication. I'm not sure here. > > > On Sun, Feb 22, 2015 at 9:57 AM, Moshe Recanati <mos...@kmslh.com> wrote: > > > Hi, > > > > I saw message rejected because of attachment. > > > > I uploaded data to drive > > > > > > https://drive.google.com/file/d/0B0GR0M-lL5QHVDNjZlUwVTR2QTQ/view?us > > p= > > sharing > > > > > > > > Moshe > > > > > > > > *From:* Moshe Recanati [mailto:mos...@kmslh.com] > > *Sent:* Sunday, February 22, 2015 8:37 AM > > *To:* solr-user@lucene.apache.org > > *Subject:* RE: NRTCachingDirectory threads stuck > > > > > > > > *From:* Moshe Recanati > > *Sent:* Sunday, February 22, 2015 8:34 AM > > *To:* solr-user@lucene.apache.org > > *Subject:* NRTCachingDirectory threads stuck > > > > > > > > Hi, > > > > We're running two Solr servers on same machine. > > > > Once Solr 4.0 and the second is Solr 4.7.1. > > > > In the Solr 4.7.1 we've very strange behavior, while indexing > > document we get spike of memory from 1GB to 4Gb in couple of minutes > > and huge number of threads stuck on > > > > NRTCachingDirectory.openInput methods. > > > > > > > > Thread sump and GC attached. > > > > > > > > Are you familiar with this behavior? What can be the trigger for this? > > > > > > > > Thank you, > > > > > > > > > > > > *Regards,* > > > > *Moshe Recanati* > > > > *SVP Engineering* > > > > Office + 972-73-2617564 > > > > Mobile + 972-52-6194481 > > > > Skype : recanati > > [image: KMS2] > > <http://finance.yahoo.com/news/kms-lighthouse-named-gartner-cool-121 > > 00 > > 0184.html> > > > > More at: www.kmslh.com | LinkedIn > > <http://www.linkedin.com/company/kms-lighthouse> | FB > > <https://www.facebook.com/pages/KMS-lighthouse/123774257810917> > > > > > > > > > > > > > > -- > Sincerely yours > Mikhail Khludnev > Principal Engineer, > Grid Dynamics > > <http://www.griddynamics.com> > <mkhlud...@griddynamics.com> > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
