官方一般是建议将操作系统一半分配给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内存划分到堆中是否合理呢？
这样做的好处是，操作系统会cache段文件，当有大量请求访问es时可以优先走page cache获取文档内容，效率会高于走磁盘访问，如果操作系统缓存不足，无法cache更多段文件，读请求missing到磁盘就会降低吞吐。
但是类似日志集群这种，写远大于读的场景，用户的查询需求并不高，不存在并发查询的需求，这种情况下是不是可以适当给堆多分配一些内存呢？目前使用官方建议一半JVM一半OS。因为集群数据量比较大，往往磁盘还很充足但是堆已经快满了（16G堆，老年代设置80% gc，高峰期经常半分钟不到就一次old gc）,而且要存储较多的日志就需要为term index 提供更多地空间，但此时实际上另一半OS的内存通过free -m 的cache这一列看到，高峰期最多不到12G，也就是说还有4G左右的空间是闲置的， 因此在这种场景下将这4G内存划分到堆中是否合理呢？
3 个回复
JackGe
赞同来自: qiuziyang_i
code4j - coder github: https://github.com/rpgmakervx
赞同来自:
zqc0512 - andy zhou
赞同来自:
试试业务不繁忙的时候 forceMerg segment.