ElasticSearch中的JVM性能调优
ElasticSearch6.3.2 中的JVM性能调优
前⼀段时间被⼈问了个问题：在使⽤ES的过程中有没有做过什么JVM调优措施？
在我搭建ES集过程中，参照官⽅⽂档来的，并没有对JVM参数做过多的调整。但谈到JVM配置参数，少不了操作系统层⾯上的⼀些配置参数，⽐如 page cache 和⽂件描述符的个数：(/etc/f)。另外ES jvm.options配置⽂件也针对JVM参数做了⼀些优化，这⾥简要介绍⼀下ElasticSearch中与jvm相关的各个配置参数：
将 Xms 和 Xmx 设置成⼀样⼤避免JVM堆的动态调整给应⽤进程带来"不稳定"。参考：
By default, the JVM grows or shrinks the heap at each GC to try to keep the proportion of free space to the living objects at
each collection within a specific range. This range is set as a percentage by the parameters -
XX:MinHeapFreeRatio=minimum and -XX:MaxHeapFreeRatio=maximum; and the total size bounded by -Xms and -Xmx 预留⾜够的内存空间给page cache。假设⼀台32GB内存的机器，配置16GB内存给ES进程使⽤，另外16GB给page cache，⽽不是将xmx 设置成32GB。
禁⽤内存交换(/proc/sys/vm/swappiness)，后⾯解释为什么要禁⽤内存交换？
配置JVM参数：-XX:+AlwaysPreTouch 减少新⽣代晋升到⽼年代时停顿。JDK官⽅⽂档关于 AlwaysPreTouch 的解释是：Pre-touch the Java heap during JVM initialization. Every page of the heap is thus demand-zeroed during initialization rather than incrementally during application execution.
也就是说：在启动时就把参数⾥说好了的内存全部都分配了，会使得启动慢上⼀点，但后⾯访问时会更流畅，⽐如页⾯会连续分配，⽐如不会在晋升新⽣代到⽼⽣代时才去访问页⾯，。
既然提到了这个参数，我想说⼀下Linux内存分配、Linux OOM Killer、内存交换vm.swappiness参数之间的⼀些理解：当ES进程向操作系统MMU申请分配内存时，操作系统内核分配的是虚拟内存，⽐如指定 -Xms=16G 那么只是告诉内核这个ES进程在启动的时候最需要16G内存，但是ES进程在启动后并不是⽴即就⽤了16G的内存。因此，随着ES的运⾏，ES进程访问虚拟内存时产⽣缺页错误(page fault)，然后内核为之分配实际的物理页⾯（这个过程也是需要开销的）。⽽如果在JVM启动时指定了AlwaysPreTouch，就会分配实际的物理内存，这样在发⽣YGC的时候，新⽣代对象晋升到⽼年代，减少⽼年代空间分配产⽣的缺页异常，从⽽减少YGC停顿时间。
正是由于Linux内存管理机制，应⽤程序进程可以申请⽐物理内存⼤得多的内存，⽽进程⽽⾔，它看到的是逻辑地址空间，因为通过内存交换(vm.swapiness)，操作系统允许将那些长期不⽤的物理页⾯交换到
磁盘上去，因此程序能够申请的内存空间范围是很⼤的。由于进程可以申请到⼀块很⼤的地址空间，但不⼀定把这些空间都使⽤了。但万⼀进程真的实实在在地占⽤了这么多空间，怎么办？于是OOM Killer 就出马了，。
在使⽤CMS垃圾回收器时，jmap -heap 查看jvm实际为ES进程分配的新⽣代的⼤⼩。因为，影响新⽣代⼤⼩的参数有三个：第⼀个是：-XX:NewSize和-XX:MaxNewSize、第⼆个是：-Xmn、第三个是：-XX:NewRatio=2。根据参数XX:NewRatio=2 ，ES 进程 jvm新⽣代堆⼤⼩占配置的总的堆的1/3，但其实并没有，就是因为参数：-XX:NewSize和-XX:MaxNewSize 优先级⽐XX:NewRatio=2⾼，覆盖了这个参数配置的值。
-XX:CMSInitiatingOccupancyFraction 设置成75%。主要是因为CMS是并发收集，垃圾回收线程和⽤户线程同时运⾏，⽤户线程运⾏时可能继续⽆⽤的垃圾对象，如果到90%再去回收就太晚了。⽼年代使⽤到75%就回收可减少OOM异常发⽣的概率。
-XX:MaxTenuringThreshold 设置成6。这个值默认为15，即Survivor区对象经历15次Young GC后才进⼊⽼年代，设置成6就只需6次YGC就晋升到⽼年代了。默认情况下ES新⽣代采⽤ -XX:+UseParNewGC，⽼年代采⽤CMS垃圾回收器，关于这个参数的调优说明，可参考：
Young GC是最⼤的应⽤停顿来源，⽽新⽣代⾥GC后存活对象的多少⼜直接影响停顿的时间，所以如果
清楚Young GC的
执⾏频率和应⽤⾥⼤部分临时对象的最长⽣命周期，可以把它设的更短⼀点，让其实不是临时对象的新⽣代对象赶紧晋升
到年⽼代
-Xss 配置为1M。线程占⽤栈内存，默认每条线程为1M。从这个参数可看出⼀个进程下可创建的线程数量是有限制的，可视为创建线程的开销。
page cache 与应⽤程序内存
Linux内存可分成2种类型：Page cache和应⽤程序内存。应⽤程序内存会被Linux的swap机制交换出去，⽽page cache则是由Linux后台的异步flush策略刷盘。当OS内存满了时，就需要把⼀部分内存数据写⼊磁盘，因此就需要决定是swap应⽤程序内存呢？还是清理page cache？OS有个系统参数/proc/sys/vm/swappiness默认值60，⼀般将之设置成0，表⽰优先刷新page cache⽽不是将应⽤程序的内存交换出去。
那Linux的page cache的清除策略是什么呢？--优化了的LRU算法。LRU存在缺点：那些新读取的但却只使⽤⼀次的数据占满了LRU列表，反⽽把热点数据给evict 到磁盘上去了，因此还需要考虑数据的访问次
数(频率)
很多存储系统针对LRU做了⼀些优化，⽐如Redis的键过期策略是基于LRU算法的思想，⽤若⼲个位记录每个key的idle time（空闲时间），将空闲时间较⼤的key存⼊pool，从pool中选择key evict出去，具体可参考：。再⽐如Mysql innodb 缓冲池管理page也是基于LRU，当新读
⼊⼀页数据时不是⽴即放到LRU链表头，⽽是设置mid point(默认37%)，即放到链表37%位置处。关于如何理解page cache 与应⽤程序内存之间的区别，可参考这篇⽂章：
Linux总会把系统中还没被应⽤使⽤的内存挪来给Page Cache，在命令⾏输⼊free，或者cat /proc/meminfo，"Cached"的部分就是Page Cache。
当Linux系统内存不⾜时，要么就回收page cache，要么就内存交换(swap)，⽽内存交换就有可能把应⽤程序的数据换出到磁盘上去了，这就有可能造成应⽤的长时间停顿了。参考：
Linux有个很怪的癖好，当内存不⾜时，有很⼤机率不是把⽤作IO缓存的Page Cache收回，⽽是把冷的应⽤内存page out到磁盘上。当这段内存重新要被访问时，再把它重新page in回内存（所谓的主缺页错误），这个过程进程是停顿的。增长缓慢的⽼⽣代，池化的堆外内存，都可能被认为是冷内存，⽤ cat /proc/[pid]/status 看看 VmSwap的⼤⼩，再dstat⾥看看监控page in发⽣的时间。
Linux free 内存参数
free -m 查看机器的内存使⽤情况时，其实⼀直被以下⼏个概念所困扰。Google了⼀圈，⼤部分只是"翻译"，没有解释。其实我是想了解这些参数对系统的影响是什么？
man free 查看注释如下，free 命令输出的内容其实就是 /proc/meminfo 中的内容，因此真正的是要理解 /proc/meminfo 中每⼀⾏的内容。free displays the total amount of free and used physical and swap memory in the system, as well as the buffers and caches used by the kerneljvm调优参数
1. 如何理解操作系统的交换内存？
2. 命令输出的 free 和 available 之间的区别是什么？free表⽰：Unused memory (MemFree and SwapFree in /proc/meminfo)。⽽
available ⼀般都⽐free字段数值⼤，这是因为：available 还包含了那些已经被使⽤但是可以被回收的内存。
⼀个JVM长时间停顿的⽰例
随着系统的运⾏，JVM堆内存会被使⽤，引⽤不可达对象就是垃圾对象，⽽操作系统有可能会把这些垃圾对象（长期未⽤的物理页⾯）交换到磁盘上去。当JVM堆使⽤到⼀定程度时，触发FullGC，FullGC过程中发现这些未引⽤的对象都被交换到磁盘上去了，于是JVM垃圾回收进程得把它们重新读回来到内存中，然⽽戏剧性的是：这些未引⽤的对象本⾝就是垃圾，读到内存中的⽬的是回收被丢弃它们！⽽这种来回读取磁盘的操作导致了FullGC 消耗了⼤量时间，(有可能)发⽣长时间的stop the world。因此，需要禁⽤内存交换以避免这种现象，这也是为什么在部署Kafka和ES的机器上都应该要禁⽤内存交换的原因吧(如果因长时间STW导致node与master之间的"⼼跳包"失效，集的master 节点认为该节点发⽣了故障，于是是⾃动进⾏failover，对于ES来说可能就发⽣⾃动rebalance分⽚迁移)。具体可参考这篇⽂章：
总结
本⽂以ES使⽤的JVM配置参数为⽰例，记录了⼀些关于JVM调优的参数理解，以及涉及到的⼀些关于page cache、应⽤程序内存区
别，LRU算法思想等，它们在Mysql、Kafka、ElasticSearch都有所应⽤。⽂中所引⽤的参考链接都⾮常好，对深⼊理解系统底层运⾏原理有帮助。
ElasticSearch官⽅⽂档HowTo也给出了ElasticSearch搜索、索引(Indexing)的调优⽅案，也值得⼀看：
⼀个统计gc⽇志的⼯具：gcplot，以图形化⽅式显⽰gc情况。（分析⼀个ES进程的gc⽇志得到：99%的gc STW 时间控制在77ms以内）
原⽂：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。