Hi Shawn,
Yes, I've increased the heap size to 4GB already, and I'm using a machine
with 32GB RAM.
Is it recommended to further increase the heap size to like 8GB or 16GB?
Regards,
Edwin
On 23 Aug 2015 10:23, "Shawn Heisey" wrote:
> On 8/22/2015 7:31 PM, Zheng Lin Edwin Yeo wrote:
> > I'm usin
On 8/22/2015 3:50 PM, Yago Riveiro wrote:
> I'm using java 7u25 oracle version with Solr 4.6.1
>
> It work well with > 98% of throughput but in some full GC the issue arises. A
> full sync for one shard is more than 50G.
>
> There is any configuration to configurate the number of docs behind lea
On 8/22/2015 7:31 PM, Zheng Lin Edwin Yeo wrote:
> I'm using Solr 5.2.1, and I've indexed about 1GB of data into Solr.
>
> However, I find that clustering is exceeding slow after I index this 1GB of
> data. It took almost 30 seconds to return the cluster results when I set it
> to cluster the top
TrieDateFields can be null. Actually, just not in the document.
I just verified with 4.10
How are you indexing? I suspect that somehow the program that's sending
things to Solr is putting the default time in.
What version of Solr?
Best,
Erick
On Sat, Aug 22, 2015 at 4:04 PM, Henrique O. San
Hi,
I'm using Solr 5.2.1, and I've indexed about 1GB of data into Solr.
However, I find that clustering is exceeding slow after I index this 1GB of
data. It took almost 30 seconds to return the cluster results when I set it
to cluster the top 1000 records, and still take more than 3 seconds when
Hello,
Just a simple question. Can TrieDateField fields be null? I have a
schema with the following field and type:
docValues="true" />
positionIncrementGap="0"/>
Every time I index a document with no value for this field, the current
time gets indexed and stored. Is there anyway to m
I'm using java 7u25 oracle version with Solr 4.6.1
It work well with > 98% of throughput but in some full GC the issue arises. A
full sync for one shard is more than 50G.
There is any configuration to configurate the number of docs behind leader that
a replica can be?
On Sat, Aug 22, 201
On 8/22/2015 11:51 AM, Yago Riveiro wrote:
> My heap is about 24G an I tuned it using this link
> https://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr
>
> Shawn updated since I use it and some configuration are not in this document
> any more.
>
> I see on my GC logs pauses about 6s, my in
My heap is about 24G an I tuned it using this link
https://wiki.apache.org/solr/ShawnHeisey#GC_Tuning_for_Solr
Shawn updated since I use it and some configuration are not in this document
any more.
I see on my GC logs pauses about 6s, my index has a high index rate > 1000
docs/s.
I'm running jav
You can try to follow the suggestions at below link which had similar
issued and see if that helps.
http://lucene.472066.n3.nabble.com/ColrCloud-IOException-occured-when-talking-to-server-at-td4061831.html
Thnx
On Sat, Aug 22, 2015 at 9:05 AM, Yago Riveiro
wrote:
> Hi,
>
> Can anyone explain
M is the number of ids you want for each group, specified by group.limit.
It's unrelated to the number of rows requested..
On 21 Aug 2015 19:54, "SolrUser1543" wrote:
> Ramkumar R. Aiyengar wrote
> > Grouping does need 3 phases.. The phases are:
> >
> >
> > (2) For the N groups, each shard is ask
Using json facet api for nested faceting on the docValues.
Trying to improve the query time and I read in a blog that query time on
docValue can be improved with collapse & expand.
> On 22-Aug-2015, at 9:29 am, Joel Bernstein wrote:
>
> Can you explain your use case a little more?
>
>
>
Can you explain your use case a little more?
Joel Bernstein
http://joelsolr.blogspot.com/
On Fri, Aug 21, 2015 at 5:43 PM, Kiran Sai Veerubhotla
wrote:
> how can i use collapse & expand on the docValues with json facet api?
>
Hi,
Faceting is indeed the best way to do it.
Here is how it will look like in java:
SolrQuery query = new SolrQuery();
query.setQuery("id:" + docId);
query.setFacet(true);
query.addFacetField("text"); // You can add all fields you
want to inspect
query
Hi,
Can anyone explain me the possible causes of this warning?
too many updates received since start - startingUpdates no longer overlaps
with our currentUpdates
This warning triggers an full recovery for the shard that throw the warning.
-
Best regards
--
View this message in context:
h
15 matches
Mail list logo