摘要：前言 性能調(diào)優(yōu)是一個老生常談的話題，通常情況下，一個應用在上線之前會進行容量規(guī)劃、壓力測試并進行驗證，而性能調(diào)優(yōu)則是在容量規(guī)劃與驗證結(jié)果之間出現(xiàn)差異時會進行的必然手段。從某種角度來講，性能調(diào)優(yōu)是一個非常需要經(jīng)驗的領(lǐng)域，需要調(diào)優(yōu)人員對應用的架構(gòu)、調(diào)用的鏈路、使用的語言、操作系統(tǒng)的差異、內(nèi)核的參數(shù)表現(xiàn)等等都有完整的了解。

前言

性能調(diào)優(yōu)是一個老生常談的話題，通常情況下，一個應用在上線之前會進行容量規(guī)劃、壓力測試并進行驗證，而性能調(diào)優(yōu)則是在容量規(guī)劃與驗證結(jié)果之間出現(xiàn)差異時會進行的必然手段。從某種角度來講，性能調(diào)優(yōu)是一個非常需要經(jīng)驗的領(lǐng)域，需要調(diào)優(yōu)人員對應用的架構(gòu)、調(diào)用的鏈路、使用的語言、操作系統(tǒng)的差異、內(nèi)核的參數(shù)表現(xiàn)等等都有完整的了解。大部分情況下，系統(tǒng)性能調(diào)優(yōu)都是通過各種各樣的工具監(jiān)聽、跟蹤、分析、檢測來檢查解決的。所以通常情況下，性能調(diào)優(yōu)的老手都有一套自己的診斷工具集以及相應的診斷方式。但是當性能調(diào)優(yōu)遇到Docker的時候，很多事情發(fā)生了轉(zhuǎn)變甚至惡化。

經(jīng)常有客戶抱怨說應用進入Docker后，應用的QPS無法和ECS進行媲美，并且時常會出現(xiàn)DNS查詢超時、短連接TIME_OUT、網(wǎng)絡(luò)丟包等等，這極大打擊了客戶對使用容器技術(shù)的信心與決心。誠然，容器化的方式根據(jù)網(wǎng)絡(luò)模型的不同，會在傳輸效率上面略有差異，但遠遠達不到客戶反饋的性能損耗，而在容器中進行調(diào)優(yōu)與診斷的效果因為安裝工具的復雜度大大折扣。

那么到底該如何針對容器的場景進行調(diào)優(yōu)呢？

性能調(diào)優(yōu)的“望聞問切”

在討論容器化場景的性能調(diào)優(yōu)之前，想先和大家談一下性能調(diào)優(yōu)中的“望聞問切”的問題。對于性能問題，大部分人第一個想到的是CPU利用率高，但是得到CPU利用率高這個現(xiàn)象后，我們改如何解決呢？從某種意義來講，這個只是現(xiàn)象，并不是癥狀。為了方便大家理解，在此我打一個比方：感冒的時候我們?nèi)メt(yī)院看病，病人跟大夫描述的是現(xiàn)象，包括頭部發(fā)熱、流鼻涕等等；而大夫通過探查、化驗，得到的醫(yī)學癥狀是病人的白細胞較多，喉嚨有紅腫等等，然后大夫確診是細菌性感冒，給你開了999感冒靈。診斷病情的過程和性能調(diào)優(yōu)是一樣的，也需要找到現(xiàn)象、癥狀和解法。我們回到剛才CPU利用率高的例子：我們已知的現(xiàn)象是CPU的利用率高，然后我們通過strace進行檢查，發(fā)現(xiàn)futex_wait系統(tǒng)調(diào)用占用了80%的CPU時間，而這才是真正的癥狀，根據(jù)這個癥狀，我們業(yè)務(wù)邏輯代碼降低了線程切換，CPU利用率降低。

大部分的性能調(diào)優(yōu)問題都可以通過發(fā)現(xiàn)現(xiàn)象、探測癥狀、解決問題這三個步驟來進行，而這在容器的性能調(diào)優(yōu)中就更為重要的，因為在主機的性能調(diào)優(yōu)過程中，我們有很多的經(jīng)驗可以快速找到癥狀，但是在容器的場景中，很多客戶只能告訴我們的是現(xiàn)象。從某種角度來講是由于客戶并不了解使用的容器引擎的工作原理以及容器化架構(gòu)的實現(xiàn)方式。那么接下來我們來看下容器化場景中性能調(diào)優(yōu)面對的挑戰(zhàn)。

容器化性能調(diào)優(yōu)的難點

VM級別的調(diào)優(yōu)方式在容器中實現(xiàn)難度較大
在VM級別我們看到的即是所有，網(wǎng)絡(luò)棧是完整暴漏在我們面前的，CPU、內(nèi)存、磁盤等也是完全沒有限制的。性能調(diào)優(yōu)老司機的工具箱安個遍，診斷流程走一趟基本問題就查個八九不離十了，但是在容器中，很多時候，都是默認不自帶診斷、調(diào)優(yōu)工具的，很多時候連ping或者telnet等等基礎(chǔ)命令都沒有，這導致大部分情況下我們需要以黑盒的方式看待一個容器，所有的癥狀只能從VM層的鏈路來看。但是我們知道容器通過namespace的隔離，具備完整網(wǎng)絡(luò)棧，CPU、內(nèi)存等通過隔離，只能使用limit的資源，如果將容器當做黑盒會導致很多時候問題癥狀難以快速發(fā)現(xiàn)。排查問題的方式變難了。

容器化后應用的鏈路邊長導致排查問題成本變大
容器的場景帶來很多酷炫的功能和技術(shù)，比如故障自動恢復，彈性伸縮，跨主機調(diào)度等等，但是這一切的代價是需要依賴容器化的架構(gòu)，比如Kubernetes網(wǎng)絡(luò)中需要FullNat的方式完成兩層網(wǎng)絡(luò)的轉(zhuǎn)發(fā)等等，這會給排查問題帶來更復雜的問題，當你不清楚編排引擎的架構(gòu)實現(xiàn)原理的時候，很難將問題指向這些平時不會遇到的場景。例如上面這個例子中，FullNat的好處是降低了網(wǎng)絡(luò)整體方案的復雜性，但是也引入了一些NAT場景下的常見問題，比如短連接場景中的SNAT五元組重合導致包重傳的問題等等。排查問題的方位變大了。

不完整隔離帶來的調(diào)優(yōu)復雜性
容器技術(shù)本質(zhì)是一種虛擬化技術(shù)，提到虛擬化技術(shù)就離不開隔離性，雖然我們平時并不需要去考慮隔離的安全性問題，但是當遇到性能調(diào)優(yōu)的時候，我們發(fā)現(xiàn)內(nèi)核的共享使我們不得不面對的是一個更復雜的場景。舉個，由于內(nèi)核的共享， 系統(tǒng)的proc是以只讀的方式進行掛載的，這就意味著系統(tǒng)內(nèi)核參數(shù)的調(diào)整會帶來的宿主機級別的變更。在性能調(diào)優(yōu)領(lǐng)域經(jīng)常有人提到C10K或者C100K等等類似的問題，這些問題難免涉及到內(nèi)核參數(shù)的調(diào)整，但是越特定的場景調(diào)優(yōu)的參數(shù)越不同，有時會有彼之蜜糖，我之毒藥的效果。因此同一個節(jié)點上的不同容器會出現(xiàn)非常離奇的現(xiàn)象。

不同語言對cgroup的支持
這個問題其實大多數(shù)場景下我們是不去考慮的，但是在此我們把他列在第四位的原因是期望能夠引起大家的重視。一次在和Oracel Java基礎(chǔ)庫的負責同學聊天中了解到Java針對與Cgroup的場景做了大量的優(yōu)化，而且時至今日，在Java的標準庫中對于Cgroup的支持還是不完全的，好在這點在大多數(shù)的場景中是沒有任何影響，也就不過多的討論。排查問題的腦洞更大了。

網(wǎng)絡(luò)方案不同帶來的特定場景的先天缺欠
提到容器架構(gòu)我們逃不掉的話題是網(wǎng)絡(luò)、存儲和調(diào)度，網(wǎng)絡(luò)往往是一個容器架構(gòu)好壞的最根本的評判標準，不同的網(wǎng)絡(luò)方案也會有不同的實現(xiàn)方式與問題。比如在阿里云的Kubernetes中我們使用了Flannel的CNI插件實現(xiàn)的網(wǎng)絡(luò)方案，標準Flannel支持的Vxlan的網(wǎng)絡(luò)方案，Docker的Overlay的macVlan，ipvlan的方案等等。這些不同的網(wǎng)絡(luò)方案無一例外都是分布式的網(wǎng)絡(luò)方案而存儲的數(shù)據(jù)都會存放在一個中心存儲中，因此越大型的集群對網(wǎng)絡(luò)中心存儲的壓力也就越大，出錯的可能性就越大。此外跨宿主機的二層網(wǎng)絡(luò)很多都會通過一些封包解包的方式來進行數(shù)據(jù)傳輸，這種方式難免會增加額外的系能損耗，這是一種先天的缺欠，并不是調(diào)優(yōu)能夠解決的問題。有的時候排查出問題也只能繞過而不是調(diào)優(yōu)。

鏡像化的系統(tǒng)環(huán)境、語言版本的差異
應用容器化是一個需要特別值得注意的問題，很多公司其實并沒有嚴格的配管流程，比如系統(tǒng)依賴的內(nèi)核版本、語言的小版本等等，進行應用容器化很多時候都是選擇一個大概的版本，這會帶來很多語言層級的BUG,比如PHP7.0中php-fpm的詭異行為，而這個現(xiàn)象在客戶原本的5.6版本上已經(jīng)修復過了。環(huán)境的問題本是一個嚴肅的問題，需要嚴格個管控，但是當遇到了容器，很多時候我們會分不清哪些不經(jīng)意的行為會帶來嚴重的問題。警惕性因為容器鏡像能夠正常啟動而降低。

最后

這篇文章中我們主要討論了基礎(chǔ)的性能調(diào)優(yōu)的方式以及容器化場景中性能調(diào)優(yōu)的難點，在下篇文章中我們會來套路下不同的性能瓶頸現(xiàn)象對應的診斷和調(diào)優(yōu)方法。

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載，如需轉(zhuǎn)載請發(fā)送郵件至yqeditor@list.alibaba-inc.com；如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：yqgroup@service.aliyun.com 進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

原文鏈接

轉(zhuǎn)載于:https://juejin.im/post/5a69a4a1518825732258e649

總結(jié)

以上是生活随笔為你收集整理的Docker中应用的性能调优指南（一）- 先谈谈容器化性能调优的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。