模板
教程
環境
性能
功能
管理
Linux系統的性能測試與性能分析(2)
每秒鐘處理的中斷數
Hi%
服務于IRQs的時間占比
Si%
服務于Soft IRQs的時間占比
St%
關于st的解釋，在IBM的一份文檔里，有一段描述：
IBM’s definition of steal time is actually pretty good:
Steal time is the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.
3.3 工作原理
為了更好地理解CPU的性能參數，需要了解如下一些概念
3.3.1 進程及進程調度算法
什么是線程
圖3：進程和線程的數據結構
2. 進程的狀態
可運行狀態(TASK_RUNNING)
不可中斷的等待狀態(TASK_UNINTERRUPTIBLE)
暫停狀態(TASK_STOPPED)
跟蹤狀態(TASK_TRACED)
僵死狀態(EXIT_ZOMBIE)
問題 Wait io%包含在idle%當中嗎?
從下面top實例可以看出，wait io%不屬于idle%,等IO的過程被叫做uninterruptible sleep
Cpu1 : 2.7%us, 3.0%sy, 0.0%ni, 3.7%id, 89.7%wa, 0.0%hi, 1.0%si, 0.0%st
從性能測試角度來看，我傾向于這樣理解線程：
1. 線程和進程的確不同，因為他們可以共享進程的資源，如地址空間等。因此在上下文切換的過程中可能會產生較小的性能損耗。
2. 站在調度器(scheduler)的角度來說，線程就是一個進程，或者說是一個輕量級的進程(Light Weight Process)。Kernel實際上就是通過輕量級的進程來支持多線程應用程序的。我們經常用的線程開發庫pthread就是通過將輕量級進程和線程關聯起來，來實現的。這樣既可以實現資源的共享，又可以讓每個線程被調度器獨立調度。
2. 進程的狀態
可運行狀態(TASK_RUNNING)
不可中斷的等待狀態(TASK_UNINTERRUPTIBLE)
暫停狀態(TASK_STOPPED)
跟蹤狀態(TASK_TRACED)
僵死狀態(EXIT_ZOMBIE)
問題 Wait io%包含在idle%當中嗎?
從下面top實例可以看出，wait io%不屬于idle%,等IO的過程被叫做uninterruptible sleep
Cpu1 : 2.7%us, 3.0%sy, 0.0%ni, 3.7%id, 89.7%wa, 0.0%hi, 1.0%si, 0.0%st
3.3.4 硬中斷
性能測試中關注的中斷，主要由自于IO設備所產生，如鍵盤的一次按鍵，網卡的收報等等。
IRQ
IO設備所發出的IRQ(Interrupt ReQuest)請求叫做中斷請求(可屏蔽中斷)
每個能夠發出中斷的IO設備都有一個IRQ輸出線(部分高級前兆網卡，和大部分萬兆網卡都多條IRQ輸出線)。每條IRQ輸出線和可編程中斷控制器(Programmable Interrupt Controller)引腳相關聯。
每個IRQ輸出線的中斷信號，只能被一個CPU core處理，IRQ線從0開始編號。
如何觀察IRQ的狀態：
問題3：大量的中斷，是否會使CPU響應中斷成為瓶頸呢?
答案是一般不會，中斷享有最高的優先級，有硬件中斷發生時，CPU會立即停下手中的工作，響應中斷，并調用相應中斷處理程序。瓶頸一般發生在中斷處理程序。
IRQ硬件中斷是否意味著不會出現瓶頸呢?瓶頸有可能出現在中斷的服務例程中，看下面的流程圖：
IRQ在多處理器上的分發：
遵循對稱多處理模型，每個IO中斷的處理時間片是相同的，均勻分配。Kernel通過中斷向量表來將中斷信號發送到特定的CPU上去。
在必要的時候，Linux 2.6利用kirqd的內核線程來糾正IRQ在CPU上的分配。kirqd線程周期性的執行掃描每個CPU處理的中斷個數，發現不均衡時重新調整CPU的負載。
下面的案例表明，IRQ在CPU上的分配不夠均衡，因為8個CPU，只有4個CPU有負載：
性能測試中關注的中斷，主要由自于IO設備所產生，如鍵盤的一次按鍵，網卡的收報等等。
IRQ
IO設備所發出的IRQ(Interrupt ReQuest)請求叫做中斷請求(可屏蔽中斷)
每個能夠發出中斷的IO設備都有一個IRQ輸出線(部分高級前兆網卡，和大部分萬兆網卡都多條IRQ輸出線)。每條IRQ輸出線和可編程中斷控制器(Programmable Interrupt Controller)引腳相關聯。
每個IRQ輸出線的中斷信號，只能被一個CPU core處理，IRQ線從0開始編號。
問題3：大量的中斷，是否會使CPU響應中斷成為瓶頸呢?
答案是一般不會，中斷享有最高的優先級，有硬件中斷發生時，CPU會立即停下手中的工作，響應中斷，并調用相應中斷處理程序。瓶頸一般發生在中斷處理程序。
IRQ硬件中斷是否意味著不會出現瓶頸呢?瓶頸有可能出現在中斷的服務例程中，看下面的流程圖：
IRQ在多處理器上的分發：
遵循對稱多處理模型，每個IO中斷的處理時間片是相同的，均勻分配。Kernel通過中斷向量表來將中斷信號發送到特定的CPU上去。
在必要的時候，Linux 2.6利用kirqd的內核線程來糾正IRQ在CPU上的分配。kirqd線程周期性的執行掃描每個CPU處理的中斷個數，發現不均衡時重新調整CPU的負載。
下面的案例表明，IRQ在CPU上的分配不夠均衡，因為8個CPU，只有4個CPU有負載：
原文鏈接：http://testing.etao.com/
原文轉自：http://www.anti-gravitydesign.com
