二次元同好交流新大陆
扫码下载App
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(1246)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_094068',
blogTitle:'关于avast（小a）ashServ.exe狂占CPU的解决办法！！！！',
blogAbstract:'自从本人装了小A后，就一直被ASHSERV.EXE狂占CPU的问题所\r\n困扰。事情的原委是这样的，我一当进入某些文件夹，系统就会出现假死，然后我调出Windows\r\n任务管理器发现ashServ.exe这个进程狂占CPU到90多，要大约2&&3分钟才能平息。我一直在找原因都没有找到，还重装过小A，问题依然不能\r\n得到解决，后来我就到论坛求救，几天过后果然有人发现了问题所在，让我如梦初醒。我觉得这个问题还是有很多人没有发现的，在这里跟大家说一下：\r\n& & 之所以这个进程会狂占CPU的重要原因可能是我们的文件夹中有不少压缩文件，而使到小A不停得扫描导致的假死。',
blogTag:'',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:6,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'贫下中农',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}最近在运维我们部门的hadoop集群时,发现了很多Job OOM的现象,因为在机器上可以用命令进行查看,full gc比较严重.我们都知道,full gc带来的后果是比较大的,会"stop the world"的,一旦你的full gc elapsed time超过几分钟,那么其他的活动都得暂停这么多时间.所以Full gc一旦出现并且异常,一定要找到根源并将其解决.本篇文章就为大家讲述一下我们是如何解决这类问题并且在这个基础上做了一些别的什么优化的.
Full Gc源于何处
OOM发生了,导致频繁的Full Gc的现象,首先就要想到底是什么导致Full gc.第一个联想一定是上面跑的Job,Job的运行时的体现又是从每个task身上来的,而每个Task又是表现于每个TaskAttempt.而TaskAttempt是跑在所申请到的container中的.每个container都是一个独立的进程,你可以在某台datanode上用jps命令,可以看到很多叫"YarnChild"的进程,那就是container所起的.找到了源头之后,我们估计会想,那应该是container所启的jvm的内存大小配小了,导致内存不够用了,内存配大些不就可以解决问题了?事实上问题并没有这么简单,这里面的水还是有点深的.
为什么会发生Full Gc
一.为什么会发生full gc,第一种原因就是平常大家所说的内存配小了,就是下面2个配置项:
public&static&final&String&MAP_MEMORY_MB&=&"mapreduce.map.memory.mb";&&
public&static&final&String&REDUCE_MEMORY_MB&=&"mapreduce.reduce.memory.mb";&&
默认都是1024M,就是1个G.
二.另外一个原因估计想到的人就不太多了,除非你真的在生活中碰到过,概况来说一句话:错误的配置导致.上面的这个配置其实并不是container设置他所启的jvm的配置,而是每个Task所能用的内存的上限值,但是这里会有个前提,你的jvm必须保证可以用到这么多的内存,如果你的jvm最大内存上限就只有512M,你的task的memory设的再大也没有,最后造成的直接后果就是内存一用超,就会出现full gc.上面的2个值更偏向于理论值.而真正掌控jvm的配置项的其实是这2个配置:
public&static&final&String&MAP_JAVA_OPTS&=&"mapreduce.map.java.opts";&&
public&static&final&String&REDUCE_JAVA_OPTS&=&"mapreduce.reduce.java.opts";&&
所以理想的配置应该是java.opts的值必须大于等于memory.mb的值.所以说,这种配置不当的方式也会引发频繁的full gc.
Container内存监控
不过比较幸运的是针对上面所列举的第二种问题,hadoop自身已经对此进行了contaienr级别的监控,对于所有启动过container,他会额外开启一个叫container-monitor的线程,专门有对于这些container的pmem(物理内存),vmem(虚拟内存)的监控.相关的配置属于如下:
String&org.apache.hadoop.yarn.conf.YarnConfiguration.NM_PMEM_CHECK_ENABLED&=&"yarn.nodemanager.pmem-check-enabled"&&
String&org.apache.hadoop.yarn.conf.YarnConfiguration.NM_VMEM_CHECK_ENABLED&=&"yarn.nodemanager.vmem-check-enabled"&&
默认都是开启的.内存监控的意思就是一旦这个container所使用的内存超过这个jvm本身所能使用的最大上限值,则将此conyainer kill掉.下面简单的从源代码的级别为大家分析一下,过其实不难.首先进入到ContainersMonitorImpl.java这个类.
@Override&&
&&protected&void&serviceInit(Configuration&conf)&throws&Exception&{&&
&&&&this.monitoringInterval&=&&
&&&&&&&&conf.getLong(YarnConfiguration.NM_CONTAINER_MON_INTERVAL_MS,&&
&&&&&&&&&&&&YarnConfiguration.DEFAULT_NM_CONTAINER_MON_INTERVAL_MS);&&
&&&&....&&
&&&&pmemCheckEnabled&=&conf.getBoolean(YarnConfiguration.NM_PMEM_CHECK_ENABLED,&&
&&&&&&&&YarnConfiguration.DEFAULT_NM_PMEM_CHECK_ENABLED);&&
&&&&vmemCheckEnabled&=&conf.getBoolean(YarnConfiguration.NM_VMEM_CHECK_ENABLED,&&
&&&&&&&&YarnConfiguration.DEFAULT_NM_VMEM_CHECK_ENABLED);&&
&&&&("Physical&memory&check&enabled:&"&+&pmemCheckEnabled);&&
&&&&("Virtual&memory&check&enabled:&"&+&vmemCheckEnabled);&&
&&&&....&&
在serviceInit方法中就会从配置中读取是否开启内存监控功能,并输出日志信息.然后我们直接进入到此类的MonitorThread监控线程类中.
private&class&MonitoringThread&extends&Thread&{&&
&&public&MonitoringThread()&{&&
&&&&super("Container&Monitor");&&
&&@Override&&
&&public&void&run()&{&&
&&&&while&(true)&{&&
&&&&&&if&(LOG.isDebugEnabled())&{&&
&&&&&&&&StringBuilder&tmp&=&new&StringBuilder("[&");&&
&&&&&&&&for&(ProcessTreeInfo&p&:&trackingContainers.values())&{&&
&&&&&&&&&&tmp.append(p.getPID());&&
&&&&&&&&&&tmp.append("&");&&
&&&&&&&&}&&
&&&&&&&&....&&
在监控线程的run方法中,他会对所监控的container做遍历判断处理
@Override&&
&&&public&void&run()&{&&
&&&&&while&(true)&{&&
&&&&&&&....&&
&&&&&&&long&vmemStillInUsage&=&0;&&
&&&&&&&long&pmemStillInUsage&=&0;&&
&&&&&&&for&(Iterator&Map.Entry&ContainerId,&ProcessTreeInfo&&&it&=&&
&&&&&&&&&&&trackingContainers.entrySet().iterator();&it.hasNext();)&{&&
&&&&&&&&&Map.Entry&ContainerId,&ProcessTreeInfo&&entry&=&it.next();&&
&&&&&&&&&ContainerId&containerId&=&entry.getKey();&&
&&&&&&&&&ProcessTreeInfo&ptInfo&=&entry.getValue();&&
&&&&&&&&&try&{&&
&&&&&&&&&&&String&pId&=&ptInfo.getPID();&&
&&&&&&&&&&&....&&
我们以物理内存监控的原理实现为一个例子.
首先他会根据pTree拿到进程相关的运行信息,比如内存,CPU信息等
LOG.debug("Constructing&ProcessTree&for&:&PID&=&"&+&pId&&
&&&&&&&&&&&&&&&+&"&ContainerId&=&"&+&containerId);&&
&&&&&&&&&&&ResourceCalculatorProcessTree&pTree&=&ptInfo.getProcessTree();&&
&&&&&&&&&&&pTree.updateProcessTree();&&&&
&&&&&&&&&&&long&currentVmemUsage&=&pTree.getVirtualMemorySize();&&
&&&&&&&&&&&long&currentPmemUsage&=&pTree.getRssMemorySize();&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&float&cpuUsagePercentPerCore&=&pTree.getCpuUsagePercent();&&
&&&&&&&&&&&float&cpuUsageTotalCoresPercentage&=&cpuUsagePercentPerCore&/&&
&&&&&&&&&&&&&&&resourceCalculatorPlugin.getNumProcessors();&&
然后拿到内存使用上限值
&&&&&&&&&&&&int&milliVcoresUsed&=&(int)&(cpuUsageTotalCoresPercentage&*&1000&&
&&&&&&&&&&&&&&&&*&maxVCoresAllottedForContainers&/nodeCpuPercentageForYARN);&&
&&&&&&&&&&&&
&&&&&&&&&&&&
&&&&&&&&&&&&long&curMemUsageOfAgedProcesses&=&pTree.getVirtualMemorySize(1);&&
&&&&&&&&&&&&long&curRssMemUsageOfAgedProcesses&=&pTree.getRssMemorySize(1);&&
&&&&&&&&&&&&long&vmemLimit&=&ptInfo.getVmemLimit();&&
&&&&&&&&&&&&long&pmemLimit&=&ptInfo.getPmemLimit();&&
而这个pememLimit就不是pTree的信息,而是来自于外界所启动container时候所传进来的值,这个值其实就是java.opts的值.
ContainerId&containerId&=&monitoringEvent.getContainerId();&&
&&&&switch&(monitoringEvent.getType())&{&&
&&&&case&START_MONITORING_CONTAINER:&&
&&&&&&ContainerStartMonitoringEvent&startEvent&=&&
&&&&&&&&&&(ContainerStartMonitoringEvent)&monitoringE&&
&&&&&&synchronized&(this.containersToBeAdded)&{&&
&&&&&&&&ProcessTreeInfo&processTreeInfo&=&&
&&&&&&&&&&&&new&ProcessTreeInfo(containerId,&null,&null,&&
&&&&&&&&&&&&&&&&startEvent.getVmemLimit(),&startEvent.getPmemLimit(),&&
&&&&&&&&&&&&&&&&startEvent.getCpuVcores());&&
&&&&&&&&this.containersToBeAdded.put(containerId,&processTreeInfo);&&
然后是内存监控的核心逻辑
&&&&&&&&&&&&}&else&if&(isPmemCheckEnabled()&&
&&&&&&&&&&&&&&&&&&&isProcessTreeOverLimit(containerId.toString(),&&
&&&&&&&&&&&&&&&&&&&&currentPmemUsage,&curRssMemUsageOfAgedProcesses,&&
&&&&&&&&&&&&&&&&&&&&pmemLimit))&{&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&msg&=&formatErrorMessage("physical",&&
&&&&&&&&&&&&&&&&&&currentVmemUsage,&vmemLimit,&&
&&&&&&&&&&&&&&&&&&currentPmemUsage,&pmemLimit,&&
&&&&&&&&&&&&&&&&&&pId,&containerId,&pTree);&&
&&&&&&&&&&&&&&isMemoryOverLimit&=&&&
&&&&&&&&&&&&&&containerExitStatus&=&ContainerExitStatus.KILLED_EXCEEDED_PMEM;&&
&&&&&&&&&&&&&&....&&
传入当前的内存使用量和限制值然后做比较,isProcessTreeOverLimit最终会调用到下面的这个方法.
boolean&isProcessTreeOverLimit(String&containerId,&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&long&currentMemUsage,&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&long&curMemUsageOfAgedProcesses,&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&long&vmemLimit)&{&&
&&boolean&isOverLimit&=&&&
&&if&(currentMemUsage&&&(2&*&vmemLimit))&{&&
&&&&LOG.warn("Process&tree&for&container:&"&+&containerId&&
&&&&&&&&+&"&running&over&twice&"&+&"the&configured&limit.&Limit="&+&vmemLimit&&
&&&&&&&&+&",&current&usage&=&"&+&currentMemUsage);&&
&&&&isOverLimit&=&&&
&&}&else&if&(curMemUsageOfAgedProcesses&&&vmemLimit)&{&&
&&&&LOG.warn("Process&tree&for&container:&"&+&containerId&&
&&&&&&&&+&"&has&processes&older&than&1&"&&
&&&&&&&&+&"iteration&running&over&the&configured&limit.&Limit="&+&vmemLimit&&
&&&&&&&&+&",&current&usage&=&"&+&curMemUsageOfAgedProcesses);&&
&&&&isOverLimit&=&&&
&&return&isOverL&&
有2种情况会导致内存超出的现象,1个是使用内存超出限制内存2倍,理由是新的jvm会执行fork和exec操作,fork操作会拷贝父进程的信息,还有1个就是内存年龄值的限制.其他的上面注释已经写的很清楚了,如果还看不懂英文的话,自行找工具翻译.
最后如果发现container内存使用的确是超出内存限制值了,之后,就会发送container kill的event事件,会触发后续的container kill的动作.
&&&&&&&&&&&&}&else&if&(isVcoresCheckEnabled()&&
&&&&&&&&&&&&&&&&&&&cpuUsageTotalCoresPercentage&&&vcoresLimitedRatio)&{&&
&&&&&&&&&&&&&&msg&=&&
&&&&&&&&&&&&&&&&&&String.format(&&
&&&&&&&&&&&&&&&&&&&&&&"Container&[pid=%s,containerID=%s]&is&running&beyond&%s&vcores&limits."&&
&&&&&&&&&&&&&&&&&&&&&&&&&&+&"&Current&usage:&%s.&Killing&container.\n",&pId,&&
&&&&&&&&&&&&&&&&&&&&&&containerId,&vcoresLimitedRatio);&&
&&&&&&&&&&&&&&isCpuVcoresOverLimit&=&&&
&&&&&&&&&&&&&&containerExitStatus&=&ContainerExitStatus.KILLED_EXCEEDED_VCORES;&&
&&&&&&&&&&&&}&&
&&&&&&&&&&&&if&(isMemoryOverLimit)&{&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&LOG.warn(msg);&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&if&(!pTree.checkPidPgrpidForMatch())&{&&
&&&&&&&&&&&&&&&&LOG.error("Killed&container&process&with&PID&"&+&pId&&
&&&&&&&&&&&&&&&&&&&&+&"&but&it&is&not&a&process&group&leader.");&&
&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&eventDispatcher.getEventHandler().handle(&&
&&&&&&&&&&&&&&&&&&new&ContainerKillEvent(containerId,&&
&&&&&&&&&&&&&&&&&&&&&&containerExitStatus,&msg));&&
&&&&&&&&&&&&&&it.remove();&&
&&&&&&&&&&&&&&("Removed&ProcessTree&with&root&"&+&pId);&&
&&&&&&&&&&&&}&else&{&&
&&&&&&&&&&&&&&...&&
这就是container的内存监控的整个过程.我们当时又恰巧把这个功能给关了,所以导致了大量的Ful gc的现象.
为什么只对Container内存做监控
对于小标题上的问题,不知道有没有哪位同学想过?当时我在解决掉这个问题之后,我就在想,同样是很关键的指标,CPU的使用监控为什么不在ContainersMonitorImpl一起做掉呢.下面是我个人所总结出来的几点原因.
1.内存问题所造成的结果比CPU使用造成的影响更大,因为OOM问题一旦发生,就会引起gc.
2.内存问题比较CPU使用问题更加常见.因为大家在平常生活或写程序时,经常发碰到类似"啊,内存不够用了"等类似的问题,相对比较少碰到"CPU不够用了"的问题.
3.内存问题与Job运行规模,数据量使用规模密切相关.内存的使用与Job所处理的数据量密切相关,一般大Job,处理数据量大了,内存使用自然会变多,CPU也会变多,但不会那么明显.
综上3点原因,所以CPU监控并没有被加入到监控代码中(个人分析而言).
但是hadop自身没有加CPU监控并不代表我们不可以加这样的监控,有一些程序可能就是那种应用内存并不多,但是会耗尽很多CPU资源的程序,比如说开大量的线程,但是每个线程都在做很简单的操作,就会造成机器线程占比过高的问题.基于这个出发点,我添加了CPU使用百分比的监控.
Container的Cpu使用率监控
首先你要定义是否开启此功能的配置:
public&static&final&String&NM_VCORES_CHECK_ENABLED&=&NM_PREFIX&&
&&&&+&"vcores-check-enabled";&&
public&static&final&boolean&DEFAULT_NM_VCORES_CHECK_ENABLED&=&&&
因为是新功能,默认是关闭的,然后你还需要定义1个使用阈值,在0~1之间,就是说一旦某个container的使用CPU的百分比超过这个值,就会被kill.
public&static&final&String&NM_VCORES_LIMITED_RATIO&=&NM_PREFIX&&
&&&&+&"resource.cpu-vcores.limited.ratio";&&
public&static&final&float&DEFAULT_NM_VCORES_LIMITED_RATIO&=&0.8f;&&
默认这个值0.8,这个可以你随便设置.监控代码的逻辑,与内存监控完全类似,我将比较快的带过.
多定义2个变量值
private&boolean&pmemCheckE&&
&&private&boolean&vcoresCheckE&&
&&private&float&vcoresLimitedR&&
然后在serviceInit中进程配置初始化工作
&&&&pmemCheckEnabled&=&conf.getBoolean(YarnConfiguration.NM_PMEM_CHECK_ENABLED,&&
&&&&&&&&YarnConfiguration.DEFAULT_NM_PMEM_CHECK_ENABLED);&&
&&&&vmemCheckEnabled&=&conf.getBoolean(YarnConfiguration.NM_VMEM_CHECK_ENABLED,&&
&&&&&&&&YarnConfiguration.DEFAULT_NM_VMEM_CHECK_ENABLED);&&
&&&&vcoresCheckEnabled&=&&
&&&&&&&&conf.getBoolean(YarnConfiguration.NM_VCORES_CHECK_ENABLED,&&
&&&&&&&&&&&&YarnConfiguration.DEFAULT_NM_VCORES_CHECK_ENABLED);&&
&&&&("Physical&memory&check&enabled:&"&+&pmemCheckEnabled);&&
&&&&("Virtual&memory&check&enabled:&"&+&vmemCheckEnabled);&&
&&&&("Cpu&vcores&check&enabled:&"&+&vcoresCheckEnabled);&&
&&&&if&(vcoresCheckEnabled)&{&&
&&&&&&vcoresLimitedRatio&=&&
&&&&&&&&&&conf.getFloat(YarnConfiguration.NM_VCORES_LIMITED_RATIO,&&
&&&&&&&&&&&&&&YarnConfiguration.DEFAULT_NM_VCORES_LIMITED_RATIO);&&
&&&&&&("Vcores&limited&ratio:&"&+&vcoresLimitedRatio);&&
然后利用monitor监控代码中已计算出的cpu百分比变量
LOG.debug("Constructing&ProcessTree&for&:&PID&=&"&+&pId&&
&&&&&&&&&&&&&&&&+&"&ContainerId&=&"&+&containerId);&&
&&&&&&&&&&&&ResourceCalculatorProcessTree&pTree&=&ptInfo.getProcessTree();&&
&&&&&&&&&&&&pTree.updateProcessTree();&&&&
&&&&&&&&&&&&long&currentVmemUsage&=&pTree.getVirtualMemorySize();&&
&&&&&&&&&&&&long&currentPmemUsage&=&pTree.getRssMemorySize();&&
&&&&&&&&&&&&
&&&&&&&&&&&&
&&&&&&&&&&&&
&&&&&&&&&&&&float&cpuUsagePercentPerCore&=&pTree.getCpuUsagePercent();&&
&&&&&&&&&&&&float&cpuUsageTotalCoresPercentage&=&cpuUsagePercentPerCore&/&&
&&&&&&&&&&&&&&&&resourceCalculatorPlugin.getNumProcessors();&&
最后进行大小判断即可
&&&&&&&&&&&&}&else&if&(isVcoresCheckEnabled()&&
&&&&&&&&&&&&&&&&&&&cpuUsageTotalCoresPercentage&&&vcoresLimitedRatio)&{&&
&&&&&&&&&&&&&&msg&=&&
&&&&&&&&&&&&&&&&&&String.format(&&
&&&&&&&&&&&&&&&&&&&&&&"Container&[pid=%s,containerID=%s]&is&running&beyond&%s&vcores&limits."&&
&&&&&&&&&&&&&&&&&&&&&&&&&&+&"&Current&usage:&%s.&Killing&container.\n",&pId,&&
&&&&&&&&&&&&&&&&&&&&&&containerId,&vcoresLimitedRatio);&&
&&&&&&&&&&&&&&isCpuVcoresOverLimit&=&&&
&&&&&&&&&&&&&&containerExitStatus&=&ContainerExitStatus.KILLED_EXCEEDED_VCORES;&&
&&&&&&&&&&&&}&&
&&&&&&&&&&&&if&(isMemoryOverLimit&||&isCpuVcoresOverLimit)&{&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&LOG.warn(msg);&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&if&(!pTree.checkPidPgrpidForMatch())&{&&
&&&&&&&&&&&&&&&&LOG.error("Killed&container&process&with&PID&"&+&pId&&
&&&&&&&&&&&&&&&&&&&&+&"&but&it&is&not&a&process&group&leader.");&&
&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&&&
&&&&&&&&&&&&&&eventDispatcher.getEventHandler().handle(&&
&&&&&&&&&&&&&&&&&&new&ContainerKillEvent(containerId,&&
&&&&&&&&&&&&&&&&&&&&&&containerExitStatus,&msg));&&
&&&&&&&&&&&&&&it.remove();&&
&&&&&&&&&&&&&&("Removed&ProcessTree&with&root&"&+&pId);&&
&&&&&&&&&&&&}&else&{&&
对了,还要在这里添加1个新的ExitStatus退出码:
public&static&final&int&KILLED_EXCEEDED_VCORES&=&-108;&&
CPU监控代码的改动就是这么多.此功能的完整代码可以查看文章末尾的链接.在这里我要特别申请一下,此功能代码由于我在本地电脑上不支持ProcfsBasedProcessTree,导致单元测试没法跑通,所以我还没有完整测过,理论上是OK,大家可以拿去试试,可以给我一些反馈.希望能带给大家收获.
Github patch链接:
阅读(...) 评论()MSR5040路由器CPU使用率过高什么原因？_百度知道
MSR5040路由器CPU使用率过高什么原因？
14725c3TICK
0&#47: 99%CPU Usage S
40761dCCHK
0&#47:10. Time :
799a58 ACL
a803a9L2TP
10abb1DrTF
0&#47: 0x3b0e(CPU Tick High) 0xc54279fe(CPU Tick Low)Actual Stat:05CPU Usage S
0/ 1512713IFNT
0&#47: 0x0(CPU Tick High) 0x(CPU Tick Low)TaskName
Runtime(CPU Tick High/
0/6cb97c80DrTm
0/H3C5040_1&
2d4781STMR
128876VTYD
0/dis cpu-usage task ===== Current CPU usage info =====CPU Usage SCPU Tick Low)VIDL
0&#47: 38 (Second)CPU Usage
. Cycle&lt
怎么回事！！但是从路由器速度上看没有什么问题我有两台路由器每一个都是DrTF进程超过95%！
提问者采纳
系统开启时，里面的处理信息占用了大量的CPU资源。
其他类似问题
为您推荐：
您可能关注的推广
cpu使用率的相关知识
其他2条回答
rTF和SOCK任务都是用于包转发的任务，通过display interface可查看这个统计，
在路由器的每个对外接口上，都有对最近300秒的输入输出的流量统计，表明路由器需要转发的流量较大，这两个任务高，则表明cpu高是正常的，观察流量是否已经接近接口线速，如果是接近
人家问的是
什么原因，你答非所问吗,,,我也认为是 二楼的观点 系统开启时， 里面的处理信息占用了大量的CPU资源。 ，
绝对 不要紧的
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁关于系统进程,高手进!!!_百度知道
关于系统进程,高手进!!!
C:14 KB文件版本,最近突然发现有一个名为svchost的系统进程在开机不久的时候会占cpu使用率90%以上,一共有8个svchost.2600;System32&#92.exe命令行.exe -k netsvcs文件描述: 安全路径;WINDOWS&#92:名称.1;WINDOWS&#92:system32&#92:Generic Host Process for Win32 Services出品公司?,导致整机速度慢:Microsoft Corporation文件大小小弟用的是winxp sp2操作系统.exe进程正常不;svchost:5:100 - 进程项安全级别:1bb906a2e148另外问一句,一下是该进程的详细信息.2180MD5值:\svchost:&#92:C.exe组别
决问题必将加分重谢!!!!!!!
我有更好的答案
系统进程列表
actmovie.exe agentsvr.exe
alg.exe ASPNET_WP.exe btwdins.exe
ccmexec.exe cidaemon.exe cisvc.exe
clisvcl.exe cmd.exe Control.exe
csrss.exe ctfmon.exe ddhelp.exe
dfssvc.exe dllhost.exe dos4gw.exe
dotnetfx.exe dumprep.exe explorer.exe
fast.exe grpconv.exe hidserv.exe
iexplore.exe imapi.exe inetinfo.exe
internat.exe kernel32.dll launch32.exe
loadwc.exe locator.exe logonui.exe
lsass.exe mad.exe mapisp32.exe
mmc.exe mmtask.tsk mprexe.exe
msconfig.exe msdtc.exe msgsrv32.exe
msiexec.exe msoobe.exe mstask.exe
mstinit.exe ndisuio.sys netdde.exe
ntoskrnl.exe ntvdm.exe pchschd.exe
pstores.exe rasautou.exe rdpclip.e...
svchost.exe是系统服务，有多个也是正常的，有没病毒，不好说。要具体看了。
svchost.exe是系统服务，具体有多少个也关系到你所启用 服务，服务启动的越多，所产生的进程，包括svchost.exe就可能越多，但也不排除病毒，不过目前svchost.exe已经不是那么多了，你先确保机器无毒，然后对系统服务进行优化
下面是我编辑好的优化批处理
打开记事本
将以下内容复制进去 并保存成.bat格式
例如1.bat 然后双击1.bat 后 重启电脑 就完成了对服务的自动优化了
rem 服务最优批处理文件！！
Alerter start= DISABLED
Application Layer Gateway Service 2
ALG start= DISABLED
@rem Application Management (应用程序管理) 3
AppMgmt start= DEMAND
@rem Background Intelligent Transf...
一般只有5－6个就够多了，有8个就不正常了，最好安全模式下查下毒
我的也是Windows XP SP2的 我的svchost.exe进程才6个 你怎么会有8个
估计是有病毒了
正常不不正常
其他类似问题
为您推荐：
您可能关注的推广
系统进程的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁