|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
按照它们在系统中的作用分成几个部分介绍给大家,通过这些基础命令的学习我们可以进一步理解Linux系统:
受益生齿述凄惨的遭受——
1、比来一段工夫(改换了预发呆板后)我卖力的一个使用的预发情况(线上不乱得像个婴儿~)出格不不乱,开始是使用一再的过几天就发明供应的接口不事情了,但容器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这个工夫点,找到:
Jun2004:05:14***.pre.cm3kernel::javainvokedoom-killer:gfp_mask=0x201d2,order=0,oomkilladj=0
Jun2004:05:14***.pre.cm3kernel::
Jun2004:05:14***.pre.cm3kernel::CallTrace:
Jun2004:05:14***.pre.cm3kernel::[]out_of_memory+0x8b/0x203
...
Jun2004:05:18***.pre.cm3kernel::Mem-info:
...
oom-killer,之前不晓得有这个工具,想一想JVM本人不成能产生OOM,由于即没OOM日记也没CrashCore日记,并且还每次都是统一工夫点!使用中也木有这类准时义务。
关于LinuxOOM-killer机制——
linuxoom-killer是一种自我回护机制,当体系分派不出内存时(触发前提)会触发这个机制,由操纵体系在己有历程中选择一个占用内存较多,接纳内存收益最年夜的历程kill失落来开释内存。
体系为每一个历程做评价(/proc/<pid>/oom_score中数值最年夜的历程被kill失落),参考这里。
后面的成绩,Java历程占用内存充足多,历程保存又对照短,恰是OOM-killer的首选啊,以是中招。
- /**
- *badness–calculateanumericvalueforhowbadthistaskhasbeen
- *@p:taskstructofwhichtaskweshouldcalculate
- *@uptime:currentuptimeinseconds
- *
- *Theformulausedisrelativelysimpleanddocumentedinlineinthe
- *function.Themainrationaleisthatwewanttoselectagoodtask
- *tokillwhenwerunoutofmemory.
- *
- *Goodinthiscontextmeansthat:
- *1)welosetheminimumamountofworkdone
- *2)werecoveralargeamountofmemory
- *3)wedon’tkillanythinginnocentofeatingtonsofmemory
- *4)wewanttokilltheminimumamountofprocesses(one)
- *5)wetrytokilltheprocesstheuserexpectsustokill,this
- *algorithmhasbeenmeticulouslytunedtomeettheprinciple
- *ofleastsurprise…(becarefulwhenyouchangeit)
- */
别的,Linux的malloc分派内存,也不是一次到位的真分派了指定巨细的物理内存(Overcommit机制,另外一篇也不错,这里Fenny一篇),而是先答应你,实践用到的时分才往体系分派,假如恰好谁人时分内存不敷了,就会触发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,在这个情形下,体系所能分派的内存不会凌驾swap+RAM*系数(/proc/sys/vm/overcmmit_ratio,默许50%,你能够调剂),假如这么多资本已用光,那末前面任未尝试请求内存的举动城市前往毛病,这一般意味着此时没法运转任何新程序。 我的呆板为何会触发OOM-killer——
先查了下sar的日记:
- 12:00:01AMCPU%user%nice%system%iowait%steal%idle
- 04:00:01AMall0.010.000.000.000.0199.98
- 04:10:02AMall0.550.0020.7137.970.0640.71
- 04:20:01AMall0.010.000.040.240.0199.71
systemcpu占的对照多,应当是kernelOOM-killer实行所占失落的。再看没有启java历程情形下这个工夫点的日记,CPU是一般的。
cat/proc/sys/vm/overcommit_memory值0,即启示式战略,同意Overcommit。
再看这台呆板上对照损耗内存的历程:
<br>
总可用内存才2G(改换呆板之前为4G,前面的设置是按4G来配的),JVM就请求了2G+,再加上nginx所占请求内存,远超实践物理内存2G+Swap1G局限了,使用之以是一般是使用启动不久,实践用的内存并没用那末多,到早晨到达临界值,实在一个不干系的准时义务请求内存,恰好就触发了OOM-killer了。
nginx和java使用线上长工夫考证是不乱的,不存在内存保守,至于呆板上4:03启动了甚么义务,实在都不那末主要了。
参考材料:
Linux体系日记办理
HowtheLinuxOOMkillerworks
TamingtheOOMkiller
WhenLinuxRunsOutofMemory
OOMKiller
Linux下OOMKiller机制详解
Linux的Out-of-Memory(OOM)Killer
MemoryovercommitinLinux
网络操作命令:ifconfig、ip、ping、netstat、telnet、ftp、route、rloginrcp、finger、mail、nslookup |
|