亞馬遜AWS首席云計算技術顧問 費良宏于基于云架構的性能優化專場發表了題為《AWS 云計算之上Linux實例的優化》的演講，現場分享了AWS 上Linux 實例的深度優化和實踐，這對于云計算的而言是最基礎但卻是不可缺少的一環。

 

 

 

費良宏：大家好，很高興跟大家分享一些我最近關心的話題。在云計算上我們會使用很多的操作系統，Linux是我們非常熟悉、使用量非常大的系統，但是如何對這個操作系統進行優化，是大家面臨的問題。Linux的歷史比較悠久，但是在云計算之上的優化有一些需要特別注意的地方，也是今天我想跟大家分享的幾個話題。

 

提到云計算我想先介紹一下AWS，大家可能知道AWS是云計算服務的提供者，到目前為止AWS在全球有13個區域，其中包括35個可用區，有56個邊緣站點，這些構成了全球云計算的基礎架構，服務于全球190個國家。

 

在過去的十年里通過這樣的發展，AWS現在所提供的服務范圍是非常廣泛的，涵蓋的種類不僅包括了計算、網絡、存儲、數據庫、大數據、人工智能，還包括了像安全，甚至像SaaS等等一些新的云計算的領域。

 

在今年8月6號發布的云計算IaaS魔力象限里面，AWS又處于報告的絕對領先位置。在這個報告出現的6年時間里，每次AWS都處于絕對領先的位置，這個報告也代表了AWS在整個云計算市場的位置。

 

如果使用過AWS的人，恐怕第一個接觸的產品都是AWS所提供的彈性虛擬服務器，我們稱之為EC2，這個產品也是我今天談的重點話題，也就是如何針對這樣的環境進行優化。

 

大家都了解在云計算的環境里面包括在數據中心里面會有很多物理服務器，服務器之上通過虛擬化的技術會提供許許多多的虛擬機，如何使用這些虛擬機的資源，讓它更好的服務于我們的應用，這是我們面臨的一個很現實的問題。

 

回顧起來這樣的技術發展有超過十年的時間，十年前第一代EC2產品種類比較單一，而且性能相對比較弱小。但是通過十年的發展，尤其是在過去三年里發展速度非常快，幾乎每年都有很多新類型虛擬機的資源會發布出來。

 

面對這樣的環境，我們使用的計算機資源如此豐富，我們可以通過AWS環境使用免費的操作系統，我們稱之為Amazon Machine Image，這些操作系統包括Amazon Linux、CentOS、FreeBSD、Ubuntu、Debian等，同樣也有大量付費的操作系統，包括Windows Server、Red Hat Enterprise Linux 、SUSE Linux Enterprise 版本等等。同樣使用AWS提供的Marketplace資源，你可以大量的使用第三方甚至社區提供的各種Linux版本和分發的介質。在 Marketplace里面所有的Linux Image總數是1738個，幾乎涵蓋了所有主流的Linux版本。

 

 

所有的EC2產品包含在十個大的家族產品里面，這些家族產品有各自不同的目的，分別適用于計算優化、內存優化、GPU、存儲優化等等。其中一些產品代表了這個領域里面最高的級別，比如最新發布的S1就提供了2TB內存的處理能力，這些不同的機器可以滿足大家不同程度的需求。

 

 

今天的話題是圍繞EC2 Linux環境的優化，從這個簡單的示意圖可以看到，我們能夠使用到的主要就是Guest、OS等，它們運行在一個虛擬層之上，之下是物理的操作系統。面對這樣的環境，優化方式跟我們傳統熟悉的Linux優化有很多的不同，這也是我今天強調的最重要的一點。

 

回到優化的問題，我們首先要決定優化的目的到底是什么？是決定改進我們的性能，那性能又是什么以及如何定義它？這是首先必須要回答的問題。由于我們的需求不同，對性能的要求有很大的差異。所以決定優化之前先從問題的視角出發，明確你的需求是什么。通常來看性能的表現取決于很多因素，這些因素可以歸納為三個大的方面，系統響應時間、吞吐量、一致性。當然性能不僅僅包括這些，我今天談到的只是通用的方面。

 

 

影響性能的因素從廣義上來說非常多，但是圍繞著操作系統這個環境來看，影響性能因素包括幾個方面，第一個就是CPU，CPU插槽的數量、核的數量等等對CPU的表現有很大的影響。其次是內存，內存容量的多少直接影響到我們使用的資源所能承擔的處理能力。網絡的帶寬、包速率也會對網絡情況有很大的制約。磁盤的情況，包括吞吐量和每秒鐘完成的輸出/輸入都是很大的影響，今天我們就是圍繞這幾個方面展開。除此之外還有很多因素都會對性能產生影響，但不在我們的探討范圍之內。

 

談到云計算的性能問題必須要強調一點就是資源的利用率，在傳統針對物理機的優化里面不是特別在意資源利用率，在低利用率的情況下我們還竊喜，因為還處在比較好的狀態。云計算的環境，決定了云計算的成本是彈性可變的，如果不能很好的利用資源，使大量資源閑置，某種意義上會產生極大的浪費。所以對云計算環境下的優化來說，首先要考慮的是如何提高我們資源的利用率。從這個角度出發我的建議是，選擇好的云計算的實例就等于優化，如果選擇和你相匹配的實例就會最大程度發揮你的資源，使我們的成本在合理的范圍內，并且未來隨著我們需求的不斷增長，我們的成本也會調整，不會讓我們的每一分錢花在不必要的地方。

 

 

那如何選擇實例呢？業內有很多經驗和方法，這張圖是Netflix奉獻給業內的他們自己選擇實例的流程圖，依據不同的需求利用這個流程圖就可以在為數眾多的 AWS實例類型當中選擇適合你的資源。這些資源其實還是非常復雜的，不僅僅是虛擬機涵蓋的含義，以EC2 C4實例為例，實際是針對Intel E5-2666 v3 CPU定制的一款產品，算是一代面向計算優化的實例，更通用的類型。但是為了解決這個類型也做了很多優化，比如針對P-state和C-state 進行了定制化的配置處理。P-state和C-state實際上是CPU APCI的控制，決定了CPU是處于低功耗的狀態還是處于一個從C0到CN不同運行狀態處理能力的變化，可以使我們的服務器在能耗和性能之間保持一個合理的控制。同樣每一款EC2的實例有不同的型號，有不同的處理能力，從large到8xlarge提供了不同的處理能力。

 

EC2的技術特性里有一些是需要讓大家了解，并且可以應用這些技術進行優化，我大概列舉了以下這些內容。

 

•CPU 指令核保護等級。對于X86這款CPU大家比較清楚熟悉，這款架構有明顯的特征，就是指令核的保護等級，而且不能在用戶模式下執行特權指令來保護系統，應用程序通過syscall實現內核調用的完成。比如我們針對一個Web服務器，使用strace就可以看到不同的調用，有效的減少這些調用可以明顯提升性能。

 

•另外一個技術特點就是Intel VT-x，在2005年這款技術出現之前，我們的虛擬化主要使用PV的模式，PV模式存在很多不足，比如說需要穿透VMM，增加了延遲，系統調用的開銷以及網絡和存儲系統的性能開銷相對比較大，所以那時候我們對虛擬化的技術有很多顧慮。但是在2005年由于Intel增加了這個特性，我們出現了新的選擇，使用硬件輔助的虛擬化滿足了性能的提升。尤其是利用PV driver和HVM相結合，巧妙解決了處理較慢的操作，從此之后我們的虛擬化才大放異彩被業內廣泛接受。

 

•Xen 虛擬化模式。大家知道Xen的穩定版本是4.7，它提供了五種虛擬化方式，包括HVM、PV-HVM、PV driver HVM、PVH等等五種不同的類型，對應到AWS EC2產品上，我們所說的HVM其實等價于PVHVM，前提是Linuxkernel支持。另外在AWS的網站上你會看到也會存在PV的描述，這就等價于Xen PV的模式。總結起來，我們在AWS網站上能夠看到的所有的案例里面，性能最好得就是HVM的Xen版本，對應的就是PVHVM。從未來的發展來看，隨著技術的不斷進步，虛擬化技術也在不斷提升，未來可能看到的性能預期比較好的就是PVH。

 

 

這張圖里我歸納了剛才談到的情況，當然這個版本相對老了一點，圖上呈現的是4.4版本，目前是4.7版本，但總體的格局沒有太大的變化。目前使用比較多的是 PVHVM的模式，未來可能會過渡到PVH的場景里面。通過幾個不同的維度可以看到，PVH代表了未來速度最好的狀態。

 

•另外一個特性是單根 I/O 虛擬化也就是SR-IOV，這個特性的出現是為了解決網絡的特性，虛擬化會對網絡性能產生損耗。于是Intel針對這種場景提供了幾個方案，將PCIe的設備共享給我們每一個VM，某種意義上就解決了穿透的問題，使得我們的 VM可以直接訪問PCIe的設備，就是網絡的網卡。利用這個設備在AWS的環境里面就提供了增強聯網的能力，比如C3、C4的實例，它們的某個特性就能達到10GB。最明顯的是吞吐量會提高，并且降低了網絡平均往返時延、減少了抖動 。需要強調的是不同的類型和型號，這個特性會有所差別，所以在選擇的時候一定要強調你最好選擇支持增強聯網特性的類型，會得到一個更好的網絡體驗。

 

回到Linux內核這個話題，我們來看看針對剛才談到的技術特點，如何利用技術手段幫助我們進行優化。我們簡單來說有七大方面，就是CPU調度器、虛擬內存、巨型頁、文件系統、存儲的IO、網絡、Hypervisor 。針對不同的場景會有各種優化的選項和策略，如果進行適當調整，在某種意義上對我們應用的性能會有很大的提升。

 

 

比如說如果安裝了schedtool這款工具，這個工具可以通過GitHub搜索下載。使用之后可以針對每一個值進行特殊的處理，我在圖中列出了一個特性，用B參數使長時間運行的進程得到一個非常好的性能優化，減少了上下文的切換。如果強調實時性，可以用R參數進行特定的優化。

 

 

針對虛擬內存，將swappiness設置為0可以釋放出更多的內存。我們可以通過這些參數設定，使我們的系統更適合于我們內存消耗的需求。缺省的時候swappiness是打開的，并且值是60，我們可以改成10更好地提升性能。

 

 

巨型頁也是內存訪問上重要的特性，常見的內存管理是通過內存配置的方式進行管理，缺省的情況是4K，那么如果有1GB內存，就會有26萬頁的管理項，如果內存更大就會更加龐大。我們經常會在這樣大的表中進行查找，如果數據量非常大，某種程度上會影響使用的效率。缺省情況下在EC2的某個實例里面將頁設置為 2M，你也可以設置成更大的值。在不同的應用里面都會對page進行很好的設置。

 

 

文件系統是很特別的應用場景，需要我們引起注意。不同的文件系統有很多可調整的參數，通常這些優化的項目都圍繞這幾個參數進行，包括background flush earlier、 aggressive flush later等，這些都依托我們具體的使用環境和需求完成。以dirty_background_ratio為例，缺省情況下是10，這里設置為5來提高響應速度和處理能力。

 

 

Storage I/O主要是針對塊設備進行優化的調整項，大家知道在操作系統里面，Linux操作系統支持預讀的能力，它可以預知下一個要讀取的文件，將它讀到內存里。環境變化了，目前很多應用軟件對這個特性是非常敏感的，這種情況下我們可以對read ahead size進行一些優化和調整，甚至可以把它禁用。另外SSD出現之后，使得我們傳統的調度方法產生了變化，比如我們經常采用的調度策略是CFQ，它對 SSD就不是非常友好，更好的方法我們推薦使用“noop” scheduler，所以可以通過這樣的一些改變使得我們更好地匹配SSD獲得不同應用場景的需求。

 

 

對于網絡，大家都很清楚，我們有很多的網絡優化項進行調整和設置，這些優化項種類和數量非常多，其中包含了像buffer sizes、backlog等，這些項大家可以針對具體的經驗進行優化處理。

 

 

還有一種應用場景就是在虛擬化的環境里面，云計算里面經常會遇到的，針對Hypervisor 的優化。最主要的優化項就是clocksource，包括像hpet、xen、tsc等等。

 

 

在我們的環境里缺省的EC2時鐘源都是Xen，如果你用cat命令讀取都是這樣的。這里面有什么區別呢？簡單來說hpet是一個硬件的時鐘源，它提供了非常好的監控，但是它需要產生系統的調度，開銷比較大。Xen的適用性非常好，所以在虛擬化環境里面缺省會使用它。tsc是通過計算器的方法獲得這樣的時鐘源，并不需要用系統調度來實現，只需要在用戶空間就可以得到，但相對來說精度不如hpet，但是速度上tsc是最好的表現。所以你可以嘗試把時鐘源設置為tsc進行觀測。比較理想的情況下，CPU的用量可以降低30%，當然如果表現不好也會產生額外的副作用。

 

 

我們剛才提到了監測，在AWS的環境里面有很多服務可以幫助我們達成這個目標。以這個WebServer為例，在這個場景里面，可以通過監控看到不同WebServer請求的表現，也可以看到內存的使用情況，包括磁盤的統計情況、網絡的使用統計等等，所有的監控指標都是我們進行優化的非常重要的基礎條件。

 

 

優化時也會有一些不好的優化場景，希望大家引起注意。第一種是“打地鼠” 式的優化，這個是什么樣的場景呢？就是隨機的調整參數，你嘗試著或者說猜測性的對參數進行調整，并沒有直觀的邏輯關系證明它會有影響，你只是在賭博。如果現象消失了你可能假設的認為這種方式取得了效果，這種方式其實有很大的偶然性，并不能很好的解決問題，所以要盡量避免。另一種是“街燈”式的優化，只看到了眼前一點點的情況，就是選擇自己熟悉的工具或者隨便從互聯網上找到一個工具，甚至隨機選擇一款工具就作為你參考的依據，這些方法都有很大的弊端。

 

 

一個比較有效的方法我們強調是基于觀察，使用一些統計工具觀察系統的性能和資源的使用情況，用數據來證明你的優化是高效的。從使用方式來看就是對硬件和軟件的組件，逐一進行分解，研究每個組件可以調整的參數，并且有一個明確的、量化的預期，通過調整參數看能不能滿足預期來達到優化目的。

 

 

這里面特別強調的一個方法，叫做USE，就是利用率、飽和度和錯誤數。這個方法在一本書里面講的非常詳細，叫做《Systems Performance》，它就強調了用利用率、飽和度、錯誤數這三個維度幫助我們進行調整優化，在這本書里有非常詳細的描述。

 

 

除了剛才談到的方法之外還有一些地方需要大家考慮：

 

•在云計算的環境里面，有的時候復雜的問題并沒有明確的答案，即使是你做了嘗試和調整也沒有答案，有可能是你需要換一個實例了，比如換一個更大的型號或者更強勁的實例才能幫助解決問題。

 

•有時候分析之后確認與實例有關，但是大多數可能與應用有關，這從統計數據來看符合80/20原則，也就是說80%可能性與應用有關，只有20%是跟基礎架構操作系統有關的。簡單來說80%是跟應用程序本身有關的，通過程序的優化和重構就可以滿足或者解決應用問題，只有20%的場景里面你需要對操作系統基礎架構優化，才可以解決，大家一定要記得，不要上來就嘗試對操作系統進行太多的優化，可能欲速則不達。

 

•有些場景會有些意外，比如說延遲異常的場景，20%是由代碼引起的，更多的因素是由實例的類型、網絡的選擇、垃圾回收等產生的。

 

在分析方法上，對于負載的分析，建議是自頂向下，從應用的負載著手，然后分解請求時間。對資源的分析建議自下而上，從資源的性能開始著手，然后是工作負載，大家在分析的時候可以靈活掌握。

 

對于性能工具，除了云計算平臺提供的觀察工具之外還有一些系統的工具，可以對操作系統的核心進行很好的統計，這里我們介紹四大方面的工具給大家參考。

 

•Statistical 工具即統計工具，包括vmstat、pidstat、sar等等。需要強調的是這些工具沒有安裝到AWS EC2的缺省環境里面，需要手工安裝，安裝之后你可以看到對網絡狀況非常詳細的統計。

 

•profiling 工具，就是對CPU堆棧進行跟蹤，解釋CPU的使用情況，對內存對象進行跟蹤，解釋內存的使用情況，產生的調優就是對熱代碼的路徑進行調整和配置，比如熱代碼的問題，如果定位以后可能是真正的瓶頸，你可以聚焦在這點解決最終最根本的問題。另外對頻繁的對象的分配，尤其是內存使用上，也可以利用這些方法和工具幫我們解決它。針對這個程序有很多不同的profiling工具，這里面推薦的就是Lightweight Java Profiler 的工具。

 

LJP 是一個開源的項目，主要針對java。優點有兩點，第一就是精度非常高，第二就是支持火焰圖的輸出。火焰圖是一個非常好玩的東西，也非常直觀。下面是一個火焰圖的例子，其實非常簡單，Y軸是堆棧的情況，X軸是取樣頻度的情況。通過這個圖既使你沒有太多的時間或者缺少經驗也可以幫助你定位到一個方向，從而優化和解決問題，所以火焰圖是比較推薦的方法。系統的profiling是一個perf的工具，perf也可以生成CPU的火焰圖，火焰圖這個工具也是開源項目。

 

 

•Tracing的工具非常多，包括ftrace、perf_events等等，不給大家特別強調了。需要給大家強調的就是ftrace，現在已經是Linux的組成部分了，如果你打開代碼的話可以在原代碼當中看到。iosnoop是一個開源項目，大家用這個名字可以下載到，但是需要你編譯一下，小小的工作并不復雜。而且我的經驗來看，絕大多數Linux環境里面依賴庫并不復雜，工作量蠻小的。

 

•Hardware 計數器。比較特別一點的就是MSR，就是硬件的計數器，通過這個計數器提供了很多基本的信息，不同的型號會有差別。在大部分AWS EC2的實例中都已經支持MSR的特點了，利用這個特點就可以完成很多對CPU低級別的監控操作。其實MSR工具也是一個GitHub的工具，它能做很多有意思的事情，比如說對CPU的型號、頻率、狀態等等進行數據的獲取，然后通過這些數據定位你所需要的一些信息，就可以找到你需要調優的幾個點。


 

歸納起來今天講了很多工具，講了一些需要注意的原則。我想把最后這三點作為總結分享給大家的經驗。

 

•第一，在云計算環境里面，由于我們面對的環境不同于物理環境，有更多的虛擬資源，有更多的選擇項。對于優化的場景來說，選擇一個合適的實例就等于性能優化，大家千萬不要小瞧這個結論，也是很多的經驗換來了。

 

•第二，按照80/20原則，在需要的時候你可以使用Linux內核、性能優化或者統計的方法進行觀察，并且基于數據實現對核心的調優。最重要的是所有的優化都是基于監測的結果，都是由數據驅動的，所以千萬不要忽略掉。

 

•使用你手上所有的工具，包括云計算平臺上的工具、操作系統自帶的工具以及我們可以下載的工具來獲得你的數據，用數據來說服你選擇哪一個優化的方向。