一、前提

我們可以在文章的開始就列出一個列表，列出可能影響Linux作業系統效能的一些調優引數，但這樣做其實並沒有什麼價值。因為效能調優是一個非常困難的任務，它要求對硬體、作業系統、和應用都有著相當深入的瞭解。如果效能調優非常簡單的話，那些我們要列出的調優引數早就寫入硬體的微碼或者作業系統中了，我們就沒有必要再繼續讀這篇文章了。正如下圖所示，伺服器的效能受到很多因素的影響。

當面對一個使用單獨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核心。

新排程器另外一個重要的優勢是體現在對NUMA(non-uniform memory architecture)和SMP（symmetric multithreading processors）的支援上，例如[email protected]的超執行緒技術。

改進的NUMA支援保證了負載均衡不會發生在CECs或者NUMA節點之間，除非發生一個節點的超出負載限度。

三、Linux的記憶體架構

今天我們面對選擇32位作業系統還是64位作業系統的情況。對企業級使用者它們之間最大的區別是64位作業系統可以支援大於4GB的記憶體定址。從效能角度來講，我們需要了解32位和64位作業系統都是如何進行實體記憶體和虛擬記憶體的對映的。

在上面圖示中我們可以看到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空間中。

另外要提到的是，通常應用程式不直接將資料寫到磁碟子系統中，而是寫入快取和緩衝區中。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應用中。

這是一個處理網路封包的簡單的流程，但從中我們可以看到這個處理方式的缺點。正如我們看到的，每次適合網路封包到達網路介面都將對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。