Linux下如何查看高CPU佔用率線程 LINUX CPU利用率計算

 

 

能夠用下面的命令將 cpu 佔用率高的線程找出來:
 ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpuhtml

這個命令首先指定參數'H',顯示線程相關的信息,格式輸出中包含:user,pid,ppid,tid,time,%cpu,cmd,而後再用%cpu字段進行排序。這樣就能夠找到佔用處理器的線程了。java

直接使用 ps Hh -eo pid,tid,pcpu | sort -nk3 |tail 獲取對於的進程號和線程號,而後跳轉到3.
查看哪一個進程線程佔用cpu太高; top / ps -aux, 得到進程號
肯定哪一個線程佔用cpu太高,進入進程號的目錄:/proc/pid/task, 
執行:grep SleepAVG  **/status  | sort -k2,2 | head,  肯定cpu佔用較高的線程號。
使用kill -3 pid 會打印線程堆棧的狀況linux

在 Linux 下 top 工具能夠顯示 cpu 的平均利用率(user,nice,system,idle,iowait,irq,softirq,etc.),能夠顯示每一個 cpu 的利用率。可是沒法顯示每一個線程的 cpu 利用率狀況,這時就可能出現這種狀況,總的 cpu 利用率中 user 或 system 很高,可是用進程的 cpu 佔用率進行排序時,沒有進程的 user 或 system 與之對應。ios


 

 

 

proc文件系統

 

/proc文件系統是一個僞文件系統,它只存在內存當中,而不佔用外存空間。它以文件系統的方式爲內核與進程提供通訊的接口。用戶和應用程序能夠經過/proc獲得系統的信息,並能夠改變內核的某些參數。因爲系統的信息,如進程,是動態改變的,因此用戶或應用程序讀取/proc目錄中的文件時,proc文件系統是動態從系統內核讀出所需信息並提交的。nginx

/proc目錄中有一些以數字命名的目錄,它們是進程目錄。系統中當前運行的每個進程在/proc下都對應一個以進程號爲目錄名的目錄/proc/pid,它們是讀取進程信息的接口。此外,在Linux2.6.0-test6以上的版本中/proc/pid目錄中有一個task目錄,/proc/pid/task目錄中也有一些以該進程所擁有的線程的線程號命名的目錄/proc/pid/task/tid,它們是讀取線程信息的接口。算法

/proc/cpuinfo文件

         該文件中存放了有關 cpu的相關信息(型號,緩存大小等)。shell

[zhengangen@buick ~]$ cat /proc/cpuinfoexpress

processor       : 0api

vendor_id       : GenuineIntel

cpu family      : 15

model           : 4

model name      : Intel(R)Xeon(TM) CPU 3.00GHz

stepping        : 10

cpu MHz         : 3001.177

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 1

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 5

wp              : yes

flags           : fpu vme de psetsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsrsse sse2 ss ht tm pbe lm pni monitor ds_cpl cid xtpr

bogomips        : 6004.52

 

說明:如下只解釋對咱們計算Cpu使用率有用的相關參數。

         參數                            解釋

processor (0)                       cpu的一個物理標識

 

結論1:能夠經過該文件根據processor出現的次數統計cpu的邏輯個數(包括多核、超線程)。

/proc/stat文件

         該文件包含了全部CPU活動的信息,該文件中的全部值都是從系統啓動開始累計到當前時刻。不一樣內核版本中該文件的格式可能不大一致,如下經過實例來講明數據該文件中各字段的含義。

實例數據:2.6.24-24版本上的

 

fjzag@fjzag-desktop:~$cat /proc/stat

cpu  38082 627 27594 89390812256 581 895 0 0

cpu022880 472 16855 430287 10617 576 661 0 0

cpu115202 154 10739 463620 1639 4 234 0 0

intr120053 222 2686 0 1 1 0 5 0 3 0 0 0 47302 0 0 34194 29775 0 5019 845 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

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等待時間(since 2.5.41)

irq (581)           從系統啓動開始累計到當前時刻,硬中斷時間(since 2.6.0-test4)

softirq (895)      從系統啓動開始累計到當前時刻,軟中斷時間(since2.6.0-test4)stealstolen(0)                   which is the time spent in otheroperating systems when running in a virtualized environment(since 2.6.11)

guest(0)                               whichis the time spent running a virtual CPU  for  guest operating systems under the control ofthe Linux kernel(since 2.6.24)

 

結論2:總的cpu時間totalCpuTime = user + nice+ system + idle + iowait + irq + softirq + stealstolen +  guest

/proc/<pid>/stat文件                                          

該文件包含了某一進程全部的活動的信息,該文件中的全部值都是從系統啓動開始累計

到當前時刻。如下經過實例數據來講明該文件中各字段的含義。

 

[zhengangen@buick ~]# cat/proc/6873/stat

6873 (a.out) R 6723 6873 6723 34819 6873 8388608 77 0 0 0 41958 31 0 0 25 0 3 05882654 1409024 56 4294967295 134512640 134513720 3215579040 0 2097798 0 0 0 00 0 0 17 0 0 0

 

說明:如下只解釋對咱們計算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使用率的信息。如下在linux man文檔中對ps命令輸出中有關cpu使用率的解釋:

 

CPU usage is currentlyexpressed as the percentage of time spent running during the entire lifetime ofa process. This is not ideal, and it does not conform to the standards that psotherwise conforms to. CPU usage is unlikely to add up to exactly 100%.

 

%cpu   cpu utilization of the process in"##.#" format. It is the CPU time used                           divided by the timethe process has been running (cputime/realtime ratio),                           expressed as apercentage. It will not add up to 100% unless you are lucky.

 

結論5:ps命令算出來的cpu使用率相對於進程啓動時的平均值,隨着進程運行時間的增大,該值會趨向於平緩。

top命令

經過top命令能夠查看系統中相關進程的實時信息(cpu使用率等)。如下是man文檔中對top命令輸出中有關進程cpu使用率的解釋。

 

#C  -- Last used CPU (SMP)                   Anumber representing the last used processor. In a true  SMP environment  this  will likely change  frequently  since the  kernel intentionally usesweak affinity.  Also, the very act ofrunning top may break this weak affinity and cause more processes to  change CPUs  more  often (because of the extra demand for cputime).

 

%CPU  --  CPUusage                   The  task’s share ofthe elapsed CPU time since the last screen update, expressed as a percent-ageof total CPU time.  In a true SMP environment, if  Irix mode is Off, top will operate in Solaris modewhere a task’s cpu usage will be divided by the total number of CPUs.

 

結論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使用率計算

計算方法:

一、  採樣兩個足夠短的時間間隔的Cpu快照,分別記做t1,t2,其中t一、t2的結構均爲:

(user、nice、system、idle、iowait、irq、softirq、stealstolen、guest)的9元組;

二、  計算總的Cpu時間片totalCpuTime

a)        把第一次的全部cpu使用狀況求和,獲得s1;

b)        把第二次的全部cpu使用狀況求和,獲得s2;

c)        s2 - s1獲得這個時間間隔內的全部時間片,即totalCpuTime = j2 - j1 ;

三、計算空閒時間idle

idle對應第四列的數據,用第二次的第四列- 第一次的第四列便可

idle=第二次的第四列- 第一次的第四列

六、計算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.              分別根據結論二、結論3計算出兩個時刻的總的cpu時間與進程的cpu時間,分別記做:totalCpuTime一、totalCpuTime二、processCpuTime一、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

 

PID    USER      PR   NI   VIRT   RES   SHR   S  %CPU %MEM  TIME+  COMMAND 

7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:00.74 java              

 7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:03.71 java              

 7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:06.67 java              

 7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:09.63 java              

 7639 fjzag     20   0  206m  10m 7136 S   98  2.2   1:12.59 java              

 7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:15.55 java              

 7639 fjzag     20   0  206m  10m 7136 S  100  2.2   1:18.55 java              

 7639 fjzag     20   0  206m  10m 7136 S  100  2.2   1:21.54 java              

 7639 fjzag     20   0  206m  10m 7136 S   99  2.2   1:24.52 java              

 7639 fjzag     20   0  206m  10m 7136 S   98  2.2   1:27.46 java

 

實驗二: 監控jconsole進程的cpu使用率。

說明:左邊的數據是按以上算法獲得的數據,其中採樣的時間間隔與top命令刷新屏幕的時間間隔相同。

按以上方法計算獲得的cpu使用率

經過top命令獲得的

 

8.681135

12.0

10.350584

7.6539097

7.6539097

5.0

13.021703

11.0

8.666667

PID   USER      PR   NI  VIRT   RES   SHR  S  %CPU %MEM  TIME+  COMMAND 

7753 fjzag     20   0  252m  72m  22m S   10 14.4   0:18.70 jconsole          

 7753 fjzag     20   0  252m  72m  22m S   12 14.4   0:19.07 jconsole          

 7753 fjzag     20   0  252m  72m  22m S   11 14.4   0:19.39 jconsole          

 7753 fjzag     20   0  252m  72m  22m S    7 14.4   0:19.61 jconsole          

 7753 fjzag     20   0  252m  72m  22m S    7 14.4   0:19.83 jconsole          

 7753 fjzag     20   0  252m  72m  22m S    5 14.4   0:19.97 jconsole          

 7753 fjzag     20   0  252m  72m  22m S   14 14.4   0:20.38 jconsole          

 7753 fjzag     20   0  252m  72m  22m S   10 14.4   0:20.68 jconsole          

 7753 fjzag     20   0  252m  72m  22m S    9 14.5   0:20.96 jconsole

某一線程Cpu使用率的計算

計算方法:  

1.              採樣兩個足夠短的時間隔的cpu快照與線程快照,

a)        每個cpu快照均爲(user、nice、system、idle、iowait、irq、softirq、stealstealon、guest)的9元組;

b)        每個線程快照均爲 (utime、stime)的2元組;

2.              分別根據結論二、結論4計算出兩個時刻的總的cpu時間與線程的cpu時間,分別記做:totalCpuTime一、totalCpuTime二、threadCpuTime一、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

PID    USER      PR   NI   VIRT   RES   SHR   S  %CPU %MEM  TIME+  COMMAND 

7649 fjzag     20   0  206m  10m 7136 R   97  2.2   7:22.94 java              

 7649 fjzag     20   0  206m  10m 7136 R   97  2.2   7:25.86 java              

 7649 fjzag     20   0  206m  10m 7136 R   97  2.2   7:28.76 java              

 7649 fjzag     20   0  206m  10m 7136 R   99  2.2   7:31.72 java              

 7649 fjzag     20   0  206m  10m 7136 R   98  2.2   7:34.65 java              

 7649 fjzag     20   0  206m  10m 7136 R   96  2.2   7:37.53 java              

 7649 fjzag     20   0  206m  10m 7136 R   98  2.2   7:40.47 java              

 7649 fjzag     20   0  206m  10m 7136 R   96  2.2   7:43.34 java              

 7649 fjzag     20   0  206m  10m 7136 R   97  2.2   7:46.25 java

 

實驗二: 監控jconsole程序某一線程的cpu使用率。

說明:左邊的數據是按以上算法獲得的數據,其中採樣的時間間隔與top命令刷新屏幕的時間間隔相同。

按以上方法計算獲得的cpu使用率

經過top命令獲得的

 

1.3400335

6.644518

1.3333334

0.6677796

0.6666667

1.3333334

1.3333334

 PID    USER      PR   NI   VIRT   RES  SHR  S  %CPU %MEM  TIME+  COMMAND 

7755 fjzag     20   0  251m  72m  22m S    1 14.4   0:11.92 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    7 14.4   0:12.12 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    2 14.4   0:12.18 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    0 14.4   0:12.18 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    1 14.4   0:12.20 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    1 14.4   0:12.24 jconsole          

 7755 fjzag     20   0  251m  72m  22m S    1 14.4   0:12.28 jconsole

多核狀況下cpu使用率的計算                                                    

如下經過實驗數據來講明多核狀況下某一進程cpu使用率是按cpu個數*100%計算的.

實驗一

描述:

雙核的狀況下做的一組實驗,第一組數據是經過ps  -eLo pid,lwp,pcpu | grep 9140命令查看進程號爲9140的進程中各線程的詳細信息。第二組數據是經過 ps命令查看進程號爲9140進程的cpu使用率。

數據一:

pid   lwp  %cpu

9140  9140  0.0
 9140  9141  0.0
 9140  9142  0.0
 9140  9143  0.0
 9140  9144  0.0
 9140  9149  0.0
 9140  9150  0.0
 9140  9151  0.0
 9140  9152  0.1
 9140  9153 96.6                         該線程是一個空循環
 9140  9154 95.9                         該線程是一個空循環

以上除了紅色標註出來的兩個線程之外,其餘的線程都是後臺線程。

數據二:

pid   %cpu

9140  193

實驗二

描述:

單核的狀況下做的一組實驗,第一組數據是經過ps  -eLo pid,lwp,pcpu | grep 6137命令查看進程號爲6137的進程中各線程的詳細信息。第二組數據是經過 ps命令查看進程號爲6137進程的cpu使用率。

數據一:

 pid    lwp  %cpu

 6137 6137  0.0

 6137 6138  0.1

 6137 6143  0.0

 6137 6144  0.0

 6137 6145  0.0

 6137 6146  0.0

 6137 6147  0.0

 6137 6148  0.0

 6137 6149  0.0

 6137 6150 46.9                                                 空循環線程

 6137 6151 46.9                                                 空循環線程

以上除了紅色標註出來的兩個線程之外,其餘的線程都是後臺線程。

數據二

pid %cpu

6137 92.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:                    which is thetime spent in other operating

systems whenrunning in a virtualized environment

2.6.24新增字段:guest:                                    whichis the time spent running a virtual CPU  for  guest operating systems under the control ofthe Linux kernel

2./proc/pid/task目錄是Linux 2.6.0-test6以後纔有的功能。

 

3.關於出現cpu使用率爲負的狀況,目前想到的解決方案是若是出現負值,連續採樣計算cpu使用率直到爲非負。

 

4.有些線程生命週期較短,可能在咱們採樣期間就已經死掉了.

 

 

 

php-cgi進程佔用cpu資源過多負載高的緣由分析及解決步驟

 

 

服務器環境:redhat linux 5.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. 程序中存在過分耗時且不可能完成的操做(仍是程序的問題),例如discuz x 1.5的附件下載功能: source/module/forum/forum_attachement.php中的定義

 

function getremotefile($file) {
    global $_G;
    @set_time_limit(0);
    if(!@readfile($_G['setting']['ftp']['attachurl'].'forum/'.$file)) {
        $ftp = ftpcmd('object');
        $tmpfile = @tempnam($_G['setting']['attachdir'], '');
        if($ftp->ftp_get($tmpfile, 'forum/'.$file, FTP_BINARY)) {
            @readfile($tmpfile);
            @unlink($tmpfile);
        } else {
            @unlink($tmpfile);
            return FALSE;
        }
    }
    return TRUE;
}

 

沒有對傳入的參數做任何初步檢查,並且設置了永不超時,而且使用readfile一次讀取超大文件,就可能存在如下問題:
 A. 以http方式讀取遠程附件過分耗時

 B. FTP沒法鏈接時,如何及時反饋出錯誤?

 C. readfile是一次性讀取文件加載到內存中並輸出,當文件過大時,內存消耗驚人

      根據實驗發現採用readfile一次性讀取,內存消耗會明顯增長,可是CPU的利用率會降低較多。若是採用分段讀取的方式,內存消耗會稍微降低,而CPU佔用卻會明顯上升。

 

對discuz x 1.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`
 
for n in $f
do  
    r=`egrep 'view_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.cnblogs.com/cute/archive/2011/04/20/2022280.html


最近對個人本本(4核8線程)用top命令看系統情況出現了CPU利用率超過200%的狀況,很是詫異,查了下相關資料,把這個問題弄清楚了。
首先來分析下CPU Load

load average: 0.09, 0.05, 0.01

分別是1分鐘、5分鐘、15分鐘的平均Load。
Load這個東西怎麼理解呢,就像一條馬路,有N個車道,若是N個進程進入車道,那麼正好一人一個,再多一輛車就佔不到車道,要等有一個車空出車道。
在CPU中能夠理解爲CPU能夠並行處理的任務數,那麼就是「CPU個數 * 核數」,若是CPU Load = CPU個數 * 核數 那麼就是說CPU正好滿負載,再多一點,可能就要出問題了,有任務不能被及時分配處理器,那麼保證性能的話,最好是小於CPU個數 * 核數 *0.7。

查看CPU核數能夠經過:grep ‘model name’ /proc/cpuinfo

那麼以哪一個平均值爲準呢?若是1分鐘平均出現大於CPU個數 * 核數的狀況,還不用擔憂,若是5分鐘平均也是,那就要警戒了,15分鐘平均也是這樣,就要分析哪裏出問題了,防範於未然
CPU利用率超過100%的問題,也是差很少,top命令應該是把每一個核的CPU佔用率加起來,算一個和,因而多核狀況下會出現超過100%。

另外Context Switch Rate也是個很是值得注意的值,由於線程間切換的代價也是很是高的。

引用一個公式:Context Switch Rate = Interrupt Rate + TPS* N

對於一個多線程的程序,我以爲準備一個控制線程來調度任務是很是必要的,省得線程過於高併發,致使資源的爭用和線程切換帶來性能問題,最好控制併發的線程數基本等於CPU的總核數,減小這個N,得到更好的處理器性能。

 

 

Java 系統性能分析 命令  

1. cpu分析     top , pidstat(sysstat)     pid -p PID -t 1 10     vmstat 1  CPU上下文切換、運行隊列、利用率     ps Hh -eo tid     pcpu 查看具體線程的CPU消耗     sar  來查看必定世界範圍內以及歷史的cpu消耗狀況信息     查看java線程信息     jstack pid | grep 'nid=0x9999'      2. cs sy消耗比較高     上下文切換性能偏高, jstack -l pid, 查看on object monitor  3. io消耗     pidstat -d -t -p pid 1 100     iostat  4. 網絡io消耗     cat /proc/interruptes     sar -n FULL 1 2     tcpdump
相關文章
相關標籤/搜索