我有Elasticsearch v 2.2.0集群,1个节点,4g堆大小,7g RAM,2个cpu核心,401个索引,1,873个分片,107,780,287个文档,总数据70.19GB.
我也配置了indices.fielddata.cache.size:40%.
问题是当我使用Kibana查询某些东西(非常简单的查询)时,如果它只是单个查询它工作正常,但如果我继续查询更多 – 弹性变得如此缓慢并最终因为JVM堆而卡住用法(来自Marvel)达到87-95%.它也发生在我尝试加载一些Kibana仪表板时,这种情况的唯一解决方案是重新启动弹性服务or clear all cache.
堆为什么会这样?
编辑:
_node/stats when heap is stuck
_node/stats when cluster in normal state
编辑2:
为了更好地理解这个问题,我一直在分析内存转储.在群集卡住尝试一些Kibana查询后执行此分析:
在某些索引中,我确实有_ttl的设置无效(_ttl设置为4周,但文档仍在那里……).我从那以后更改了默认映射,但没有删除“not working ttl”索引.
这可能是主要问题吗?
最佳答案 我认为您现在没有其他选择,只能向群集添加更多节点,增加当前节点的硬件资源,或者不在群集中存储那么多索引.
对于这样一个小节点,你有很多分片,并且所有这些分片都使用一些内存(767MB)来处理常见的事情:条款,规范和分段元数据使用的整体内存:
"segments": {
"count": 14228,
"memory_in_bytes": 804235553,
"terms_memory_in_bytes": 747176621,
"stored_fields_memory_in_bytes": 31606496,
"term_vectors_memory_in_bytes": 0,
"norms_memory_in_bytes": 694880,
"doc_values_memory_in_bytes": 24757556,
"index_writer_memory_in_bytes": 0,
"index_writer_max_memory_in_bytes": 1381097464,
"version_map_memory_in_bytes": 39362,
"fixed_bit_set_memory_in_bytes": 0
}
你移动到ES 2.x这意味着你现在默认使用doc_values,而fielddata用法实际上非常小(11.8MB):
"fielddata": {
"memory_size_in_bytes": 12301920,
"evictions": 0
}
旧的过滤器缓存(现在称为查询缓存)也非常小:
"query_cache": {
"memory_size_in_bytes": 302888,
清除缓存(fielddata,查询缓存)我不太确定它会产生很大的不同.在收集统计信息时,堆使用率为2.88GB(72%),这不是那么高(JVM触发旧GC的75%).但是,对我而言,对于那么多碎片来说,这是一个太小的节点.
还有一件事需要注意,与内存问题无关:
"open_file_descriptors": 29461,
"max_file_descriptors": 65535,
有这么多打开的文件描述符,我强烈建议increase the OS limit for the count of open file descriptors.