Index.fielddata.cache 'soft' or 'resident'

Hi group,

I've an ES server (0.90.0) with 3.2G dedicated to the JAVA heap memory. I'd
like to utilize bulk of the memory equally for
indexing and searching (from web end- Kibana). In this situation what
should be the appropriate value for index.fielddata.cache?
Soft or resident?

Please advise as to how to decide this value.

PS: ES is a part of Logstash setup.

Thanks,
Subin

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

If you want all field data in the cache to be resident, including OOM
messages, choose 'resident' (which is the default).

If you want to let the JVM garbage collection decide about heap usage for
your cache values, choose 'soft'. The risk of OOM is low, but performance
will not be well, because cache rebuilding takes additional time.

Jörg

On Sun, Jul 28, 2013 at 1:01 PM, subin ksubins321@gmail.com wrote:

Hi group,

I've an ES server (0.90.0) with 3.2G dedicated to the JAVA heap memory.
I'd like to utilize bulk of the memory equally for
indexing and searching (from web end- Kibana). In this situation what
should be the appropriate value for index.fielddata.cache?
Soft or resident?

Please advise as to how to decide this value.

PS: ES is a part of Logstash setup.

Thanks,
Subin

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Just to add to what Jörg said, since you're using 0.90, you can limit the
fielddata cache size:

Which should prevent OOMs, and it should give you better performance than
having soft caches. The best way to know for sure is to test and monitor.

Best regards,
Radu

On Sun, Jul 28, 2013 at 3:48 PM, joergprante@gmail.com <
joergprante@gmail.com> wrote:

If you want all field data in the cache to be resident, including OOM
messages, choose 'resident' (which is the default).

If you want to let the JVM garbage collection decide about heap usage for
your cache values, choose 'soft'. The risk of OOM is low, but performance
will not be well, because cache rebuilding takes additional time.

Jörg

On Sun, Jul 28, 2013 at 1:01 PM, subin ksubins321@gmail.com wrote:

Hi group,

I've an ES server (0.90.0) with 3.2G dedicated to the JAVA heap memory.
I'd like to utilize bulk of the memory equally for
indexing and searching (from web end- Kibana). In this situation what
should be the appropriate value for index.fielddata.cache?
Soft or resident?

Please advise as to how to decide this value.

PS: ES is a part of Logstash setup.

Thanks,
Subin

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://sematext.com/ -- Elasticsearch -- Solr -- Lucene

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.