Re: Fielddata cache sanity check

[Drew Town]

Mark,

Thanks for the idea of using doc values.  I added our @timestamp field to 
doc values and it has made a huge impact on reducing our field data cache 
size with only a pretty minimal impact on performance.  It has worked so 
well I may actually add some more commonly used fields to doc values.

Thanks,

Drew

On Thursday, March 19, 2015 at 11:45:26 AM UTC-5, Mark Walkom wrote:

 It's not really worth flushing things from cache based on time, 
 Elasticsearch uses LRU (last recently used) to clear things and it's best 
 to just let that handle it.

 Don't forget that allowing that much fielddata in your heap means there is 
 less for actual good things to happen, as the JVM cannot GC this data from 
 the heap. If you are seeing a lot of field data then you're probably better 
 off leveraging doc values.

 On 19 March 2015 at 06:08, Drew Town drew...@gmail.com javascript: 
 wrote:

 Can anybody comment on this?  Does this look ok?

 Thanks,

 Drew

 On Wednesday, March 11, 2015 at 3:02:56 PM UTC-5, Drew Town wrote:

 Hello all,

 Just want to make sure my field data settings are going to work in a way 
 that will protect my cluster from a bad query.

 elasticsearch.yml
 indices.fielddata.cache.size: 11GB


 get/_cluster/settings
 {
persistent: {
   indices: {
  cache: {
 filter: {
expire: 48h
 }
  },
  breaker: {
 total: {
limit: 15GB
 },
 fielddata: {
limit: 12GB
 }
  },
  fielddata: {
 breaker: {
limit: 80%
 }
  }
   }
}
 }

 Does everything look right here?  I tried to get rid of 
 indices.fielddata.breaker.limit but it just remains.

 Thanks!

  -- 
 You received this message because you are subscribed to the Google Groups 
 elasticsearch group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to elasticsearc...@googlegroups.com javascript:.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/elasticsearch/11d056b3-60e7-450b-b0ff-f4c95717ca7b%40googlegroups.com
  
 https://groups.google.com/d/msgid/elasticsearch/11d056b3-60e7-450b-b0ff-f4c95717ca7b%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/97ca2390-5944-4b9b-90cb-ddf595b46293%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fielddata cache sanity check

[Drew Town]

Can anybody comment on this?  Does this look ok?

Thanks,

Drew

On Wednesday, March 11, 2015 at 3:02:56 PM UTC-5, Drew Town wrote:

 Hello all,

 Just want to make sure my field data settings are going to work in a way 
 that will protect my cluster from a bad query.

 elasticsearch.yml
 indices.fielddata.cache.size: 11GB


 get/_cluster/settings
 {
persistent: {
   indices: {
  cache: {
 filter: {
expire: 48h
 }
  },
  breaker: {
 total: {
limit: 15GB
 },
 fielddata: {
limit: 12GB
 }
  },
  fielddata: {
 breaker: {
limit: 80%
 }
  }
   }
}
 }

 Does everything look right here?  I tried to get rid of 
 indices.fielddata.breaker.limit but it just remains.

 Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/11d056b3-60e7-450b-b0ff-f4c95717ca7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fielddata cache sanity check

[Drew Town]

Hello all,

Just want to make sure my field data settings are going to work in a way 
that will protect my cluster from a bad query.

elasticsearch.yml
indices.fielddata.cache.size: 11GB


get/_cluster/settings
{
   persistent: {
  indices: {
 cache: {
filter: {
   expire: 48h
}
 },
 breaker: {
total: {
   limit: 15GB
},
fielddata: {
   limit: 12GB
}
 },
 fielddata: {
breaker: {
   limit: 80%
}
 }
  }
   }
}

Does everything look right here?  I tried to get rid of 
indices.fielddata.breaker.limit but it just remains.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/4a2073f5-df80-46ed-abdb-7beca2681f2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kibanan 4 Terms Facets

[Drew Town]

A follow up with my results in case anyone runs into the same issue.

Facets are depreciated and aggs are what you should be using.  The reason 
we were seeing huge field data cache is because we were not using daily 
indices in Kibana.  Once we switched to a daily index we no longer saw the 
huge fielddata cache usage.

Drew

On Tuesday, February 17, 2015 at 8:42:07 AM UTC-6, Drew Town wrote:

 In Kibana 3 we heavily rely on terms panel.  This worked well because it 
 was fast and didn't fill up our field data cache.

 With Kibana 4 RC1 I haven't been able to find a way to do this.  The 
 horizontal bar chart seems to utilize a simple filtered query rather than a 
 facet query.  This is very slow compared to the facet query and takes up a 
 huge amount of heap memory.  Are there plans to add facet queries (terms 
 panels)?  Or is there a way to do this already that I am missing?

 Thanks


-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/959da9b6-4b97-4c14-bd7d-658c397475b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Http Cors Setting

[Drew Town]

Reza,

for me I had to set enabled to true and leave out the allow-origin as it 
defaults to * anyways.

On Tuesday, November 11, 2014 6:21:05 AM UTC-6, Reza Samee wrote:

 Hello to all!

 Note: I'm new to ELK :)

 I'm using elasticsearch 1.4.0 and I'm trying to enable http.cors feature 
 in elasticsearch. When I set http.cors.enabled: true and 
 http.cors.allow-origin: * in config file and then restart, the 
 http.cors feature doesn't enabled yet and I can't use kibana again. 
 What's wrong with my config file?

 elasticsearch.conf:

 http.cors.enabled: true
 http.cors.allow-origin: *



-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/c8b2ffcc-6819-4693-8256-06462375bef9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kibana 4 - filters in a dashboard

[Drew Town]

I believe it is not implemented yet 
(https://github.com/elasticsearch/kibana/issues/1526).  There are a number 
of missing features that are scheduled on the roadmap plus a ton of bugs 
still to be fixed.  It really is a beta 1

https://github.com/elasticsearch/kibana/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap



On Tuesday, November 11, 2014 1:55:43 AM UTC-6, Alex wrote:

 Dear Elasticsearch team,

 could you possibly please clarify a question regarding Kibana 4 vs 
 Kibana 3 Dashboard feature.

 In Kibana 3 Dashboard I was able to interact with widgets i.e drill-down 
 the data by clicking on basically any of the widgets to add more filters to 
 current dashboard.
 Does it suppose to work the same way in Kibana 4 as well? 

 It does not work for me at all now and I'm wondering is that's something 
 that I can not figure out how to do or is it something that's not 
 implemented yet.

 Thanks in advance,
 Alex.


-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/39d947f1-400c-49bd-a36f-55437770bc45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Elasticsearch server is down or unreachable

[Drew Town]

I got it to work by adding

http.cors.enabled: true

and leaving the allow-origin out and the allow-credentials out.  
allow-origin seems to default to anything if it is not present. cors is 
disabled by default.

Drew

On Monday, November 10, 2014 4:16:32 AM UTC-6, Prakash Dutta wrote:

 Hi

 I am also facing same issues. Read some where that elasticsearch in not 
 running but when I tried with the url : http://localhost:9200, it is 
 showing the below message

 {
   status : 200,
   name : Tzabaoth,
   cluster_name : elasticsearch,
   version : {
 number : 1.4.0,
 build_hash : bc94bd81298f81c656893ab1d30a99356066,
 build_timestamp : 2014-11-05T14:26:12Z,
 build_snapshot : false,
 lucene_version : 4.10.2
   },
   tagline : You Know, for Search
 }

 it means, elasticsearch is running. Added below two lines in elasticsearch.yml

 http.cors.allow-origin: /.*/
 http.cors.allow-credentials: true

 After doing all this steps also, facing same issues.

 Please suggest me the way to solve this.

 Thanks in advance to all.

 Regards
 Prakash






 On Thursday, October 30, 2014 2:51:12 AM UTC+5:30, versne...@gmail.com 
 wrote:

 Hello there,

 I keep getting this message when i start Kibana. But if i go look on my 
 server i see that elasticsearch is running perfectly 

 *root@server:~# service elasticsearch status*
 * * elasticsearch is running*





 *Connection FailedPossibility #1: Your elasticsearch server is down or 
 unreachableThis can be caused by a network outage, or a failure of the 
 Elasticsearch process. If you have recently run a query that required a 
 terms facet to be executed it is possible the process has run out of memory 
 and stopped. Be sure to check your Elasticsearch logs for any sign of 
 memory pressure.Possibility #2: You are running Elasticsearch 1.4 or 
 higherElasticsearch 1.4 ships with a security setting that prevents Kibana 
 from connecting. You will need to set http.cors.allow-origin in your 
 elasticsearch.yml to the correct protocol, hostname, and port (if not 80) 
 that your access Kibana from. Note that if you are running Kibana in a 
 sub-url, you should exclude the sub-url path and only include the protocol, 
 hostname and port. For example, http://mycompany.com:8080 
 http://mycompany.com:8080, not http://mycompany.com:8080/kibana 
 http://mycompany.com:8080/kibana.Click back, or the home button, when you 
 have resolved the connection issue*

 Plz some help



-- 
You received this message because you are subscribed to the Google Groups 
elasticsearch group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/304b326c-c16b-46d5-843e-eab083d7e2a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.