理解Linux的效能

項目中常遇到需要對目前啟動並執行系統進行效率分析，或碰到客戶諮詢如何最佳化系統的效率問題。更多的情況是，在系統出現問題的時候，需要分析原因，定位系統故障或瓶頸，當然，最好是可以一併解決故障。但實際上，作業系統最佳化是一個非常複雜的問題，況且linux有自己一套有別於其他動作系統管理的機制，由此會引起很多不必要的誤解和麻煩。自問我是寫不錯條理性的文章了，只能轉一份高人寫的文檔供參考。（文章根據實際進行了一定的裁減，並對容易碰到的問題做了標識）
一、前提
   我們可以在文章的開始就列出一個列表，列出可能影響Linux作業系統效能的一些調優參數，但這樣做其實並沒有什麼價值。因為效能調優是一個非常困難的任務，它要求對硬體、作業系統、和應用都有著相當深入的瞭解。如果效能調優非常簡單的話，那些我們要列出的調優參數早就寫入硬體的微碼或者作業系統中了，我們就沒有必要再繼續讀這篇文章了。正如所示，伺服器的效能受到很多因素的影響。

1168940406_0.gif
當面對一個使用單獨IDE硬碟的，有20000使用者的資料庫伺服器時，即使我們使用數周時間去調整I/O子系統也是徒勞無功的，通常一個新的驅動或者應用程式的一個更新（如SQL最佳化）卻可以使這個伺服器的效能得到明顯的提升。正如我們前面提到的，不要忘記系統的效能是受多方面因素影響的。理解作業系統管理系統資源的方法將協助我們在面對問題時更好的判斷應該對哪個子系統進行調整。
二、Linux的CPU調度
   任何電腦的準系統都十分簡單，那就是計算。為了實現計算的功能就必須有一個方法去管理計算資源、處理器和計算任務（也被叫做線程或者進程）。非常感謝Ingo Molnar，他為Linux核心帶來了O（1）CPU調度器，區別於舊有的O（n）調度器，新的調度器是動態，可以支援負載平衡，並以恒定的速度進行操作。
新調度器的可擴充性非常好，無論進程數量或者處理器數量，並且調度器本身的系統開銷更少。新調取器的演算法使用兩個優先順序隊列。
引用
·活動運行隊列
·到期運行隊列

   調度器的一個重要目標是根據優先順序許可權有效地為進程分配CPU 時間片，當分配完成後它被列在CPU的運行隊列中，除了 CPU 的運行隊列之外，還有一個到期運行隊列。當活動運行隊列中的一個任務用光自己的時間片之後，它就被移動到到期運行隊列中。在移動過程中，會對其時間片重新進行計算。如果活動運行隊列中已經沒有某個給定優先順序的任務了，那麼指向活動運行隊列和到期運行隊列的指標就會交換，這樣就可以讓到期優先順序列表變成活動優先順序的列表。通常互動式進程（相對與即時進程而言）都有一個較高的優先順序，它佔有更長的時間片，比低優先順序的進程獲得更多的計算時間，但通過調度器自身的調整並不會使低優先順序的進程完全被餓死。新調度器的優勢是顯著的改變Linux核心的可擴充性，使新核心可以更好的處理一些有大量進程、大量處理器組成的企業級應用。新的O(1)調度器包含仔2.6核心中，但是也向下相容2.4核心。

1168940734_0.gif
新調度器另外一個重要的優勢是體現在對NUMA(non-uniform. memory architecture)和SMP（symmetric multithreading processors）的支援上，例如INTEL@的超執行緒技術。
改進的NUMA支援保證了負載平衡不會發生在CECs或者NUMA節點之間，除非發生一個節點的超出負載限度。
三、Linux的記憶體架構
   今天我們面對選擇32位作業系統還是64位作業系統的情況。對企業級使用者它們之間最大的區別是64位作業系統可以支援大於4GB的記憶體定址。從效能角度來講，我們需要瞭解32位和64位作業系統都是如何進行實體記憶體和虛擬記憶體的映射的。

1168940954_0.gif
在上面圖示中我們可以看到64位和32位Linux核心在定址上有著顯著的不同。
   在32位架構中，比如IA-32，Linux核心可以直接定址的範圍只有實體記憶體的第一個GB（如果去掉保留部分還剩下896MB），訪問記憶體必須被映射到這小於1GB的所謂ZONE_NORMAL空間中，這個操作是由應用程式完成的。但是分配在ZONE_HIGHMEM中的記憶體頁將導致效能的降低。
   在另一方面，64位架構比如x86-64（也稱作EM64T或者AMD64）。ZONE_NORMAL空間將擴充到64GB或者128GB（實際上可以更多，但是這個數值受到作業系統本身支援記憶體容量的限制）。正如我們看到的，使用64位作業系統我們排除了因ZONE_HIGHMEM部分記憶體對效能的影響的情況。
   實際中，在32位架構下，由於上面所描述的記憶體定址問題，對於大記憶體，高負載應用，會導致死機或嚴重緩慢等問題。雖然使用hugemen核心可緩解，但採取x86_64架構是最佳的解決辦法。
四、虛擬記憶體管理
   因為作業系統將記憶體都映射為虛擬記憶體，所以作業系統的實體記憶體結構對使用者和應用來說通常都是不可見的。如果想要理解Linux系統記憶體的調優，我們必須瞭解Linux的虛擬記憶體機制。應用程式並不分配實體記憶體，而是向Linux核心請求一部分映射為虛擬記憶體的記憶體空間。如所示虛擬記憶體並不一定是映射實體記憶體中的空間，如果應用程式有一個大容量的請求，也可能會被映射到在磁碟子系統中的swap空間中。

1168941286_0.gif
另外要提到的是，通常應用程式不直接將資料寫到磁碟子系統中，而是寫入緩衝和緩衝區中。Bdflush守護進程將定時將緩衝或者緩衝區中的資料寫到硬碟上。
   Linux核心處理資料寫入磁碟子系統和管理磁碟緩衝是緊密聯絡在一起的。相對於其他的作業系統都是在記憶體中分配指定的一部分作為磁碟緩衝，Linux處理記憶體更加有效，預設情況下虛擬記憶體管理器分配所有可用記憶體空間作為磁碟緩衝，這就是為什麼有時我們觀察一個配置有數G記憶體的Linux系統可用記憶體只有20MB的原因。
   同時Linux使用swap空間的機制也是相當高效率的，如所示虛擬記憶體空間是由實體記憶體和磁碟子系統中的swap空間共同組成的。如果虛擬記憶體管理器發現一個已經分配完成的記憶體分頁已經長時間沒有被調用，它將把這部分記憶體分頁移到swap空間中。經常我們會發現一些守護進程，比如getty，會隨系統啟動但是卻很少會被應用到。這時為了釋放昂貴的主記憶體資源，系統會將這部分記憶體分頁移動到swap空間中。上述就是Linux使用swap空間的機制，當swap分區使用超過50％時，並不意味著實體記憶體的使用已經達到瓶頸了，swap空間只是Linux核心更好的使用系統資源的一種方法。
   簡單理解：Swap usage只表示了Linux管理記憶體的有效性。對識別記憶體瓶頸來說，Swap In/Out才是一個比較又意義的依據，如果Swap In/Out的值長期保持在每秒200到300個頁面通常就表示系統可能存在記憶體的瓶頸。下面的案例是好的狀態：
引用
# vmstat
procs -----------memory-------------     ---swap--   -----io----   --system--    ----cpu----
r  b   swpd   free    buff  cache        si   so      bi    bo     in    cs      us sy id wa
1  0   5696   6904  28192  50496    0    0      88   117   61    29    11  8 80  1

五、模組化的I/O調度器
   就象我們知道的Linux2.6核心為我們帶來了很多新的特性，這其中就包括了新的I/O調度機制。舊的2.4核心使用一個單一的I/O調度器，2.6 核心為我們提供了四個可選擇的I/O調度器。因為Linux系統應用在很廣闊的範圍裡，不同的應用對I/O裝置和負載的要求都不相同，例如一個膝上型電腦和一個10000使用者的資料庫伺服器對I/O的要求肯定有著很大的區別。
引用
（1）．Anticipatory
anticipatory I/O調度器建立假設一個塊裝置只有一個物理的尋找磁頭（例如一個單獨的SATA硬碟），正如anticipatory調度器名字一樣， anticipatory調度器使用“anticipatory”的演算法寫入硬碟一個比較大的資料流代替寫入多個隨機的小的資料流，這樣有可能導致寫 I/O操作的一些延時。這個調度器適用於通常的一些應用，比如大部分的個人電腦。
（2）．Complete Fair Queuing (CFQ)
Complete Fair Queuing（CFQ）調度器是Red Flag DC Server 5使用的標準演算法。CFQ調度器使用QoS策略為系統內的所有任務分配相同的頻寬。CFQ調度器適用於有大量計算進程的多使用者系統。它試圖避免進程被餓死和實現了比較低的延遲。
（3）．Deadline
deadline調度器是使用deadline演算法的輪詢的調度器，提供對I/O子系統接近即時的操作，deadline調度器提供了很小的延遲和維持一個很好的磁碟輸送量。如果使用deadline演算法請確保進程資源分派不會出現問題。
（4）．NOOP
NOOP調度器是一個簡化的發送器它只作最基本的合并與排序。與案頭系統的關係不是很大，主要用在一些特殊的軟體與硬體環境下，這些軟體與硬體一般都擁有自己的調度機制對核心支援的要求很小，這很適合一些嵌入式系統內容。作為案頭使用者我們一般不會選擇它。

六、網路子系統
   新的網路中斷緩和（NAPI）對網路子系統帶來了改變，提高了大流量網路的效能。Linux核心在處理網路堆棧時，相比降低系統佔用率和高輸送量更關注可靠性和低延遲。所以在某些情況下，Linux建立一個防火牆或者檔案、列印、資料庫等企業級應用的效能可能會低於相同配置的Windows伺服器。
   在傳統的處理網路封包的方式中，如藍色箭頭所描述的，一個乙太網路封包到達網卡介面後，如果MAC地址相符合會被送到網卡的緩衝區中。網卡然後將封包移到作業系統核心的網路緩衝區中並且對CPU發出一個硬中斷，CPU會處理這個封包到相應的網路堆棧中，可能是一個TCP連接埠或者Apache應用中。

1168941826_0.gif
這是一個處理網路封包的簡單的流程，但從中我們可以看到這個處理方式的缺點。正如我們看到的，每次適合網路封包到達網路介面都將對CPU發出一個硬中斷訊號，中斷CPU正在處理的其他任務，導致切換動作和對CPU緩衝的操作。你可能認為當只有少量的網路封包到達網卡的情況下這並不是個問題，但是千兆網路和現代的應用將帶來每秒鐘成千上萬的網路資料，這就有可能對效能造成不良的影響。
   正是因為這個情況，NAPI在處理網路通訊的時候引入了計數機制。對第一個封包，NAPI以傳統的方式進行處理，但是對後面的封包，網卡引入了POLL 的輪詢機制：如果一個封包在網卡DMA環的緩衝中，就不再為這個封包申請新的中斷，直到最後一個封包被處理或者緩衝區被耗盡。這樣就有效減少了因為過多的中斷CPU對系統效能的影響。同時，NAPI通過建立可以被多處理器執行的非強制中斷改善了系統的可擴充性。NAPI將為大量的企業級多處理器平台帶來協助，它要求一個啟用NAPI的驅動程式。在今天很多驅動程式預設沒有啟用NAPI，這就為我們調優網路子系統的效能提供了更廣闊的空間。
七、理解Linux調優參數
   因為Linux是一個開源作業系統，所以又大量可用的效能監測工具。對這些工具的選擇取決於你的個人喜好和對資料細節的要求。所有的效能監測工具都是按照同樣的規則來工作的，所以無論你使用哪種監測工具都需要理解這些參數。下面列出了一些重要的參數，有效理解它們是很有用處的。
（1）處理器參數
引用
·CPU utilization
這是一個很簡單的參數，它直觀的描述了每個CPU的利用率。在xSeries架構中，如果CPU的利用率長時間的超過80％，就可能是出現了處理器的瓶頸。
·Runable processes
這個值描述了正在準備被執行的進程，在一個期間裡這個值不應該超過物理CPU數量的10倍，否則CPU方面就可能存在瓶頸。
·Blocked
描述了那些因為等待I/O操作結束而不能被執行的進程，Blocked可能指出你正面臨I/O瓶頸。
·User time
描述了處理使用者進程的百分比，包括nice time。如果User time的值很高，說明系統效能用在處理實際的工作。
·System time
描述了CPU花費在處理核心操作包括IRQ和軟體中斷上面的百分比。如果system time很高說明系統可能存在網路或者驅動堆棧方面的瓶頸。一個系統通常只花費很少的時間去處理核心的操作。
·Idle time
描述了CPU閒置百分比。
·Nice time
描述了CPU花費在處理re-nicing進程的百分比。
·Context switch
系統中線程之間進行交換的數量。
·Waiting
CPU花費在等待I/O操作上的總時間，與blocked相似，一個系統不應該花費太多的時間在等待I/O操作上，否則你應該進一步檢測I/O子系統是否存在瓶頸。
·Interrupts
Interrupts 值包括硬Interrupts和軟Interrupts，硬Interrupts會對系統效能帶來更多的不利影響。高的Interrupts值指出系統可能存在一個軟體的瓶頸，可能是核心或者驅動程式。注意Interrupts值中包括CPU時鐘導致的中斷（現代的xServer系統每秒1000個 Interrupts值）。

（2）記憶體參數
引用
·Free memory
相比其他動作系統，Linux空閑記憶體的值不應該做為一個效能參考的重要指標，因為就像我們之前提到過的，Linux核心會分配大量沒有被使用的記憶體作為檔案系統的緩衝，所以這個值通常都比較小。
·Swap usage
這個值描述了已經被使用的swap空間。Swap usage只表示了Linux管理記憶體的有效性。對識別記憶體瓶頸來說，Swap In/Out才是一個比較又意義的依據，如果Swap In/Out的值長期保持在每秒200到300個頁面通常就表示系統可能存在記憶體的瓶頸。
·Buffer and cache
這個值描述了為檔案系統和塊裝置分配的緩衝。在Red Flag DC Server 5版本中,你可以通過修改/proc/sys/vm中的page_cache_tuning來調整空閑記憶體中作為緩衝的數量。
·Slabs
描述了核心使用的記憶體空間，注意核心的頁面是不能被交換到磁碟上的。
·Active versus inactive memory
提供了關於系統記憶體的active記憶體資訊，Inactive記憶體是被kswapd守護進程交換到磁碟上的空間。

（3）網路參數
引用
·Packets received and sent
這個參數表示了一個指定網卡接收和發送的資料包的數量。
·Bytes received and sent
這個參數表示了一個指定網卡接收和發送的資料包的位元組數。
·Collisions per second
這個值提供了發生在指定網卡上的網路衝突的數量。持續的出現這個值代表在網路架構上出現了瓶頸，而不是在伺服器端出現的問題。在正常配置的網路中衝突是非常少見的，除非使用者的網路環境都是由hub組成。
·Packets dropped
這個值表示了被核心丟掉的資料包數量，可能是因為防火牆或者是網路緩衝的缺乏。
·Overruns
Overruns表達了超出網路介面緩衝的次數，這個參數應該和packets dropped值聯絡到一起來判斷是否存在在網路緩衝或者網路隊列過長方面的瓶頸。
·Errors
這個值記錄了標誌為失敗的幀的數量。這個可能由錯誤的網路設定或者部分網線損壞導致，在銅口千兆乙太網路環境中部分網線的損害是影響效能的一個重要因素。

（4）塊裝置參數
引用
·Iowait
CPU等待I/O操作所花費的時間。這個值持續很高通常可能是I/O瓶頸所導致的。
·Average queue length
I/O請求的數量，通常一個磁碟隊列值為2到3為最佳情況，更高的值說明系統可能存在I/O瓶頸。
·Average wait
響應一個I/O操作的平均時間。Average wait包括實際I/O操作的時間和在I/O隊列裡等待的時間。
·Transfers per second
描述每秒執行多少次I/O操作（包括讀和寫）。Transfers per second的值與kBytes per second結合起來可以協助你估計系統的平均傳輸塊大小，這個傳輸塊大小通常和磁碟子系統的條帶化大小相符合可以獲得最好的效能。
·Blocks read/write per second
這個值表達了每秒讀寫的blocks數量，在2.6核心中blocks是1024bytes，在早些的核心版本中blocks可以是不同的大小，從512bytes到4kb。
·Kilobytes per second read/write
按照kb為單位表示讀寫塊裝置的實際資料的數量。

八、附錄
本文截取和修改自IBM的紅皮書Tuning Red Hat Enterprise Linux on IBM eServer xSeries Servers。