ransportSearchTypeAction.java:216)
at
org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.performFirstPhase(TransportSearchTypeAction.java:203)
at
org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction$2.run(TransportSearchTypeAction.java:186)
at
Hi,
We have development test cluster 8 nodes running on 0.90.10 ES. Also we
have one monitoring node separated from dev cluster for marvel.
We installed all nodes to marvel latest /1.1.1/ pointing to monitoring
marvel IP in the ES config. Told the monitoring node not collect its data.
We
Yes we are using parent child relation in our indexes..
What I discovered tonight that *ID Cache Size: growing Gigabytes
(generally %10 percent of the shard size). I am clearing the cache while
opening the indexes repeatedly so I can manage the open all indexes with
in 30 Gb HEAP size. *
T
mment though.
>
> Regards,
> Mark Walkom
>
> Infrastructure Engineer
> Campaign Monitor
> email: ma...@campaignmonitor.com
> web: www.campaignmonitor.com
>
>
> On 26 December 2013 00:13, Prometheus WillSurvive <
> prometheus@gmail.com > wrote:
>
>&g
I forgot to mention ES version is 0.90.8
On Wednesday, December 25, 2013 3:13:12 PM UTC+2, Prometheus WillSurvive
wrote:
>
> Last couple of days I am looking the forums and the blogs regarding to
> find a help or clue about the Large indexes and the Heap usage similar to
>
Last couple of days I am looking the forums and the blogs regarding to find
a help or clue about the Large indexes and the Heap usage similar to the
our use case.
Unfortunatelly I didn’t find a solution that helps my case. Here the
setup:
We have two test server, each :
128 gig Ram
24 cor
