Elasticsearch 和 Lucene 对内存使用状况：html
Elasticsearch 限制的内存大小是 JAVA 堆空间的大小，不包括Lucene 缓存倒排索引数据空间。
git
- Lucene 中的 倒排索引 segments 存储在文件中，为提升访问速度，都会把它加载到内存中，从而提升 Lucene 性能。因此建议至少留系统一半内存给Lucene。
- Node Query Cache (负责缓存f ilter 查询结果)，每一个节点有一个，被全部 shard 共享，filter query查询结果要么是 yes 要么是no，不涉及 scores 的计算。
集群中每一个节点都要配置，默认为：indices.queries.cache.size:10% - Indexing Buffer 索引缓冲区，用于存储新索引的文档，当其被填满时，缓冲区中的文档被写入磁盘中的 segments 中。节点上全部 shard 共享。
缓冲区默认大小：indices.memory.index_buffer_size: 10%
若是缓冲区大小设置了百分百则indices.memory.min_index_buffer_size用于这是最小值，默认为 48mb。indices.memory.max_index_buffer_size用于最大大小，无默认值。 - Shard Request Cache 用于缓存请求结果，但之缓存request size为0的。好比说 hits.total, aggregations 和 suggestions.
默认最大为indices.requests.cache.size:1% - Field Data Cache 字段缓存重要用于对字段进行排序、聚合是使用。由于构建字段数据缓存代价昂贵，因此建议有足够的内存来存储。
Fielddata 是 延迟 加载。若是你历来没有聚合一个分析字符串，就不会加载 fielddata 到内存中，也就不会使用大量的内存，因此能够考虑分配较小的heap给Elasticsearch。由于heap越小意味着Elasticsearch的GC会比较快，而且预留给Lucene的内存也会比较大。。
若是没有足够的内存保存fielddata时，Elastisearch会不断地从磁盘加载数据到内存，并剔除掉旧的内存数据。剔除操做会形成严重的磁盘I/O，而且引起大量的GC，会严重影响Elastisearch的性能。
Elasticsearch默认安装后设置的内存是1GB，这是远远不够用于生产环境的。
有两种方式修改Elasticsearch的堆内存：
github
- 设置环境变量：
export ES_HEAP_SIZE=10g在es启动时会读取该变量； - 启动时做为参数传递给es：
./bin/elasticsearch -Xmx10g -Xms10g
给es分配内存时要注意，至少要分配一半儿内存留给 Lucene。
分配给 es 的内存最好不要超过 32G ，由于若是堆大小小于 32 GB，JVM 能够利用指针压缩，这能够大大下降内存的使用：每一个指针 4 字节而不是 8 字节。若是大于32G 每一个指针占用 8字节，而且会占用更多的内存带宽，下降了cpu性能。
还有一点， 要关闭 swap 内存交换空间，禁用swapping。频繁的swapping 对服务器来讲是致命的。
总结：给es JVM栈的内存最好不要超过32G，留给Lucene的内存越大越好，Lucene把全部的segment都缓存起来，会加快全文检索。
缓存
参考文档：
https://nereuschen.github.io/2015/09/16/ElasticSearch内存使用分析/
https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
服务器