Increasing the polling interval does help. But the requirement is to get a
document indexed and searchable instantly ( sounds like RTS), 30 sec is
acceptable.I need to look at Solr NRT and cloud.
I created a new core to accept daily updates and replicate every 10 sec.
Two other cores with 234 Mill
Replication will indeed be incremental. But if you commit too often (and
committing too often a common mistake) then the merging will
eventually merge everything into new segments and the whole thing will
be replicated.
Additionally, optimizing (or forceMerge in 4.x) will make a single segment
and
Hi Eric,
I totally agree. That's what I also figured ultimately. One thing I am not
clear. The replication is supposed to be incremental ? But looks like it
is trying to replicate the whole index. May be I am changing the index so
frequently, it is triggering auto merge and a full replication ?
bq: This index is only used for searching and being replicated every 7 sec from
the master.
This is a red-flag. 7 second replication times are likely forcing your
app to spend
all its time opening new searchers. Your cached filter queries are
likely rarely being re-used
because they're being throw
> FWIW, when asked at what point one would want to split JVMs and shard,
> on the same machine, Grant Ingersoll mentioned 16GB, and precisely for
> GC cost reasons. You're way above that.
- his index is 75G, and Grant mentioned RAM heap size; we can use terabytes
of index with 16Gb memory.
ou [mailto:[hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3995452&i=0>]
>
> > Sent: Monday, July 16, 2012 9:09 PM
> > To: [hidden email]<http://user/SendEmail.jtp?type=node&node=3995452&i=1>
> > Subject: Re: Using Solr 3.4 running on
sides
plausibility to the idea.
-- Bryan
> -Original Message-
> From: Mou [mailto:mouna...@gmail.com]
> Sent: Monday, July 16, 2012 9:09 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Using Solr 3.4 running on tomcat7 - very slow search
>
> Thanks Brian. Excellent sugg
Thanks Brian. Excellent suggestion.
I haven't used VisualVM before but I am going to use it to see where CPU is
going. I saw that CPU is overly used. I haven't seen so much CPU use in
testing.
Although I think GC is not a problem, splitting the jvm per shard would be
a good idea.
On Mon, Jul 16,
5 min is ridiculously long for a query that used to take 65ms. That ought
to be a great clue. The only two things I've seen that could cause that
are thrashing, or GC. Hard to see how it could be thrashing, given your
hardware, so I'd initially suspect GC.
Aim VisualVM at the JVM. It shows how muc
