Finally found query causing claster crashes. After I commented code doing
this - claster is ok for few days. Before it it was crashing once day in
average.
Query looks like:
{
"sort": [
{
"user_last_contacted.ct": {
"nested_filter": {
It could be a number of things. Check your various ES caches. Full?
Correlated with GC activity increase and eventual OOM. Then check your
queries - are they big? Expensive aggregations? (the other day I saw one of
our clients using agg queries 10K lines in size) I could keep asking
questi
anyone?
Середа, 19 листопада 2014 р. 13:32:37 UTC+1 користувач Serg Fillipenko
написав:
>
> We have contact profiles (20+ fields, containing nested documents) indexed
> and their social profiles(10+ fields) indexed as child documents of contact
> profile.
> We run complex bool match queries, de
I have similar problems with Java Garbage Collection. In my case, gc
throughput is less than generated garbage from
In my opinion, best way is to generate less garbage. This is the largest
elasticsearch allocation problems:
1. using "_source" field to store document source inside elastic -
We have contact profiles (20+ fields, containing nested documents) indexed
and their social profiles(10+ fields) indexed as child documents of contact
profile.
We run complex bool match queries, delete by query, delete children by
query, faceting queries on contact profiles.
index rate 14.31op/s
What sort of data is it, what sort of queries are you running and how often
are they run?
On 19 November 2014 17:52, tetlika wrote:
> hi,
>
> we have 6 servers and 14 shards in cluster, the index size 26GB, we have 1
> replica so total size is 52GB, and ES v1.4.0, java version "1.7.0_65"
>
> we
hi,
we have 6 servers and 14 shards in cluster, the index size 26GB, we have 1
replica so total size is 52GB, and ES v1.4.0, java version "1.7.0_65"
we use servers with RAM of 14GB (m3.xlarge), and heap is set to 7GB
around week ago we started facing next issue:
random cluster servers around o
