什麼是CPU上下文切換?java
如今linux是大多基於搶佔式,CPU給每一個任務必定的服務時間,當時間片輪轉的時候,須要把當前狀態保存下來,同時加載下一個任務,這個過程叫作上下文切換。時間片輪轉的方式,使得多個任務利用一個CPU執行成爲可能,可是保存現場和加載現場,也帶來了性能消耗。 那線程上下文切換的次數和時間以及性能消耗如何看呢? 如何得到上下文切換的次數? vmstat直接運行便可,在最後幾列,有CPU的context switch次數。 這個是系統層面的,加入想看特定進程的狀況,可使用pidstat。
$ vmstat 1 100 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 88 233484 288756 1784744 0 0 0 23 0 0 4 1 94 0 0 4 0 88 233236 288756 1784752 0 0 0 0 6202 7880 4 1 96 0 0 2 0 88 233360 288756 1784800 0 0 0 112 6277 7612 4 1 95 0 0 0 0 88 232864 288756 1784804 0 0 0 644 5747 6593 6 0 92 2 0
執行pidstat,將輸出系統啓動後全部活動進程的cpu統計信息:
linux:~ # pidstat Linux 2.6.32.12-0.7-default (linux) 06/18/12 _x86_64_ 11:37:19 PID %usr %system %guest %CPU CPU Command …… 11:37:19 11452 0.00 0.00 0.00 0.00 2 bash 11:37:19 11509 0.00 0.00 0.00 0.00 3 dd 11:37:19: pidstat獲取信息時間點 PID: 進程pid %usr: 進程在用戶態運行所佔cpu時間比率 %system: 進程在內核態運行所佔cpu時間比率 %CPU: 進程運行所佔cpu時間比率 CPU: 指示進程在哪一個核運行 Command: 拉起進程對應的命令 備註:執行pidstat默認輸出信息爲系統啓動後到執行時間點的統計信息,於是即便當前某進程的cpu佔用率很高,輸出中的值有可能仍爲0。
上下文切換的性能消耗在哪裏呢? context switch太高,會致使CPU像個搬運工,頻繁在寄存器和運行隊列直接奔波 ,更多的時間花在了線程切換,而不是真正工做的線程上。直接的消耗包括CPU寄存器須要保存和加載,系統調度器的代碼須要執行。間接消耗在於多核cache之間的共享數據。 引發上下文切換的緣由有哪些? 對於搶佔式操做系統而言, 大致有幾種: 一、當前任務的時間片用完以後,系統CPU正常調度下一個任務; 二、當前任務碰到IO阻塞,調度線程將掛起此任務,繼續下一個任務; 三、多個任務搶佔鎖資源,當前任務沒有搶到,被調度器掛起,繼續下一個任務; 四、用戶代碼掛起當前任務,讓出CPU時間; 五、硬件中斷; 如何測試上下文切換的時間消耗? LMbench,知道這個工具,是在霸爺的博客上面(http://blog.yufeng.info/archives/753),而後就開始在測試環境下搞了一把,一會就出結果了。而後就搞了臺線上機器安裝這個工具,而後測試,後面在測試Memory的時候,直接致使Load飆升,還好沒人發現,機器java進程重啓就行了。這方面純粹是業務選手。霸爺說分析的結果對於高性能C的開發同窗來講,是須要熟記的,沒辦法,咱是搞java的,只能每一個指標逐個看一下了。 LMbench的簡單介紹? 首先看英文介紹:LMbench -Tools for Performance Analysis,微觀性能分析工具。 官方地址:http://www.bitmover.com/lmbench/ 下載地址:http://www.bitmover.com/lmbench/lmbench3.tar.gz LMbench主要能幹啥? 主要是帶寬(讀取緩存文件、內存拷貝、讀寫內存、管道等)和反應時間(上下文切換、網路、進程建立等)的評測工具。 LMbench 安裝
#wget http://www.bitmover.com/lmbench/lmbench3.tar.gz #tar -zxvf lmbench3.tar.gz #cd lmbench3 #make 中間遇到一個問題,就是報錯,在CSDN上面找到了答案,這這裏貼一下。 此時會報錯: make[2]: *** 沒有規則能夠建立「bk.ver」須要的目標「../SCCS/s.ChangeSet」。 中止。 make[2]:正在離開目錄 `/home/hero/lmbench3/src' make[1]: *** [lmbench] 錯誤 2 make[1]:正在離開目錄 `/home/hero/lmbench3/src' make: *** [build] 錯誤 2 解決辦法: lmbench3目錄下 #mkdir SCCS #touch ./SCCS/s.ChangeSet #make
LMbench關於結果解釋(此次主要關注線程切換信息) 在網上找了半天,信息不多,只能看doc下面的英文解釋了。 測試上下文切換的時間,一個上下文切換,包括保存一個進程狀態的保存和恢復另一個進程的時間。 典型的上下文切換性能,僅僅是測量最小的線程切換時間。僅僅是作進程切換,任何實質的任務都不作。
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxswlinux
commonway Linux 2.6.18- 9.2400 4.0200 9.0300 7.5600 8.3800 11.6 6.28000
時間的單位是微秒。
緩存
LMbench是如何來測量進程切換的時間的?
The benchmark is a ring of two to twenty processes that are connected
with Unix pipes. A token is passed from process to process, forcing
context switches. The benchmark measures the time it takes to pass
the token two thousand times from process to process. Each hand off
of the token has two costs: (a) the context switch, and (b) the cost
of passing the token. In order to get just the context switching time,the benchmark first measures the cost of passing the token through a
ring of pipes in a single process. This time is defined as the cost
of passing the token and is not included in the reported context switch
time.
.PP
When the processes are larger than the default baseline of ``zero''
(where zero means just big enough to do the benchmark), the cost
of the context switch includes the cost of restoring user level
state (cache lines). This is accomplished by having the process
allocate an array of data and sum it as a series of integers
after receiving the token but before passing the token to the
next process. Note that the overhead mentioned above includes
the cost of accessing the data but because it is measured in
just one address space, the cost is typically the cost with hot
caches. So the context switch time does not include anything
other than the context switch provided that all the processes
fit in the cache. If there are cache misses (as is common), the
cost of the context switch includes the cost of those cache misses.
.PP
首先是看任務處理的時間(經過一次任務處理,這個任務處理的時間被定義爲token時間,不包括線程切換的)。
而後屢次執行,排除任務執行的時間,而後計算出CS的時間(若是有cache miss,則CS的時間也包括cache misses的時間)。bash
文章參考: ide
霸爺和周忱的博客工具
http://www.bitmover.com/lmbench/性能
https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf測試
http://blog.csdn.net/taozi343805436/article/details/7876087 ui