回過頭再看 計算機體系結構4----中斷和性能


【注】

----本文轉自:www.ifeve.com -----author: 【空蒙】
整理於該計算機體系

CPU中斷是什么?
CPU中斷,會導致正在運行的CPU要停下手頭的工作去響應,這需要工作任務的切換,就帶來了我們熟知的上下文切換,而頻繁上下文切換,是對系統性能的重要影響因素。

那怎么減少中斷帶來的影響呢?
現在CPU往往是多核,如16、32核,是否可以把中斷綁定到其中一個CPU上,再把其他剩余的cpu用於應用的計算。因為之前是單核的原因,傳統的很多做法是會把中斷扔給cpu0處理,在linux下,可執行mpstat -P ALL 1,查看各個cpu上的中斷情況。



這虛擬機可以看到cpu2上的中斷明顯偏多,每秒有6k次,這樣會對性能產生什么樣的影響呢?再看上下文切換的情況



此時上下文切換大於1w次,再看top里面cpu對軟中斷與硬中斷的處理情況



對應的也可發現,CPU2上處里更多的中斷,hi與si。如果此時我們的應用跑在CPU2上,結果可想而知就是每秒約6k次的上下文切換。既然如此那我就設置下應用使用的CPU,讓java進程不在CPU2上跑,會有什么效果呢?


立馬可以看到,cpu2上的us變的很低了,java進程在其他的cpu上運行了,但cpu2上繼續響應hi與si,再看上下文切換情況
可以看到,現在上下文切換,明顯比之前的少了5~6k,基本上就是之前在cpu2上的中斷次數,稍做改動,就把上下文切換減少了很多

那整體的cpu利用率情況呢:



如上圖中間這段的數據,是設置了java進程運行在CPU0、1、3、4上的,前后兩段是全部CPU跑的,大概us比不設置降低了5%,us降低了點,性能上當然可以提升點了。
當其中一個CPU的hi和si明顯比其他的高,而且系統的吞吐能力上不去,很可能是中斷處理不均衡的問題,當中斷的數量一個CPU夠處理的時候,利用親緣綁定CPU,減少中斷引起的上下文切換,但當一個CPU中斷處理不夠時候,就用多個CPU處理,或者所有CPU平均分攤,但所有的CPU分攤,上下文切換的次數不會減少。所以真正如何處理這個中斷,還是看系統與應用的實際情況。



網卡的中斷是什么?
網卡接收數據后會產生中斷,讓CPU來處理,一個CPU沒話說,只有它干活,多核時代怎么搞呢,很多老的設備還是綁定一個CPU上。為了能充分利用多核,Google的牛人搞了個RPS、RFS的patch,能夠將網卡中斷分散到多個CPU,主要就是hash到固定的CPU上,具體可google查看。

但是,這明顯是我等屌絲的玩法,現在高富帥的玩法是,高級的網卡是支持多隊列的,找新機器cat /proc/interrupts |grep eth0,可以看到eth0-TxRx-0 ~~eth0-TxRx-7,同時每個隊列的中斷對應一個CPU,這樣就把中斷響應分攤了。

但現在cpu32核,還是顯得不夠平均,所以這時候還可以使用RFS,看看效果,當然RFS需要linux 2.6.35以上支持,所以那些2.6.18內核的機器,快點退休吧。

T4的機器目前虛擬機對cpu的分配,是用cgroup跨core綁定的,也就是會跨物理cpu組成一個虛擬機,這會帶來cache miss的問題,至於為什么不選擇一個虛擬機盡量在一個core上,大師的答復是主要是為充分利用資源,我們的應用,還沒有到cache miss影響更大,還是充分利用cpu運算能力先。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com