Re: long QTime for big index

2013-02-14 Thread Mou
t; > > > > > > -Original Message- > From: Mou <[hidden email]> > To: solr-user <[hidden email]> > Sent: Thu, Feb 14, 2013 2:35 pm > Subject: Re: long QTime for big index > > > Just to close this discussion , we solved the problem by split

Re: long QTime for big index

2013-02-14 Thread alxsss
separate cores are the same as from one core? Thanks. Alex. -Original Message- From: Mou To: solr-user Sent: Thu, Feb 14, 2013 2:35 pm Subject: Re: long QTime for big index Just to close this discussion , we solved the problem by splitting the index. It turned out that

Re: long QTime for big index

2013-02-14 Thread Mou
this email, your message will be added to the discussion > below: > http://lucene.472066.n3.nabble.com/long-QTime-for-big-index-tp4037635p4037870.html > To unsubscribe from long QTime for big index, click here. > NAML -- View this message in context: http://lucene.472066.n3.nabble.c

Re: long QTime for big index

2013-01-31 Thread Mou
less than one sec . I am not sure yet, need to run solrmeter with different heap size , with cache and without cache etc. -- View this message in context: http://lucene.472066.n3.nabble.com/long-QTime-for-big-index-tp4037635p4037870.html Sent from the Solr - User mailing list archive at Nabble.com.

RE: long QTime for big index

2013-01-31 Thread Toke Eskildsen
Shawn Heisey [s...@elyograg.org] wrote: [...] > If you have a total index size for this JVM of 240GB, then you may not > have enough RAM to let the OS disk cache work efficiently. For that > size of index, I would plan on a system with at least 128GB of RAM, > 256GB would be better. [...] > On

Re: long QTime for big index

2013-01-31 Thread Shawn Heisey
On 1/31/2013 12:47 PM, Mou wrote: To clarify, the third shard is used to store the recently added/updated data. Two main big cores take very long to replicate ( when a full replication is required) so the third one helps us to return the newly indexed documents quickly. It gets deleted every hour

Re: long QTime for big index

2013-01-31 Thread Mou
into small pieces. -- View this message in context: http://lucene.472066.n3.nabble.com/long-QTime-for-big-index-tp4037635p4037781.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: long QTime for big index

2013-01-31 Thread Shawn Heisey
On 1/31/2013 1:01 AM, Mou wrote: I am running solr 3.4 on tomcat 7. Our index is very big , two cores each 120G. We are searching the slaves which are replicated every 30 min. I am using filtercache only and We have more than 90% cache hits. We use lot of filter queries, queries are usually pr

Re: long QTime for big index

2013-01-31 Thread Mou
Thanks for your reply. No, there is no eviction, yet. The time is spent mostly on org.apache.solr.handler.component.QueryComponent to process the request. Again, the time varies widely for same query. -- View this message in context: http://lucene.472066.n3.nabble.com/long-QTime-for-big

Re: long QTime for big index

2013-01-31 Thread Dmitry Kan
. We are > using Zing jvm which reduced our GC pause to milli secs, so GC is not a > problem. > > How can I improve the qtime? Is it at all possible to get a better qtime > given our index size? > > Thank you for your suggestion. > > > > -- > View this message in c

long QTime for big index

2013-01-31 Thread Mou
66.n3.nabble.com/long-QTime-for-big-index-tp4037635.html Sent from the Solr - User mailing list archive at Nabble.com.