Re: Fielddata cache sanity check
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
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
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
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
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
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
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.