如何測量上下文切換時間

LINUX查看指定進程的Context Switch上下文切換:pidstat

Context Switch（CS）上下文切換是cpu性能中的一個重要指標，context switch太高會致使CPU像個搬運工，頻繁在寄存器和運行隊列之間奔波  ，更多的時間花在了線程切換，而不是真正工做的線程上。

linux中通常使用vmstat監控系統上下文切換，pidstat監控指定進程的上下文切換。

pidstat監控指定進程的Context Switch上下文切換：

首先安裝sysstat：yum install sysstat  //使用的是fedora，ubuntu/debian使用apg-get

pidstat -w -G testp 1 10       //根據進程名監控上下文切換
pidstat -w -p 48863 1 10     //根據PID監控上下文切換

平均時間: UID    PID       cswch/s     nvcswch/s   Command
平均時間: 0         48770     2.53          2.78               testp

cswch/s: 每秒任務主動(自願的)切換上下文的次數，當某一任務處於阻塞等待時，將主動讓出本身的CPU資源。

nvcswch/s: 每秒任務被動(不自願的)切換上下文的次數，CPU分配給某一任務的時間片已經用完，所以將強迫該進程讓出CPU的執行權。

多處理器時添加-I參數，顯示各個cpu的使用率，如pidstat -w -I -G testp 1 10

什麼是CPU上下文切換？

        現 在linux是大多基於搶佔式，CPU給每一個任務必定的服務時間，當時間片輪轉的時候，須要把當前狀態保存下來，同時加載下一個任務，這個過程叫作上下文 切換。時間片輪轉的方式，使得多個任務利用一個CPU執行成爲可能，可是保存現場和加載現場，也帶來了性能消耗。  那線程上下文切換的次數和時間以及性能消耗如何看呢？  

        

        

 

    ​    ​如何得到上下文切換的次數？

         vmstat直接運行便可，在最後幾列，有CPU的context switch次數。 這個是系統層面的，加入想看特定進程的狀況，可使用pidstat。     

1 2 3 4 5 6 7

$ 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統計信息：       ​    

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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 ​安裝？

1 2 3 4

#wget http://www.bitmover.com/lmbench/lmbench3.tar.gz #tar -zxvf lmbench3.tar.gz #cd lmbench3 #make

        ​中間遇到一個問題，就是報錯，在CSDN上面找到了答案，這這裏貼一下。

1 2 3 4 5 6 7 8 9 10 11

此時會報錯：    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下面的英文解釋了。    

        測試上下文切換的時間，一個上下文切換，包括保存一個進程狀態的保存和恢復另一個進程的時間。

        典型的上下文切換性能，僅僅是測量最小的線程切換時間。僅僅是作進程切換，任何實質的任務都不作。

1 2 3 4 5 6

Context switching - times in microseconds - smaller is better ------------------------------------------------------------------------- Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K                          ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- commonway Linux 2.6.18- 9.2400 4.0200 9.0300 7.5600 8.3800    11.6 6.28000 時間的單位是微秒。

    ​

        LMbench是如何來測量進程切換的時間的？  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

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的時間）。

 

參考：http://www.cnblogs.com/EthanCai/p/3705834.html