最近又刷了一遍1988，感觉正焕错过德善，其实只是没有那么喜欢罢了。
言归正传，自建的CDH测试集群在运行任务时，HDFS中的nameNode/dataNode,Yarn ResourceManager和NodeManager中的经常出现不良现象。
请教了首席运维，产线上是否经常会有类似问题，首席运维说出现个几次就可以提离职了。
去看了角色日志，基本没什么报错和异常，难道是钞能力不够？
将主节点升级到16G，各组件的堆栈升到原来2~3倍，问题得到缓解，基本能支撑一周时间，但没过多久又开始报同样的问题。
并且host monitor资源界面的确显示集群以较低的资源运行。甚至开始怀疑阿里云为了节约成本是不是在坑散户？但这种可能性非常小。
直到上周，把nameNode日志级别调成了debug，发现日志开始暴涨，并每十秒出现以下的java异常。
03.09.2022 16:33:14 org.apache.catalina.core.ApplicationContext log INFO: JMXProxy: Error getting attribute java.lang:type=MemoryPool,name=PS Eden Space UsageThresholdExceeded javax.management.RuntimeMBeanException: java.lang.UnsupportedOperationException: Usage threshold is not supported
这就是CDH一个坑爹的地方了，明明是Error，还非要debug打开才能看到，咋想的。
谷歌之后，发现一个隐秘的角落提到：
You use the isUsageThresholdSupported() method to determine whether a memory pool supports a usage threshold, since a usage threshold is not appropriate for some memory pools. For example, in a generational garbage collector (such as the one in the HotSpot VM;
就是说，某些java 内存池不支持标准jmx中isUsageThresholdSupported的方法？难道是我当初装的jdk是个PDD版JDK？
看了一下，jdk不是PDD版，但是是一开始由于某种原因装了一个X86版本的jdk（CDH镜像网站上提供的，顺手就装了），32位JDK跑在64位的机器上，可能是会出现去取当前新生代的内存阈值不支持的问题。而HDFS,Yarn组件会频繁的去取运行内存情况用于垃圾回收(可能是自身做的一个优化)却屡屡失败，积累到一定量级导致组件不稳定以及假死。
升级到64位版JDK，日志稳定，不再报错。假死现象初步观察得以解决。
