Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAN4YXvd5Mg585b6CTLhPW00re7XkEFACj6bvuRnTTTWZzy3m2Q@mail.gmail.com>
References: 
 <CAAwEjvAbVfqKrB8TWdXG3YOmZJ5003d6s=V3e4pJudZO-twdxw@mail.gmail.com>
	<555D9907.5060506@elyograg.org>
	<CAAwEjvCHRO+sP8as7rtG81K2VL++BU1hoHBKYocAYh0veH_9-w@mail.gmail.com>
	<CAHcTSUKofRsDrEJBLA99hfmziijG55Z_MtgPHd4qNXs9aqdo9A@mail.gmail.com>
	<CAN4YXvd5Mg585b6CTLhPW00re7XkEFACj6bvuRnTTTWZzy3m2Q@mail.gmail.com>
Date: Fri, 22 May 2015 12:15:26 +0300
Message-ID: 
 <CAAwEjvBHdQHKGz6gTGkNOdG3hWzuGd=HgVZ1MrW6JudcZke=EQ@mail.gmail.com>
Subject: Re: Indexing gets significantly slower after every batch commit
From: Angel Todorov <attodorov@gmail.com>
To: solr-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=089e0160b87ccd6e2f0516a819cb

--089e0160b87ccd6e2f0516a819cb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback guys. What i am going to try now is deploying my
SOLR server on a physical machine with more RAM, and checking out this
scenario there. I have some suspicion it could well be a hypervisor issue,
but let's see. Just for the record - I've noticed those issues on a Win
2008R2 VM with 8 GB of RAM and 2 cores.

I don't see anything strange in the logs. One thing that I need to change,
though, is the verbosity of logs in the console - looks like by default
SOLR outputs text in the log for every single document that's indexed, as
well as for every query that's executed.

Angel


On Fri, May 22, 2015 at 1:03 AM, Erick Erickson <erickerickson@gmail.com>
wrote:

> bq: Which is logical as index growth and time needed to put something
> to it is log(n)
>
> Not really. Solr indexes to segments, each segment is a fully
> consistent "mini index".
> When a segment gets flushed to disk, a new one is started. Of course
> there'll be a
> _little bit_ of added overyead, but it shouldn't be all that noticeable.
>
> Furthermore, they're "append only". In the past, when I've indexed the
> Wiki example,
> my indexing speed actually goes faster.
>
> So on the surface this sounds very strange to me. Are you seeing
> anything at all in the
> Solr logs that's supsicious?
>
> Best,
> Erick
>
> On Thu, May 21, 2015 at 12:22 PM, Sergey Shvets <sergey@bintime.com>
> wrote:
> > Hi Angel
> >
> > We also noticed that kind of performance degrade in our workloads.
> >
> > Which is logical as index growth and time needed to put something to it
> is
> > log(n)
> >
> >
> >
> > =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 21 =D0=BC=D0=B0=D1=8F 2015 =
=D0=B3. =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=
=D1=8C Angel Todorov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> >
> >> hi Shawn,
> >>
> >> Thanks a bunch for your feedback. I've played with the heap size, but =
I
> >> don't see any improvement. Even if i index, say , a million docs, and
> the
> >> throughput is about 300 docs per sec, and then I shut down solr
> completely
> >> - after I start indexing again, the throughput is dropping below 300.
> >>
> >> I should probably experiment with sharding those documents to multiple
> SOLR
> >> cores - that should help, I guess. I am talking about something like
> this:
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data=
+in+SolrCloud
> >>
> >> Thanks,
> >> Angel
> >>
> >>
> >> On Thu, May 21, 2015 at 11:36 AM, Shawn Heisey <apache@elyograg.org
> >> <javascript:;>> wrote:
> >>
> >> > On 5/21/2015 2:07 AM, Angel Todorov wrote:
> >> > > I'm crawling a file system folder and indexing 10 million docs, an=
d
> I
> >> am
> >> > > adding them in batches of 5000, committing every 50 000 docs. The
> >> > problem I
> >> > > am facing is that after each commit, the documents per sec that ar=
e
> >> > indexed
> >> > > gets less and less.
> >> > >
> >> > > If I do not commit at all, I can index those docs very quickly, an=
d
> >> then
> >> > I
> >> > > commit once at the end, but once i start indexing docs _after_ tha=
t
> >> (for
> >> > > example new files get added to the folder), indexing is also slowi=
ng
> >> > down a
> >> > > lot.
> >> > >
> >> > > Is it normal that the SOLR indexing speed depends on the number of
> >> > > documents that are _already_ indexed? I think it shouldn't matter
> if i
> >> > > start from scratch or I index a document in a core that already ha=
s
> a
> >> > > couple of million docs. Looks like SOLR is either doing something
> in a
> >> > > linear fashion, or there is some magic config parameter that I am
> not
> >> > aware
> >> > > of.
> >> > >
> >> > > I've read all perf docs, and I've tried changing mergeFactor,
> >> > > autowarmCounts, and the buffer sizes - to no avail.
> >> > >
> >> > > I am using SOLR 5.1
> >> >
> >> > Have you changed the heap size?  If you use the bin/solr script to
> start
> >> > it and don't change the heap size with the -m option or another
> method,
> >> > Solr 5.1 runs with a default size of 512MB, which is *very* small.
> >> >
> >> > I bet you are running into problems with frequent and then ultimatel=
y
> >> > constant garbage collection, as Java attempts to free up enough memo=
ry
> >> > to allow the program to continue running.  If that is what is
> happening,
> >> > then eventually you will see an OutOfMemoryError exception.  The
> >> > solution is to increase the heap size.  I would probably start with =
at
> >> > least 4G for 10 million docs.
> >> >
> >> > Thanks,
> >> > Shawn
> >> >
> >> >
> >>
>

--089e0160b87ccd6e2f0516a819cb--