关于elasticsearch内存分配策略的问题

作者 code4j | 发布于2018年09月16日 | 阅读数:200

官方一般是建议将操作系统一半分配给JVM,剩下留给linux page cache,而且JVM不要超过32G。
 
这样做的好处是,操作系统会cache段文件,当有大量请求访问es时可以优先走page cache获取文档内容,效率会高于走磁盘访问,如果操作系统缓存不足,无法cache更多段文件,读请求missing到磁盘就会降低吞吐。
 
但是类似日志集群这种,写远大于读的场景,用户的查询需求并不高,不存在并发查询的需求,这种情况下是不是可以适当给堆多分配一些内存呢?目前使用官方建议一半JVM一半OS。因为集群数据量比较大,往往磁盘还很充足但是堆已经快满了(16G堆,老年代设置80% gc,高峰期经常半分钟不到就一次old gc),而且要存储较多的日志就需要为term index 提供更多地空间,但此时实际上另一半OS的内存通过free -m 的cache这一列看到,高峰期最多不到12G,也就是说还有4G左右的空间是闲置的, 因此在这种场景下将这4G内存划分到堆中是否合理呢?
已邀请:

JackGe

赞同来自: qiuziyang_i

不同业务场景对rt要求不一样。线上app端业务的特点是读多写少且查询语句简单,jvm更倾向于小堆,rt一般在几ms到十几ms。后台分析类业务写入量和查询量相当但是查询语句比较复杂,会选择在一个物理机上起多个es进程,jvm大堆g1回收算法,rt一般在几百ms复杂聚合查询在秒级。日志检索类业务写多读少,机型选择方面磁盘也会选择较大磁盘的一般上TB,内存会先出现瓶颈。如果物理机内存多的话可以多起几个es节点。像您的情况,es的堆可以多分配些,但还是预留给操作系统自己本身一部分内存。到es存储索引目录看一下.tip文件有多大,使用GET _cat/nodes?v&h=name,ip,port,r,ramPercent,ramCurrent,heapMax,heapCurrent,fielddataMemory,queryCacheMemory,requestCacheMemory,segmentsMemory 来查看内存使用情况,重点看segmentsMemory,也可以从减少不必要的索引字段入手来减少内存使用。

code4j - coder

赞同来自:

思考了下cache这部分空间可以作为写缓冲并不直接落盘,而是写内存等待脏页刷新后才落地,实际上也能提升写性能,也不应该一味的拿走做它用。但是不分配给jvm多一点总感觉GC又有点压力,有没有朋友尝试过打破一半一半原则的呢?线上的还是想谨慎点

zqc0512 - andy zhou

赞同来自:

OLD GC我这里老是报的,试试G1GC,16G 添加内存吧。
试试业务不繁忙的时候 forceMerg segment.
 

要回复问题请先登录注册