大数据集群JVM调优&内存管理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/bryce123phy/article/details/51711872

大数据集群的工作,很大一部分精力花在了调整集群的jvm参数上面。由于现在的开源大数据产品无论是hadoop、hbase、yarn还是spark等等,都运行于jvm环境中,因此而产生的垃圾收集问题是影响集群可用性的是工作中的重点。

本文首先归纳一些常见的因jvm垃圾收集导致的常见集群问题,这些归纳来自于平时工作的总结,欢迎和大家一起交流:

1、Namenode的堆内存配置过小导致频繁产生full GC导致namenode宕机,在hadoop中,数据的写入&读取经由namenode,所以namenode的jvm内存需要足够多,尤其是在出现大量数据流动的场景中。

      此外Hadoop集群中的文件数越多,Namenode的内存压力越大,可以通过archive归档命令定期合并一些目录以减少namenode的压力。hadoop不适于存储海量小文件的原因也在于此。

2、DataNode的内存可以相应调小。

3、NodeManager充当shuffle任务的server端,内存应该调大,否则会出现任务连接错误,日志Too Many fetch failures.Failing the attempt。

4、ResourceManager垃圾回收时间过长导致与zk的连接超时,出现active RM的频繁切换,此过程中会导致一些MR任务失败。

5、HRegionServer的堆内存配置过少,HBase的读写直接与RegionServer交换,Regionserver中预留了数据读写的缓存,入Memstore&blockCache等等,因此留给RegionServer的堆内存应足够其缓存数据库中的数据。

JVM的参数调整视应用环境、集群环境、业务背景的不同而不同,因此,很难统一出一个适用的标准,更多的是手艺活。下文,我们会列出各个jvm参数的含义,力求能够让大家一目了然所有参数的意义。至于具体的参数应该如何配置,视不同的需求而不同。

-Xmx:JVM最大允许分配的堆内存;

-Xms:JVM初始分配的堆内存(一般等于-Xmx);

-Xmn:JVM堆中年轻代的大小;

-Xss:每个线程都需要一定的栈空间,-Xss定义栈空间的大小;

-XX:StackYellowPages:线程栈尾部会预留两块受保护的内存区域,分别是yellow page和red page,此参数配置yellow page的大小。访问到此处的代码会抛出StackOverflowError异常;

-XX:StackRedPages:同上,red page的大小

-XX:+UseConcMarkSweepGC:该标志意味着激活CMS收集器;

-XX:UseParNewGC:一般与上述标志配合使用,激活年轻代使用多线程并行执行垃圾收集;

-XX:+CMSConcurrentMTEnbaled:启动该标志,并发的CMS阶段以多线程执行;

-XX:ConcGCThreads:定义了上述并发CMS过程运行时的线程数;

-XX:CMSInitiatingOccupancyFraction:JVM满了之后,会启动并行收集器开始full GC,此时JVM STW,为了尽量减少Full GC,需要在应用程序用完内存之间尽量使用CMS GC回收尽量多的空间,这个参数指定了CMS GC启动的时机,表示内存消耗达到此比例时开启CMS GC,默认68%。

-XX:+CMSClassUnloadingEnabled:设置此标志,开启永久代垃圾回收。

-XX:+CMSIncrementalMode:开启CMS收集器的增量模式,所谓增量模式是指CMS GC的过程中可以暂停,以对应用程序作出让步。很明显,开启此标志会延长CMS GC的时间。

-XX:+DisableExplicitGC:通知JVM忽略所有的系统GC调用;

-XX:+UseCompactAtFullCollection:由于在CMS的回收步骤中,不会对内存进行压缩,所以会有内存碎片出现,CMS提供了一个整理碎片的功能,通过此标志开启。默认为0,意味着每次GC结束后都会进行内存碎片整理。内存碎片会导致不可预知的full GC行为,因此该值建议取0。

-XX:+UseCompressedOops:压缩普通对象的指针,可用于压缩应用消耗的内存空间。需要注意的是:堆大于32G时,该标志会失效。

-XX:+CMSScavengeBeforeRemark:意思是在执行CMS remark之前进行一次youngGC,这样能有效降低remark的时间。

-XX:+SoftRefLRUPolicyMSPerMB:贴一下官方解释softly reachable objects will remain alive for some amount of time after the last time they were referenced.The default value is one second of lifetime per free megabyte in the heap,没有必要等1s,可以设置成0.

上面是一些常见的JVM参数,欢迎一起补充。


展开阅读全文

没有更多推荐了,返回首页