亞馬遜AWS首席云計(jì)算技術(shù)顧問 費(fèi)良宏于基于云架構(gòu)的性能優(yōu)化專場發(fā)表了題為《AWS 云計(jì)算之上Linux實(shí)例的優(yōu)化》的演講，現(xiàn)場分享了AWS 上Linux 實(shí)例的深度優(yōu)化和實(shí)踐，這對于云計(jì)算的而言是最基礎(chǔ)但卻是不可缺少的一環(huán)。

 

 

 

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

 

提到云計(jì)算我想先介紹一下AWS，大家可能知道AWS是云計(jì)算服務(wù)的提供者，到目前為止AWS在全球有13個(gè)區(qū)域，其中包括35個(gè)可用區(qū)，有56個(gè)邊緣站點(diǎn)，這些構(gòu)成了全球云計(jì)算的基礎(chǔ)架構(gòu)，服務(wù)于全球190個(gè)國家。

 

在過去的十年里通過這樣的發(fā)展，AWS現(xiàn)在所提供的服務(wù)范圍是非常廣泛的，涵蓋的種類不僅包括了計(jì)算、網(wǎng)絡(luò)、存儲、數(shù)據(jù)庫、大數(shù)據(jù)、人工智能，還包括了像安全，甚至像SaaS等等一些新的云計(jì)算的領(lǐng)域。

 

在今年8月6號發(fā)布的云計(jì)算IaaS魔力象限里面，AWS又處于報(bào)告的絕對領(lǐng)先位置。在這個(gè)報(bào)告出現(xiàn)的6年時(shí)間里，每次AWS都處于絕對領(lǐng)先的位置，這個(gè)報(bào)告也代表了AWS在整個(gè)云計(jì)算市場的位置。

 

如果使用過AWS的人，恐怕第一個(gè)接觸的產(chǎn)品都是AWS所提供的彈性虛擬服務(wù)器，我們稱之為EC2，這個(gè)產(chǎn)品也是我今天談的重點(diǎn)話題，也就是如何針對這樣的環(huán)境進(jìn)行優(yōu)化。

 

大家都了解在云計(jì)算的環(huán)境里面包括在數(shù)據(jù)中心里面會有很多物理服務(wù)器，服務(wù)器之上通過虛擬化的技術(shù)會提供許許多多的虛擬機(jī)，如何使用這些虛擬機(jī)的資源，讓它更好的服務(wù)于我們的應(yīng)用，這是我們面臨的一個(gè)很現(xiàn)實(shí)的問題。

 

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

 

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

 

 

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

 

 

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

 

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

 

 

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

 

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

 

 

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

 

EC2的技術(shù)特性里有一些是需要讓大家了解，并且可以應(yīng)用這些技術(shù)進(jìn)行優(yōu)化，我大概列舉了以下這些內(nèi)容。

 

•CPU 指令核保護(hù)等級。對于X86這款CPU大家比較清楚熟悉，這款架構(gòu)有明顯的特征，就是指令核的保護(hù)等級，而且不能在用戶模式下執(zhí)行特權(quán)指令來保護(hù)系統(tǒng)，應(yīng)用程序通過syscall實(shí)現(xiàn)內(nèi)核調(diào)用的完成。比如我們針對一個(gè)Web服務(wù)器，使用strace就可以看到不同的調(diào)用，有效的減少這些調(diào)用可以明顯提升性能。

 

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

 

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

 

 

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

 

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

 

回到Linux內(nèi)核這個(gè)話題，我們來看看針對剛才談到的技術(shù)特點(diǎn)，如何利用技術(shù)手段幫助我們進(jìn)行優(yōu)化。我們簡單來說有七大方面，就是CPU調(diào)度器、虛擬內(nèi)存、巨型頁、文件系統(tǒng)、存儲的IO、網(wǎng)絡(luò)、Hypervisor 。針對不同的場景會有各種優(yōu)化的選項(xiàng)和策略，如果進(jìn)行適當(dāng)調(diào)整，在某種意義上對我們應(yīng)用的性能會有很大的提升。

 

 

比如說如果安裝了schedtool這款工具，這個(gè)工具可以通過GitHub搜索下載。使用之后可以針對每一個(gè)值進(jìn)行特殊的處理，我在圖中列出了一個(gè)特性，用B參數(shù)使長時(shí)間運(yùn)行的進(jìn)程得到一個(gè)非常好的性能優(yōu)化，減少了上下文的切換。如果強(qiáng)調(diào)實(shí)時(shí)性，可以用R參數(shù)進(jìn)行特定的優(yōu)化。

 

 

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

 

 

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

 

 

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

 

 

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

 

 

對于網(wǎng)絡(luò)，大家都很清楚，我們有很多的網(wǎng)絡(luò)優(yōu)化項(xiàng)進(jìn)行調(diào)整和設(shè)置，這些優(yōu)化項(xiàng)種類和數(shù)量非常多，其中包含了像buffer sizes、backlog等，這些項(xiàng)大家可以針對具體的經(jīng)驗(yàn)進(jìn)行優(yōu)化處理。

 

 

還有一種應(yīng)用場景就是在虛擬化的環(huán)境里面，云計(jì)算里面經(jīng)常會遇到的，針對Hypervisor 的優(yōu)化。最主要的優(yōu)化項(xiàng)就是clocksource，包括像hpet、xen、tsc等等。

 

 

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

 

 

我們剛才提到了監(jiān)測，在AWS的環(huán)境里面有很多服務(wù)可以幫助我們達(dá)成這個(gè)目標(biāo)。以這個(gè)WebServer為例，在這個(gè)場景里面，可以通過監(jiān)控看到不同WebServer請求的表現(xiàn)，也可以看到內(nèi)存的使用情況，包括磁盤的統(tǒng)計(jì)情況、網(wǎng)絡(luò)的使用統(tǒng)計(jì)等等，所有的監(jiān)控指標(biāo)都是我們進(jìn)行優(yōu)化的非常重要的基礎(chǔ)條件。

 

 

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

 

 

一個(gè)比較有效的方法我們強(qiáng)調(diào)是基于觀察，使用一些統(tǒng)計(jì)工具觀察系統(tǒng)的性能和資源的使用情況，用數(shù)據(jù)來證明你的優(yōu)化是高效的。從使用方式來看就是對硬件和軟件的組件，逐一進(jìn)行分解，研究每個(gè)組件可以調(diào)整的參數(shù)，并且有一個(gè)明確的、量化的預(yù)期，通過調(diào)整參數(shù)看能不能滿足預(yù)期來達(dá)到優(yōu)化目的。

 

 

這里面特別強(qiáng)調(diào)的一個(gè)方法，叫做USE，就是利用率、飽和度和錯(cuò)誤數(shù)。這個(gè)方法在一本書里面講的非常詳細(xì)，叫做《Systems Performance》，它就強(qiáng)調(diào)了用利用率、飽和度、錯(cuò)誤數(shù)這三個(gè)維度幫助我們進(jìn)行調(diào)整優(yōu)化，在這本書里有非常詳細(xì)的描述。

 

 

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

 

•在云計(jì)算的環(huán)境里面，有的時(shí)候復(fù)雜的問題并沒有明確的答案，即使是你做了嘗試和調(diào)整也沒有答案，有可能是你需要換一個(gè)實(shí)例了，比如換一個(gè)更大的型號或者更強(qiáng)勁的實(shí)例才能幫助解決問題。

 

•有時(shí)候分析之后確認(rèn)與實(shí)例有關(guān)，但是大多數(shù)可能與應(yīng)用有關(guān)，這從統(tǒng)計(jì)數(shù)據(jù)來看符合80/20原則，也就是說80%可能性與應(yīng)用有關(guān)，只有20%是跟基礎(chǔ)架構(gòu)操作系統(tǒng)有關(guān)的。簡單來說80%是跟應(yīng)用程序本身有關(guān)的，通過程序的優(yōu)化和重構(gòu)就可以滿足或者解決應(yīng)用問題，只有20%的場景里面你需要對操作系統(tǒng)基礎(chǔ)架構(gòu)優(yōu)化，才可以解決，大家一定要記得，不要上來就嘗試對操作系統(tǒng)進(jìn)行太多的優(yōu)化，可能欲速則不達(dá)。

 

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

 

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

 

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

 

•Statistical 工具即統(tǒng)計(jì)工具，包括vmstat、pidstat、sar等等。需要強(qiáng)調(diào)的是這些工具沒有安裝到AWS EC2的缺省環(huán)境里面，需要手工安裝，安裝之后你可以看到對網(wǎng)絡(luò)狀況非常詳細(xì)的統(tǒng)計(jì)。

 

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

 

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

 

 

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

 

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


 

歸納起來今天講了很多工具，講了一些需要注意的原則。我想把最后這三點(diǎn)作為總結(jié)分享給大家的經(jīng)驗(yàn)。

 

•第一，在云計(jì)算環(huán)境里面，由于我們面對的環(huán)境不同于物理環(huán)境，有更多的虛擬資源，有更多的選擇項(xiàng)。對于優(yōu)化的場景來說，選擇一個(gè)合適的實(shí)例就等于性能優(yōu)化，大家千萬不要小瞧這個(gè)結(jié)論，也是很多的經(jīng)驗(yàn)換來了。

 

•第二，按照80/20原則，在需要的時(shí)候你可以使用Linux內(nèi)核、性能優(yōu)化或者統(tǒng)計(jì)的方法進(jìn)行觀察，并且基于數(shù)據(jù)實(shí)現(xiàn)對核心的調(diào)優(yōu)。最重要的是所有的優(yōu)化都是基于監(jiān)測的結(jié)果，都是由數(shù)據(jù)驅(qū)動的，所以千萬不要忽略掉。

 

•使用你手上所有的工具，包括云計(jì)算平臺上的工具、操作系統(tǒng)自帶的工具以及我們可以下載的工具來獲得你的數(shù)據(jù)，用數(shù)據(jù)來說服你選擇哪一個(gè)優(yōu)化的方向。