cpu時間片的原理


CPU時間片

時間片即CPU分配給各個程序的時間,每個線程被分配一個時間段,稱作它的時間片,即該進程允許運行的時間,使各個程序從表面上看是同時進行的。如果在時間片結束時進程還在運行,則CPU將被剝奪並分配給另一個進程。如果進程在時間片結束前阻塞或結束,則CPU當即進行切換。而不會造成CPU資源浪費。在宏觀上:我們可以同時打開多個應用程序,每個程序並行不悖,同時運行。但在微觀上:由於只有一個CPU,一次只能處理程序要求的一部分,如何處理公平,一種方法就是引入時間片,每個程序輪流執行。

舉例

你同時輸入兩篇文檔:A.txt和B.txt;
你在A中輸入一個字之后,再在B中輸入一個字,輪流輸入,直至完成。總的看來你似乎在同時進行兩篇文章的錄入,你可以說我一邊寫A一邊寫B。但是具體到某個字時,就是沿着時間的前進,AB交替進行了。而你每個字輸入所占用的這段時間,我們就可以稱之為時間片。

操作系統

嵌入式操作系統可以分為實時操作系統和分時操作系統兩類
 

實時

實時操作系統是指具有實時性,能支持實時控制系統工作的操作系統。實時操作系統的首要任務是調度一切可利用的資源完成實時控制任務;其次才着眼於提高計算機系統的使用效率,其重要特點是通過任務調度來滿足對於重要事件在規定的時間內做出正確的響應。實時操作系統與分時操作系統有着明顯的區別。具體地說,對於分時操作系統,軟件的執行在時間上的要求並不嚴格,時間上的延誤或者時序上的錯誤,一般不會造成災難性的后果。而對於實時操作系統,主要任務是對事件進行實時的處理,雖然事件可能在無法預知的時刻到達,但是軟件必須在事件隨機發生時,在嚴格的時限內做出響應(系統的響應時間)。即使是系統處在尖峰負荷下,也應如此,系統時間響應的超時就意味着致命的失敗。另外,實時操作系統的重要特點是具有系統的可確定性,即系統能對運行的最好和最壞情況做出精確的估計。
 

分時

分時操作系統是把CPU的時間划分成長短基本相同的時間區間,即"時間片",通過操作系統的管理,把這些時間片依次輪流地分配給各個用戶使用.如果某個作業在時間片結束之前,整個任務還沒有完成,那么該作業就被暫停下來,放棄CPU,等待下一輪循環再繼續做.此時CPU又分配給另一個作業去使用.由於計算機的處理速度很快,只要時間片的間隔取得適當,那么一個用戶作業從用完分配給它的一個時間片到獲得下一個CPU時間片,中間有所"停頓";但用戶察覺不出來,好像整個系統全由它"獨占"似的.
 
為了提高程序執行效率,大家在很多應用中都采用了多線程模式,這樣可以將原來的序列化執行變為並行執行,任務的分解以及並行執行能夠極大地提高程序的運行效率。但這都是代碼級別的表現,而硬件是如何支持的呢?那就要靠CPU的時間片模式來說明這一切。程序的任何指令的執行往往都會要競爭CPU這個最寶貴的資源,不論你的程序分成了多少個線程去執行不同的任務,他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單CPU的情況。
 
任何線程如果都排隊等待CPU資源的獲取,那么所謂的多線程就沒有任何實際意義。
 
Linux的內核處理過程中,每一個進程默認會有一個固定的時間片來執行命令(默認為1/100秒),這段時間內進程被分配到CPU,然后獨占使用。如果使用完,同時未到時間片的規定時間,那么就主動放棄CPU的占用,如果到時間片尚未完成 工作,那么CPU的使用權也會被收回,進程將會被中斷掛起等待下一個時間片。
 

CPU利用率和Load Average的區別

壓力測試不僅需要對業務場景的並發用戶等壓力參數作模擬,同時也需要在壓力測試過程中隨時關注機器的性能情況,來確保壓力測試的有效性。當服務器長期處於一種超負荷的情況下運行,所能接收的壓力並不是我們所認為的可接受的壓力。就好比項目經理在給一個人估工作量的時候,每天都讓這個人工作12個小時,那么所制定的項目計划就不是一個合理的計划,那個人遲早會垮掉,而影響整體的項目進度。

CPU利用率在過去常常被我們這些外行認為是判斷機器是否已經到了滿負荷的一個標准,看到50%-60%的使用率就認為機器就已經壓到了臨界了。CPU利用率,顧名思義就是對於CPU的使用狀況,這是對一個時間段內CPU使用狀況的統計,通過這個指標可以看出在某一個時間段內CPU被占用的情況,如果被占用時間很高,那么就需要考慮CPU是否已經處於超負荷運作,長期超負荷運作對於機器本身來說是一種損害,因此必須將CPU的利用率控制在一定的比例下,以保證機器的正常運作。

Load Average是CPU的Load,它所包含的信息不是CPU的使用率狀況,而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息,也就是CPU使用隊列的長度的統計信息。為什么要統計這個信息,這個信息的對於壓力測試的影響究竟是怎么樣的,那就通過一個類比來解釋CPU利用率和Load Average的區別以及對於壓力測試的指導意義。

我們將CPU就類比為電話亭,每一個進程都是一個需要打電話的人。現在一共有4個電話亭(就好比我們的機器有4核),有10個人需要打電話。現在使用電話的規則是管理員會按照順序給每一個人輪流分配1分鍾的使用電話時間,如果使用者在1分鍾內使用完畢,那么可以立刻將電話使用權返還給管理員,如果到了1分鍾電話使用者還沒有使用完畢,那么需要重新排隊,等待再次分配使用。

 

如果默認為1min,那么1min的代表這些使用者占用電話時間小於等於1min,2min表示使用者占用電話時間小於等於2min,以此類推。根據電話使用規則,1min的用戶只需要得到一次分配即可完成通話,而其他兩類用戶需要排隊兩次到三次。

電話的利用率= sum (active use cpu time)/period

每一個分配到電話的使用者使用電話時間的總和去除以統計的時間段。這里需要注意的是是使用電話的時間總和(sum(active use cpu time)),這與占用時間的總和(sum(occupy cpu time))是有區別的。(例如一個用戶得到了一分鍾的使用權,在10秒鍾內打了電話,然后去查詢號碼本花了20秒鍾,再用剩下的30秒打了另一個電話,那么占用了電話1分鍾,實際只是使用了40秒)

電話的Average Load體現的是在某一統計時間段內,所有使用電話的人加上等待電話分配的人一個平均統計。

電話利用率的統計能夠反映的是電話被使用的情況,當電話長期處於被使用而沒有的到足夠的時間休息間歇,那么對於電話硬件來說是一種超負荷的運作,需要調整使用頻度。而電話Average Load卻從另一個角度來展現對於電話使用狀態的描述,Average Load越高說明對於電話資源的競爭越激烈,電話資源比較短缺。對於資源的申請和維護其實也是需要很大的成本,所以在這種高Average Load的情況下電話資源的長期“熱競爭”也是對於硬件的一種損害。

低利用率的情況下是否會有高Load Average的情況產生呢?理解占有時間和使用時間就可以知道,當分配時間片以后,是否使用完全取決於使用者,因此完全可能出現低利用率高Load Average的情況。由此來看,僅僅從CPU的使用率來判斷CPU是否處於一種超負荷的工作狀態還是不夠的,必須結合Load Average來全局的看CPU的使用情況和申請情況。

所以回過頭來再看測試部對於Load Average的要求,在我們機器為8個CPU的情況下,控制在10 Load左右,也就是每一個CPU正在處理一個請求,同時還有2個在等待處理。看了看網上很多人的介紹一般來說Load簡單的計算就是2* CPU個數減去1-2左右(這個只是網上看來的,未必是一個標准)。

補充幾點:

1.對於CPU利用率和CPU Load Average的結果來判斷性能問題。首先低CPU利用率不表明CPU不是瓶頸,競爭CPU的隊列長期保持較長也是CPU超負荷的一種表現。對於應用來說可能會去花時間在I/O,Socket等方面,那么可以考慮是否后這些硬件的速度影響了整體的效率。

這里最好的樣板范例就是我在測試中發現的一個現象:SIP當前在處理過程中,為了提高處理效率,將控制策略以及計數信息都放置在Memcached Cache里面,當我將Memcached Cache配置擴容一倍以后,CPU的利用率以及Load都有所下降,其實也就是在處理任務的過程中,等待Socket的返回對於CPU的競爭也產生了影響。

2.未來多CPU編程的重要性。現在服務器的CPU都是多CPU了,我們的服務器處理能力已經不再按照摩爾定律來發展。就我上面提到的電話亭場景來看,對於三種不同時間需求的用戶來說,采用不同的分配順序,我們可看到的Load Average就會有不同。假設我們統計Load的時間段為2分鍾,如果將電話分配的順序按照:1min的用戶,2min的用戶,3min的用戶來分配,那么我們的Load Average將會最低,采用其他順序將會有不同的結果。所以未來的多CPU編程可以更好的提高CPU的利用率,讓程序跑的更快。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM