来一发CentOS下找出占用CPU资本最多的线程处理器,system,Linux,资源,信息

只想知道 发表于 2015-1-14 20:12:40

来一发CentOS下找出占用CPU资本最多的线程

如果您觉得本篇CentOSLinux教程讲得好，请记得点击右边漂浮的分享程序，把好文章分享给你的小伙伴们！1.对这个历程中的一切线程作监督:top-ppid-H
2.找到最耗CPU的线程:ps-mppid-oTHREAD,tid,time大概ps-Lfppid
3.也能够用上面的下令将cpu占用率高的线程找出来:
psH-eouser,pid,ppid,tid,time,%cpu,cmd--sort=%cpu
这个下令起首指定参数H，显现线程相干的信息，格局输入中包括:user,pid,ppid,tid,time,%cpu,cmd，然后再用%cpu字段举行排序。如许就能够找到占用途理器的线程了。
间接利用psHh-eopid,tid,pcpu|sort-nk3|tail猎取关于的历程号和线程号，然后跳转到3.
检察哪一个历程线程占用cpu太高；top/ps-aux，取得历程号
断定哪一个线程占用cpu太高，进进历程号的目次：/proc/pid/task，
实行：grepSleepAVG**/status|sort-k2,2|head，断定cpu占用较高的线程号。
利用kill-3pid会打印线程仓库的情形
在Linux下top工具能够显现cpu的均匀使用率(user,nice,system,idle,iowait,irq,softirq,etc.)，能够显现每一个cpu的使用率。可是没法显现每一个线程的cpu使用率情形，这时候便可能呈现这类情形，总的cpu使用率中user或system很高，可是用历程的cpu占用率举行排序时，没有历程的user或system与之对应。
proc文件体系

/proc文件体系是一个伪文件体系，它只存在内存傍边，而不占用外存空间。它以文件体系的体例为内核与历程供应通讯的接口。用户和使用步伐能够经由过程/proc失掉体系的信息，并能够改动内核的某些参数。因为体系的信息，如历程，是静态改动的，以是用户或使用步伐读取/proc目次中的文件时，proc文件体系是静态从体系内核读出所需信息并提交的。
/proc目次中有一些以数字定名的目次，它们是历程目次。体系中以后运转的每个历程在/proc下都对应一个以历程号为目次名的目次/proc/pid，它们是读取历程信息的接口。别的，在Linux2.6.0-test6以上的版本中/proc/pid目次中有一个task目次，/proc/pid/task目次中也有一些以该历程所具有的线程的线程号定名的目次/proc/pid/task/tid，它们是读取线程信息的接口。
/proc/cpuinfo文件

该文件中寄存了有关cpu的相干信息(型号，缓存巨细等)。
$cat/proc/cpuinfo
processor:0
vendor_id:GenuineIntel
cpufamily:15
model:4
modelname:Intel(R)Xeon(TM)CPU3.00GHz
stepping:10
cpuMHz:3001.177
cachesize:2048KB
physicalid:0
siblings:2
coreid:0
cpucores:1
fdiv_bug:no
hlt_bug:no
f00f_bug:no
coma_bug:no
fpu:yes
fpu_exception:yes
cpuidlevel:5
wp:yes
flags:fpuvmedepsetscmsrpaemcecx8apicmtrrpgemcacmovpatpse36clflushdtsacpimmxfxsrssesse2sshttmpbelmpnimonitords_cplcidxtpr
bogomips:6004.52

申明：以下只注释对我们盘算Cpu利用率有效的相干参数。
参数注释
processor(0)cpu的一个物理标识

结论1：能够经由过程该文件依据processor呈现的次数统计cpu的逻辑个数(包含多核、超线程)。
/proc/stat文件

该文件包括了一切CPU举动的信息，该文件中的一切值都是从体系启动入手下手累计到以后时候。分歧内核版本中该文件的格局大概不年夜分歧，以下经由过程实例来讲明数据该文件中各字段的寄义。
实例数据：2.6.24-24版本上的

fjzag@fjzag-desktop:~$cat/proc/stat
cpu38082627275948939081225658189500
cpu022880472168554302871061757666100
cpu115202154107394636201639423400
intr120053222268601105030004730200341942977505019845000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
ctxt1434984
btime1252028243
processes8113
procs_running1
procs_blocked0
第一行的数值暗示的是CPU总的利用情形，以是我们只需用第一行的数字盘算就能够了。下表剖析第一行各数值的寄义：
参数剖析（单元：jiffies）
(jiffies是内核中的一个全局变量，用来纪录自体系启动一来发生的节奏数，在linux中，一个节奏大抵可了解为操纵体系历程调剂的最小工夫片，分歧linux内核大概值有分歧，一般在1ms到10ms之间)
user(38082)从体系启动入手下手累计到以后时候，处于用户态的运转工夫，不包括nice值为负历程。
nice(627)从体系启动入手下手累计到以后时候，nice值为负的历程所占用的CPU工夫
system(27594)从体系启动入手下手累计到以后时候，处于中心态的运转工夫
idle(893908)从体系启动入手下手累计到以后时候，除IO守候工夫之外的别的守候工夫iowait(12256)从体系启动入手下手累计到以后时候，IO守候工夫(since2.5.41)
irq(581)从体系启动入手下手累计到以后时候，硬中止工夫(since2.6.0-test4)
softirq(895)从体系启动入手下手累计到以后时候，软中止工夫(since2.6.0-test4)stealstolen(0)whichisthetimespentinotheroperatingsystemswhenrunninginavirtualizedenvironment(since2.6.11)
guest(0)whichisthetimespentrunningavirtualCPUforguestoperatingsystemsunderthecontroloftheLinuxkernel(since2.6.24)

结论2：总的cpu工夫totalCpuTime=user+nice+system+idle+iowait+irq+softirq+stealstolen+guest
/proc/<pid>/stat文件

该文件包括了某一历程一切的举动的信息，该文件中的一切值都是从体系启动入手下手累计
到以后时候。以下经由过程实例数据来讲明该文件中各字段的寄义。

#cat/proc/6873/stat
6873(a.out)R6723687367233481968738388608770004195831002503058826541409024564294967295134512640134513720321557904002097798000000017000

申明：以下只注释对我们盘算Cpu利用率有效相干参数
参数注释
pid=6873历程号
utime=1587该义务在用户态运转的工夫，单元为jiffies
stime=41958该义务在中心态运转的工夫，单元为jiffies
cutime=0一切已逝世线程在用户态运转的工夫，单元为jiffies
cstime=0一切已逝世在中心态运转的工夫，单元为jiffies

结论3：历程的总Cpu工夫processCpuTime=utime+stime+cutime+cstime，该值包含其一切线程的cpu工夫。
/proc/<pid>/task/<tid>/stat文件

该文件包括了某一历程一切的举动的信息，该文件中的一切值都是从体系启动入手下手累计到以后时候。该文件的内容格局和各字段的寄义同/proc/<pid>/stat文件。
注重，该文件中的tid字段暗示的不再是历程号，而是linux中的轻量级历程(lwp)，即我们一般所说的线程。

结论4：线程Cpu工夫threadCpuTime=utime+stime
体系中有关历程cpu利用率的经常使用下令

ps下令

经由过程ps下令能够检察体系中相干历程的Cpu利用率的信息。以下在linuxman文档中对ps下令输入中有关cpu利用率的注释：

CPUusageiscurrentlyexpressedasthepercentageoftimespentrunningduringtheentirelifetimeofaprocess.Thisisnotideal,anditdoesnotconformtothestandardsthatpsotherwiseconformsto.CPUusageisunlikelytoadduptoexactly100%.

%cpucpuutilizationoftheprocessin"##.#"format.ItistheCPUtimeuseddividedbythetimetheprocesshasbeenrunning(cputime/realtimeratio),expressedasapercentage.Itwillnotaddupto100%unlessyouarelucky.

结论5：ps下令算出来的cpu利用率相对历程启动时的均匀值，跟着历程运转工夫的增年夜，该值会趋势于陡峭。
top下令

经由过程top下令能够检察体系中相干历程的及时信息（cpu利用率等）。以下是man文档中对top下令输入中有关历程cpu利用率的注释。

#C--LastusedCPU(SMP)Anumberrepresentingthelastusedprocessor.InatrueSMPenvironmentthiswilllikelychangefrequentlysincethekernelintentionallyusesweakaffinity.Also,theveryactofrunningtopmaybreakthisweakaffinityandcausemoreprocessestochangeCPUsmoreoften(becauseoftheextrademandforcputime).

%CPU--CPUusageThetask’sshareoftheelapsedCPUtimesincethelastscreenupdate,expressedasapercent-ageoftotalCPUtime.InatrueSMPenvironment,ifIrixmodeisOff,topwilloperateinSolarismodewhereatask’scpuusagewillbedividedbythetotalnumberofCPUs.

结论6：某一个线程在其运转时代其所利用的cpu大概会产生变更。
结论7：在多核的情形下top下令输入的cpu利用率本色是按cpu个数*100%盘算的。
单核情形下Cpu利用率的盘算

基础头脑

经由过程读取/proc/stat、/proc/<pid>/stat、/proc/<pid>/task/<tid>/stat和/proc/cpuinfo这几个文件猎取总的Cpu工夫、历程的Cpu工夫、线程的Cpu工夫和Cpu的个数的信息，然后经由过程必定的算法举行盘算(采样两个充足短的工夫距离的Cpu快照与历程快照来盘算历程的Cpu利用率)。

总的Cpu利用率盘算

盘算***：

1、采样两个充足短的工夫距离的Cpu快照，分离记作t1,t2，个中t1、t2的布局均为：
(user、nice、system、idle、iowait、irq、softirq、stealstolen、guest)的9元组;
2、盘算总的Cpu工夫片totalCpuTime
a)把第一次的一切cpu利用情形乞降，失掉s1;
b)把第二次的一切cpu利用情形乞降，失掉s2;
c)s2-s1失掉这个工夫距离内的一切工夫片，即totalCpuTime=j2-j1;
3、盘算余暇工夫idle
idle对应第四列的数据，用第二次的第四列-第一次的第四列便可
idle=第二次的第四列-第一次的第四列
6、盘算cpu利用率
pcpu=100*(total-idle)/total
某一历程Cpu利用率的盘算

盘算***：

1．采样两个充足短的工夫距离的cpu快照与历程快照，
a)每个cpu快照均为(user、nice、system、idle、iowait、irq、softirq、stealstolen、guest)的9元组;
b)每个历程快照均为(utime、stime、cutime、cstime)的4元组；
2．分离依据结论2、结论3盘算出两个时候的总的cpu工夫与历程的cpu工夫，分离记作：totalCpuTime1、totalCpuTime2、processCpuTime1、processCpuTime2
3．盘算该历程的cpu利用率pcpu=100*(processCpuTime2–processCpuTime1)/(totalCpuTime2–totalCpuTime1)(按100%盘算，假如是多核情形下还需乘以cpu的个数);
实行数据

实行一:监控一空轮回的历程的cpu利用率。
申明：右边的数据是按以上算法失掉的数据，个中采样的工夫距离与top下令革新屏幕的工夫距离不异。
按以上***盘算失掉的cpu利用率
经由过程top下令失掉的

99.50083
98.333336
98.0
98.83138
99.0
99.0
99.83361
98.83527
98.4975

PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND
7639fjzag200206m10m7136S992.21:00.74java
7639fjzag200206m10m7136S992.21:03.71java
7639fjzag200206m10m7136S992.21:06.67java
7639fjzag200206m10m7136S992.21:09.63java
7639fjzag200206m10m7136S982.21:12.59java
7639fjzag200206m10m7136S992.21:15.55java
7639fjzag200206m10m7136S1002.21:18.55java
7639fjzag200206m10m7136S1002.21:21.54java
7639fjzag200206m10m7136S992.21:24.52java
7639fjzag200206m10m7136S982.21:27.46java

实行二:监控jconsole历程的cpu利用率。
申明：右边的数据是按以上算法失掉的数据，个中采样的工夫距离与top下令革新屏幕的工夫距离不异。
按以上***盘算失掉的cpu利用率
经由过程top下令失掉的

8.681135
12.0
10.350584
7.6539097
7.6539097
5.0
13.021703
11.0
8.666667
PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND
7753fjzag200252m72m22mS1014.40:18.70jconsole
7753fjzag200252m72m22mS1214.40:19.07jconsole
7753fjzag200252m72m22mS1114.40:19.39jconsole
7753fjzag200252m72m22mS714.40:19.61jconsole
7753fjzag200252m72m22mS714.40:19.83jconsole
7753fjzag200252m72m22mS514.40:19.97jconsole
7753fjzag200252m72m22mS1414.40:20.38jconsole
7753fjzag200252m72m22mS1014.40:20.68jconsole
7753fjzag200252m72m22mS914.50:20.96jconsole
某一线程Cpu利用率的盘算

盘算***：

1．采样两个充足短的工夫隔的cpu快照与线程快照，
a)每个cpu快照均为(user、nice、system、idle、iowait、irq、softirq、stealstealon、guest)的9元组;
b)每个线程快照均为(utime、stime)的2元组；
2．分离依据结论2、结论4盘算出两个时候的总的cpu工夫与线程的cpu工夫，分离记作：totalCpuTime1、totalCpuTime2、threadCpuTime1、threadCpuTime2
3．盘算该线程的cpu利用率pcpu=100*(threadCpuTime2–threadCpuTime1)/(totalCpuTime2–totalCpuTime1)(按100%盘算，假如是多核情形下还需乘以cpu的个数);
实行数据

实行一:监控一空轮回的线程的cpu利用率。
申明：右边的数据是按以上算法失掉的数据，个中采样的工夫距离与top下令革新屏幕的工夫距离不异。
按以上***盘算失掉的cpu利用率
经由过程top下令失掉的

98.83138
97.00997
96.98997
97.49583
98.169716
96.8386
97.333336
93.82304
98.66667
PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND
7649fjzag200206m10m7136R972.27:22.94java
7649fjzag200206m10m7136R972.27:25.86java
7649fjzag200206m10m7136R972.27:28.76java
7649fjzag200206m10m7136R992.27:31.72java
7649fjzag200206m10m7136R982.27:34.65java
7649fjzag200206m10m7136R962.27:37.53java
7649fjzag200206m10m7136R982.27:40.47java
7649fjzag200206m10m7136R962.27:43.34java
7649fjzag200206m10m7136R972.27:46.25java

实行二:监控jconsole步伐某一线程的cpu利用率。
申明：右边的数据是按以上算法失掉的数据，个中采样的工夫距离与top下令革新屏幕的工夫距离不异。
按以上***盘算失掉的cpu利用率
经由过程top下令失掉的

1.3400335
6.644518
1.3333334
0.6677796
0.6666667
1.3333334
1.3333334
PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND
7755fjzag200251m72m22mS114.40:11.92jconsole
7755fjzag200251m72m22mS714.40:12.12jconsole
7755fjzag200251m72m22mS214.40:12.18jconsole
7755fjzag200251m72m22mS014.40:12.18jconsole
7755fjzag200251m72m22mS114.40:12.20jconsole
7755fjzag200251m72m22mS114.40:12.24jconsole
7755fjzag200251m72m22mS114.40:12.28jconsole
多核情形下cpu利用率的盘算

以下经由过程实行数据来讲明多核情形下某一历程cpu利用率是按cpu个数*100%盘算的.
实行一

形貌:

在双核的情形下作的一组实行，第一组数据是经由过程ps-eLopid,lwp,pcpu|grep9140下令检察历程号为9140的历程中各线程的具体信息。第二组数据是经由过程ps下令检察历程号为9140历程的cpu利用率。
数据一：

pidlwp%cpu
914091400.0
914091410.0
914091420.0
914091430.0
914091440.0
914091490.0
914091500.0
914091510.0
914091520.1
9140915396.6该线程是一个空轮回
9140915495.9该线程是一个空轮回
以上除白色标注出来的两个线程之外,其他的线程都是背景线程。
数据二：

pid%cpu
9140193
实行二

形貌：

在单核的情形下作的一组实行，第一组数据是经由过程ps-eLopid,lwp,pcpu|grep6137下令检察历程号为6137的历程中各线程的具体信息。第二组数据是经由过程ps下令检察历程号为6137历程的cpu利用率。
数据一：

pidlwp%cpu
613761370.0
613761380.1
613761430.0
613761440.0
613761450.0
613761460.0
613761470.0
613761480.0
613761490.0
6137615046.9空轮回线程
6137615146.9空轮回线程
以上除白色标注出来的两个线程之外,其他的线程都是背景线程。
数据二

pid%cpu
613792.9
次要成绩：

1.分歧内核版本/proc/stat文件格局不年夜分歧。/proc/stat文件中第一举动总的cpu利用情形。
各个版本都有的4个字段:user、nice、system、idle
2.5.41版本新增字段：iowait
2.6.0-test4新增字段：irq、softirq
2.6.11新增字段：stealstolen：whichisthetimespentinotheroperating
systemswhenrunninginavirtualizedenvironment
2.6.24新增字段：guest:whichisthetimespentrunningavirtualCPUforguestoperatingsystemsunderthecontroloftheLinuxkernel
2．/proc/pid/task目次是Linux2.6.0-test6以后才有的功效。

3．关于呈现cpu利用率为负的情形，今朝想到的办理计划是假如呈现负值，一连采样盘算cpu利用坦白到为非负。

4.有些线程性命周期较短,大概在我们采样时代就已逝世失落了.

php-cgi历程占用cpu资本过量负载高的缘故原由剖析及办理步调

办事器情况：redhatlinux5.5,nginx,phpfastcgi

在此情况下，一样平常php-cgi运转长短常不乱的，但也碰到过php-cgi占用太多cpu资本而招致办事器呼应过慢，我所碰到的php-cgi历程占用cpu资本过量的缘故原由有：

1.一些php的扩大与php版本兼容存在成绩，理论证实eAccelerater与某些php版本兼容存在成绩，详细体现时启动php-cgi历程后，运转10多分钟，奇慢非常，但静态资本会见很快，办事器负载也很一般（申明nginx没有成绩，而是php-cgi历程的成绩），办理举措就是从php.ini中克制失落eAccelerater模块，再重启php-cgi历程便可

2.步伐中大概存在逝世轮回，招致办事器负载超高（利用top指令检察负载高达100+）,必要借助Linux的proc假造文件体系找到详细的成绩步伐

3.php步伐分歧理利用session,这个产生在开源微博记事狗步伐上，详细体现是有大批php-cgi历程（不凌驾10个）的cpu利用率达98%以上，办事器负载在4-8之间，这个成绩的办理，仍旧必要借助Linux的proc文件体系找出缘故原由。

4.步伐中存在过分耗时且不成能完成的操纵（仍是步伐的成绩），比方discuzx1.5的附件下载功效:source/module/forum/forum_attachement.php中的界说

functiongetremotefile($file){
global$_G;
@set_time_limit(0);
if(!@readfile($_G.forum/.$file)){
$ftp=ftpcmd(object);
$tmpfile=@tempnam($_G,);
if($ftp->ftp_get($tmpfile,forum/.$file,FTP_BINARY)){
@readfile($tmpfile);
@unlink($tmpfile);
}else{
@unlink($tmpfile);
returnFALSE;
}
}
returnTRUE;
}

没有对传进的参数作任何开端反省，并且设置了永不超时，而且利用readfile一次读取超年夜文件，便可能存在以下成绩：
A.以http体例读取近程附件过分耗时
B.FTP没法毗连时，怎样实时反应堕落误？
C.readfile是一次性读取文件加载到内存中并输入，当文件过年夜时，内存损耗惊人
依据实行发明接纳readfile一次性读取，内存损耗会分明增添，可是CPU的使用率会下落较多。假如接纳分段读取的体例，内存损耗会略微下落，而CPU占用却会分明上升。

对discuzx1.5的这个bug较好办理***就是背景从头准确设置近程附件参数。

以下是我慢慢收拾的妨碍扫除步调：
1.失掉占用cpu资本过量的php-cgi历程的pid(历程id)，利用top下令便可，以下图：

经由上图，我们发明，有两个php-cgi历程的cpu资本占用率太高，pid分离是10059，11570，这一样平常都是步伐优化不敷形成，怎样定位成绩的php步伐地位？

2.找出历程所利用的文件
/proc/文件体系保留在内存中，次要保留体系的形态，关头设置等等，而/proc/目次下有良多数字目次，就是历程的相干信息，以下图，我们看看历程10059正在利用哪些文件？

明显，利用了/home/tmp/sess_*文件，这分明是PHP的session文件，我们检察这个session文件的内容为：view_time|123333312412

到这里，我们已能够嫌疑是因为php步伐写进一个叫view_time的session项而引发，那末残剩的事务就是反省包括view_time的一切php文件，然后修正之（好比改用COOKIE），这假话，这个view_time并不是敏感数据，仅仅纪录用户最初会见工夫，其实没需要利用价值伟大的session,而应当利用cookie。

3.找出有成绩的步伐，修正之
利用vi编纂以下shell步伐（假定网站步伐位于/www目次下）

#!/bin/bash
find/www/-name"*.php">list.txt

f=`cat./list.txt`

fornin$f
do
r=`egrepview_time$n`
if[!"$r"=""];then
echo$n
fi
done

运转这个shell步伐，将输入包括有view_time的文件，对记事狗微博体系，发生的成绩位于modules/topic.mod.class文件中

http://blog.csdn.net/turkeyzhou/article/details/6709953
http://www.ckuyun.com/cute/archive/2011/04/20/2022280.html

比来对我的本本（4核8线程）用top下令看体系情况呈现了CPU使用率凌驾200%的情形，十分惊奇，查了下相干材料，把这个成绩弄分明了。
起首来剖析下CPULoad
loadaverage:0.09,0.05,0.01
分离是1分钟、5分钟、15分钟的均匀Load。
Load这个器材怎样了解呢，就像一条马路，有N个车道，假如N个历程进进车道，那末恰好一人一个，再多一辆车就占不到车道，要等有一个车空出车道。
在CPU中能够了解为CPU能够并行处置的义务数，那末就是“CPU个数*核数”，假如CPULoad=CPU个数*核数那末就是说CPU恰好满负载，再多一点，大概就要出成绩了，有义务不克不及被实时分派处置器，那末包管功能的话，最好是小于CPU个数*核数*0.7。
检察CPU核数能够经由过程：grep‘modelname’/proc/cpuinfo
那末以哪一个均匀值为准呢？假如1分钟均匀呈现年夜于CPU个数*核数的情形，还不必忧虑，假如5分钟均匀也是，那就要小心了，15分钟均匀也是如许，就要剖析那里出成绩了，提防于已然
CPU使用率凌驾100%的成绩，也是差未几，top下令应当是把每一个核的CPU占用率加起来，算一个和，因而多核情形下会呈现凌驾100%。
别的ContextSwitchRate也是个十分值得注重的值，由于线程间切换的价值也长短常高的。
援用一个公式：ContextSwitchRate=InterruptRate+TPS*N
关于一个多线程的步伐，我以为筹办一个把持线程来调剂义务长短常需要的，以免线程过于高并发，招致资本的争用和线程切换带来功能成绩，最好把持并发的线程数基础即是CPU的总核数，削减这个N，取得更好的处置器功能。

Java体系功能剖析下令

1.cpu剖析
top，pidstat(sysstat)
pid-pPID-t110
vmstat1CPU高低文切换、运转行列、使用率
psHh-eotid
pcpu检察详细线程的CPU损耗
sar来检察必定天下局限内和汗青的cpu损耗情形信息

检察java线程信息
jstackpid|grepnid=0x9999

2.cssy损耗对照高
高低文切换功能偏高，jstack-lpid,检察onobjectmonitor

3.io损耗
pidstat-d-t-ppid1100
iostat

4.收集io损耗
cat/proc/interruptes
sar-nFULL12
tcpdump

欢迎大家来到仓酷云论坛！

小魔女 发表于 2015-1-14 23:14:21