In case s1 will face the same problem, the thing was that SOLR caches were
turned off, and I underestimated the meaning of caches in desire to save as
much RAM as possible.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Simple-search-low-speed-tp4202135p4202975.html
Sent fr
Perhaps belated and IANA Solr expert, but take a look at mergeFactor and
ramBufferSizeMB. I've had a situation where after Solr upgrade old values
were kept. Those are used for buffering during indexing AFAIR. If buffer
size is exceeded, merge happens. If merge factor is exceeded, coalesced
segment
Try breaking down the query to see which part of it is slow. If it turns
out to be the range query you may want to look into using an frange
postfilter.
Joel Bernstein
http://joelsolr.blogspot.com/
On Fri, Apr 24, 2015 at 6:50 AM, Norgorn wrote:
> Thanks for your reply.
>
> Yes, 100% CPU is use
Thanks for your reply.
Yes, 100% CPU is used by SOLR (100% - I mean 1 core, not all cores), I'm
totally sure.
I have more than 80 GB RAM on test machine and about 50 is cached as disk
cache, SOLR uses about 8, Xmx=40G.
I use GC1, but it can't be the problem, cause memory usage is much lower
than
Java side:
- launch jvisualvm
- see how heap and CPU are occupied
What are your JVM settings (heap) and how much RAM do you have?
The CPU100% is used only by Solr? That is, are you 100% certain it's Solr
that drives CPU to it's limit?
pozdrawiam,
LAFK
2015-04-24 12:14 GMT+02:00 Norgorn :
> The
The number of documents in collection is about 100m.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Simple-search-low-speed-tp4202135p4202152.html
Sent from the Solr - User mailing list archive at Nabble.com.
