标签：
问题：
自己写了一个yarn上的application，发现nodemanager过段时间，会out of memory退出，把nodemanager的heap memory从1G增大到2G也是无法避免NM程序OOM
开启NM的jmx监控
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=50079 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
然后用jconsole连接，如下图所示
然后主要内存都在old gen里头占用，perform GC也是没有效果，说明内存都是在被引用着。
写了一个crontab半小时生成一份内存对象数据
*/30 * * * * jmap -histo:live 18114 > /home/yarn/log/`date`.log
对比发现主要的内存增长几乎都在[C这个类中，因为instances数目基本不增长，只是size增长，大概猜想是因为stringbuilder的不停append导致
:/home/yarn/log# diff Mon\ Aug\ 24\ 04\:30\:02\ PDT\ 2015.log Mon\ Aug\ 24\ 19\:30\:01\ PDT\ 2015.log 4,10c4,10 < 1: 33014 312864176 [C < 2: 90784 11817968 <constMethodKlass> < 3: 90784 11632640 <methodKlass> < 4: 7756 8908000 <constantPoolKlass> < 5: 7756 5780072 <instanceKlassKlass> < 6: 6493 4882976 <constantPoolCacheKlass> < 7: 21287 3447608 [B --- > 1: 33219 622929048 [C > 2: 90897 11830824 <constMethodKlass> > 3: 90897 11647104 <methodKlass> > 4: 7807 8948632 <constantPoolKlass> > 5: 7807 5810392 <instanceKlassKlass> > 6: 6543 4913344 <constantPoolCacheKlass> > 7: 21346 3470040 [B
利用java工具
jmap -dump:live,format=b,file=xxx.xxx [pid] jhat -J-Xmx1024M [file]
看到的东西也不够明了
最后打算用mat来图形化的分析下问题，https://eclipse.org/mat/
定位到shell.java的代码
原来nodemanager这边启动一个command之后，一直会记录标准错误输出到一个变量，这个变量在程序运行期间一直不会被释放，GC也无法回收空间，找到问题之后，解决办法就很简单了。启动一个命令的时候把标准输出和错误输出都定位到一个文件，不让nodemanager去接收即可。如下
// Add log redirect params vargs.add("1>>" + ApplicationConstants.LOG_DIR_EXPANSION_VAR + "/" + VoidboxConfiguration.VOIDBOX_PROXY_LOG_FILENAME); vargs.add("2>>" + ApplicationConstants.LOG_DIR_EXPANSION_VAR + "/" + VoidboxConfiguration.VOIDBOX_PROXY_LOG_FILENAME);
不过这边NM这个潜在的bug还是需要fix的，不能因为程序的一些考虑不周到，而影响了自身的稳定。
建议可以对errMsg做rotate。
Nodemanager Out of heap memory[fix bug全过程]
标签：
原文地址：http://www.cnblogs.com/yanghuahui/p/4757151.html
