■河南 劉景云

某單位Hadoop平臺(tái)最近在運(yùn)行一個(gè)數(shù)據(jù)量很大的計(jì)算任務(wù)時(shí)，一些計(jì)算節(jié)點(diǎn)主機(jī)出現(xiàn)運(yùn)行異常故障，無法提供計(jì)算服務(wù)。

該Hadoop集群由30多個(gè)節(jié)點(diǎn)組成，可以提供HDFS分布式存儲(chǔ)和YARN分布式計(jì)算服務(wù)。節(jié)點(diǎn)主機(jī)配置了兩顆八核CPU以及64GB的內(nèi)存，硬件配置是沒有問題的，進(jìn)入Hadoop的日志目錄，執(zhí)行“more yarn-hadoopnodemanager-master.log”命令，查看NodeMagager的日志信息，發(fā)現(xiàn)“WARN org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.Container Launch：Failed to launch container.”“java.lang.OutOfMemoryError：GC overheadlimit exceeded”等警告信息。

故障排查

這些節(jié)點(diǎn)的操作系統(tǒng)為CentOS 7.X，采用的JDK為Oracle JDK 1.8版本，因?yàn)槌霈F(xiàn)故障的節(jié)點(diǎn)已經(jīng)無法為外界提供服務(wù)，所以Hadoop將其移出分布式計(jì)算集群，使其進(jìn)入黑名單中，執(zhí)行“jps”命令，發(fā)現(xiàn)NodeManager進(jìn)程消失了，這說明NodeManager服務(wù)已經(jīng)退出，這自然無法為外界提供計(jì)算服務(wù)。

所有的故障節(jié)點(diǎn)都是同樣的問題，當(dāng)出現(xiàn)內(nèi)存溢出后，NodeManager進(jìn)程自動(dòng)關(guān)閉，之后被HadoopHadoop放置到黑名單中。

要想處理此類故障，必須深入了解JVM內(nèi)存分配機(jī)制。對(duì)于Eden Space來說，當(dāng)對(duì)象被創(chuàng)建時(shí)會(huì)先被放入到該區(qū)域，進(jìn)行垃圾回收后，無法回收的對(duì)象會(huì)被放入空的Survivor Sapce。Eden Space和Survivior Space屬于新生代，在其中進(jìn)行垃圾回收的話，性能消耗較小。Old Gen主要用來存放新生代中經(jīng)過多次垃圾回收依然存活的對(duì)象。

當(dāng)Old Gen中堆滿不能收回的對(duì)象后，如果默認(rèn)堆空間使用率達(dá)到80%，Major GC會(huì)對(duì)整個(gè)堆進(jìn)行掃描和回收，其效能是很慢的。非堆內(nèi)存是Java虛擬機(jī)管理堆之外的內(nèi)存。對(duì)于JDK8來說，PermGen Space已被元空間MetaSpace取代，主要用來存放編譯器編譯后的代碼等數(shù)據(jù)。兩者最大的區(qū)別在于Metaspace并不存在于虛擬機(jī)中，使用的是本地內(nèi)存。Code Cache主要用來存放JIT所編譯的本地代碼。

JVM Stack描述的是Java方法執(zhí)行的內(nèi)存模型，當(dāng)Java虛擬機(jī)運(yùn)行程序程序時(shí)，每當(dāng)創(chuàng)建新的線程時(shí)，Java虛擬機(jī)都會(huì)分配一個(gè)虛擬機(jī)棧。Local Method Stack是為虛擬機(jī)使用到Native方法服務(wù)。整個(gè)堆內(nèi)存為新生代大小和老年代大小之和，JVM 初始分配的堆內(nèi)存默認(rèn)為物理內(nèi)存的1/64，最大分配的堆內(nèi)存默認(rèn)為物理內(nèi)存的1/4。當(dāng)默認(rèn)空閑內(nèi)存小于40%，JVM 就會(huì)增大堆直到最大內(nèi)存限制。如果默認(rèn)空閑堆內(nèi)存大于70%，JVM 就會(huì)減小堆直到最小內(nèi)存限制。

如果最大分配的堆內(nèi)存過大或過小，就很容易出現(xiàn)“Java.lang.OutOfMemory”的內(nèi)存溢出錯(cuò)誤。當(dāng)然，對(duì)于非堆內(nèi)存來說，如果最大非堆內(nèi)存設(shè)置過小，也會(huì)出現(xiàn)相同的故障，其默認(rèn)為物理內(nèi)存的1/4。根據(jù)以上分析，JVM 的內(nèi)存包含堆內(nèi)存和非堆內(nèi)存，JVM 的最大內(nèi)存取決于物理內(nèi)存和操作系統(tǒng)化的類型，如果在JVM 的參數(shù)設(shè)置中，初始分配的堆內(nèi)存大于最大分配的堆內(nèi)存，或永久代區(qū)初始值大于永久代區(qū)最大值，那么就會(huì)出現(xiàn)問題。如果堆內(nèi)存最大分配的堆內(nèi)存和永久代區(qū)最大值之和大于物理內(nèi)存的話，程序是無法啟動(dòng)的。

故障解決

對(duì)于本例中出現(xiàn)的“GC overheadlimit exceeded”錯(cuò)誤信息，其實(shí)說明了在垃圾回收上存在問題，即執(zhí)行垃圾回收的時(shí)間比例太大，而有效的運(yùn)算量太小。在默認(rèn)情況下，如果GC 花費(fèi)的時(shí)間超過98%，且GC 回收的內(nèi)存小于2%，就會(huì)引發(fā)該錯(cuò)誤。如果該錯(cuò)誤不出現(xiàn)，GC 回收的清理的內(nèi)存就會(huì)被再次填滿，GC 就會(huì)不斷的重復(fù)執(zhí)行，造成CPU 占用率過高。要想關(guān)閉該提示，可在JVM 參數(shù)配置文件中的“JAVA_OPTS=”行添加“-XX：-UseGCOverheadLimit”。

但是，這樣配置并不能有效解決內(nèi)存不足問題，當(dāng)經(jīng)過一段時(shí)間后，會(huì)出現(xiàn)“java.lang.OutOfMemoryError：Java heap space”的警告信息。打開YARN 的“yarnenv.sh”配置文件，在其中查看“YARN_NODEMANAGER_HEAPSIZE”參數(shù)，該參數(shù)的作用是JVM 運(yùn)行的堆內(nèi)存參數(shù)的，其默認(rèn)值為1000MB，可以使用的堆內(nèi)存為1000MB，但是此處卻沒有配置。這就說明JVM 使用了默認(rèn)的堆內(nèi)存配置信息，但默認(rèn)的堆內(nèi)存是比較小的，只能應(yīng)對(duì)數(shù)據(jù)量較小的計(jì)算場(chǎng)景，如果處理巨量的數(shù)據(jù)的話，就顯得不足了。

該問題毫無疑問是因?yàn)閿?shù)據(jù)量過大導(dǎo)致的內(nèi)存溢出。當(dāng)某個(gè)計(jì)算節(jié)點(diǎn)上的NodeManager 失效，Hadoop 會(huì)自動(dòng)請(qǐng)求下一個(gè)NodeManager節(jié)點(diǎn)，該節(jié)點(diǎn)也會(huì)因堆內(nèi)存不夠自動(dòng)關(guān)閉。按照這樣的順序，很可能會(huì)導(dǎo)致整個(gè)Hadoop集群徹底無法正常運(yùn)作。

根據(jù)以上分析，在默認(rèn)情況下，每個(gè)NodeManager 節(jié)點(diǎn)只能得到大約1GB 的堆內(nèi)存，這應(yīng)對(duì)一般的計(jì)算還可以，如果面對(duì)巨量的運(yùn)算場(chǎng)景肯定會(huì)出現(xiàn)問題。

解決方法只能給JVM 增加堆內(nèi)存。在上述“yarn-env.sh”配置文件中添加“export YARN_NODEMANAGER_OPTS="-Xms4096m -Xmx4096m"”行，其中的“-Xms”指的是JVM 的初始分配堆內(nèi)存值，“-Xmx”參數(shù)值的是JVM 的最大分配堆內(nèi)存值，這里將其均設(shè)為4096MB。在所有的NodeManager 節(jié)點(diǎn)上都進(jìn)行這樣的配置操作。執(zhí)行“bin/yarn-daemons.sh start nodemanager”之類的命令，重啟NodeManager 服務(wù)，讓Hadoop 集群恢復(fù)正常運(yùn)作。當(dāng)然，除了增加最大堆內(nèi)存，還可以從Job 任務(wù)代碼等方面進(jìn)行優(yōu)化，來有效的避免上述問題。