Elasticsearch 和 Lucene 对内存使用情况:
![](http://img.e-com-net.com/image/info8/705ab52573ce4e03a3b8781d89cca8d9.jpg)
Elasticsearch 限制的内存大小是 JAVA 堆空间的大小,不包括Lucene 缓存倒排索引数据空间。
- 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的堆内存:
- 设置环境变量:
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
)