能夠用下面的命令將 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文件系統是動態從系統內核讀出所需信息並提交的。nginx
/proc目錄中有一些以數字命名的目錄,它們是進程目錄。系統中當前運行的每個進程在/proc下都對應一個以進程號爲目錄名的目錄/proc/pid,它們是讀取進程信息的接口。此外,在Linux2.6.0-test6以上的版本中/proc/pid目錄中有一個task目錄,/proc/pid/task目錄中也有一些以該進程所擁有的線程的線程號命名的目錄/proc/pid/task/tid,它們是讀取線程信息的接口。算法
該文件中存放了有關 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的邏輯個數(包括多核、超線程)。
該文件包含了全部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
該文件包含了某一進程全部的活動的信息,該文件中的全部值都是從系統啓動開始累計
到當前時刻。如下經過實例數據來講明該文件中各字段的含義。
[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>/stat文件。
注意,該文件中的tid字段表示的再也不是進程號,而是linux中的輕量級進程(lwp),即咱們一般所說的線程。
結論4:線程Cpu時間threadCpuTime = utime +stime
經過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命令能夠查看系統中相關進程的實時信息(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%計算的。
經過讀取/proc/stat 、/proc/<pid>/stat、/proc/<pid>/task/<tid>/stat以及/proc/cpuinfo這幾個文件獲取總的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
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 |
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個數*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,得到更好的處理器性能。