福建省建设厅考试网站,网站怎么做 流程图,中国建设银行 云南 网站首页,微信公众号平台及网站建设计划From1、最近一段时间(更换了预发机器后)我负责的一个应用的预发环境(线上稳定得像个婴儿~)特别不稳定#xff0c;最先是应用频频的过几天就发现提供的接口不工作了#xff0c;但容器Jetty还在跑得欢#xff0c;于是jstack/jmap看#xff0c;发现没有一个线程在跑我的war包中…From1、最近一段时间(更换了预发机器后)我负责的一个应用的预发环境(线上稳定得像个婴儿~)特别不稳定最先是应用频频的过几天就发现提供的接口不工作了但容器Jetty还在跑得欢于是jstack/jmap看发现没有一个线程在跑我的war包中的程序但是容器里个中间件的sar还跑得很欢(-_-|||)dump出来的对象也没有一点蛛丝马迹所有日志到04:03就什么也没有了。然后查发现一个中间件的sar(远程接口层)包刚好在那个时候升级了这玩意用OSGI的CloassLoader来加载整个应用自然就怀疑它怎么着把我的Class都卸载掉了。简单回滚到前一版本试试。2、诡异的第二天还是4:03分又发作了!排除了新sar的原因就百思不和其解了发现-XX:CMSClassUnloadingEnabled开着关掉。第二天还是一样各种看代码都没有问题在一个无穷循环的线程里打日志各种招都用上还是老样子连Servlet消失了突然对哥掌握的Java知识产生了莫名其妙的怀疑…3、这个应用改过名字上边2个应用的目录都存在的。发现老目录的log文件修改时间居然是当前时间,再PS一看发现启的进程是老应用的新老2个war变化非常大之前验证的点在老war里都木有的好觉得终于找着原因了。删老目录找PE查脚本果然查到启老应用的脚本!停掉脚本。甚至把老的应用目录link到新应用即使脚本改不干净也不致于把我应用杀掉免受接口调用方骚扰啊。4、奇迹再一次发生了。应用在4:03准时消失了老的确实也不起来了。因为是预发环境线上完全无问题怀疑是环境问题所以也就一直没花太多时间去查。PE也觉不再有脚本在跑了好吧决定好好查一下。首先看系统日志希望能找到SSH登录日志、命令执行日志或进程启动/终止日志搜4点这个时间wtmp/secure都没有发现。然后找messages这个时间点找到Jun 20 04:05:14 ***.pre.cm3 kernel: : java invoked oom-killer : gfp_mask0x201d2, order0, oomkilladj0Jun 20 04:05:14 ***.pre.cm3 kernel: :Jun 20 04:05:14 ***.pre.cm3 kernel: : Call Trace:Jun 20 04:05:14 ***.pre.cm3 kernel: : [] out_of_memory0x8b/0x203...Jun 20 04:05:18 ***.pre.cm3 kernel: : Mem-info:...oom-killer之前不知道有这个东西想想JVM自己不可能发生OOM,因为即没OOM日志也没Crash Core日志而且还每次都是同一时间点应用中也木有这种定时任务。关于Linux OOM-killer机制——是一种自我保护机制当系统分配不出内存时( )会触发这个机制由操作系统在己有进程中挑选一个占用内存较多回收内存收益最大的进程kill掉来释放内存。系统为每个进程做评估(/proc/ /oom_score中数值最大的进程被kill掉) 。前面的问题Java进程占用内存足够多进程生存又比较短正是OOM-killer的首选啊所以中招。/*** badness – calculate a numeric value for how bad this task has been* p: task struct of which task we should calculate* uptime: current uptime in seconds** The formula used is relatively simple and documented inline in the* function. The main rationale is that we want to select a good task* to kill when we run out of memory.** Good in this context means that:* 1) we lose the minimum amount of work done* 2) we recover a large amount of memory* 3) we don’t kill anything innocent of eating tons of memory* 4) we want to kill the minimum amount of processes (one)* 5) we try to kill the process the user expects us to kill, this* algorithm has been meticulously tuned to meet the principle* of least surprise … (be careful when you change it)*/另外Linux的malloc分配内存也不是一次到位的真分配了指定大小的物理内存( , ,这里 )而是先承诺你实际用到的时候才去系统分配如果刚好那个时候内存不够了就会触发oom-killer。Linux下有3种Overcommit的策略(参考内核文档vm/overcommit-accounting)可以在/proc/sys/vm/overcommit_memory配置。取0,1和2三个值默认是0。0启发式策略比较严重的Overcommit将不能得逞比如你突然申请了128TB的内存。而轻微的Overcommit将被允许。另外root能Overcommit的值比普通用户要稍微多些。1永远允许Overcommit这种策略适合那些不能承受内存分配失败的应用比如某些科学计算应用。2永远禁止Overcommit在这个情况下系统所能分配的内存不会超过swapRAM*系数( /proc/sys/vm/overcmmit_ratio 默认50%你可以调整)如果这么多资源已经用光那么后面任何尝试申请内存的行为都会返回错误这通常意味着此时没法运行任何新程序。我的机器为什么会触发OOM-killer——先查了下sar的日志12 : 00 : 01 AM CPU % user % nice % system % iowait % steal % idle04 : 00 : 01 AM all 0.01 0.00 0.00 0.00 0.01 99.9804 : 10 : 02 AM all 0.55 0.00 20.71 37.97 0.06 40.7104 : 20 : 01 AM all 0.01 0.00 0.04 0.24 0.01 99.71system cpu占的比较多应该是kernel OOM-killer执行所占掉的。再看没有启java进程情况下这个时间点的日志CPU是正常的。cat /proc/sys/vm/overcommit_memory 值0即启发式策略允许Overcommit。再看这台机器上比较消耗内存的进程总可用内存才2G(更换机器之前为4G后面的配置是按4G来配的),JVM就申请了2G再加上nginx所占申请内存远超实际物理内存2GSwap 1G范围了应用之所以正常是应用启动不久实际用的内存并没用那么多到晚上达到临界值其实一个不相干的定时任务申请内存刚好就触发了OOM-killer了。nginx和java应用线上长时间验证是稳定的不存在内存泄露至于机器上4:03启动了什么任务其实都不那么重要了。参考资料From 2 http://www.tuicool.com/articles/6veeIv
