《為什么我的服務器資源使用率這么低？》要點：
本文介紹了為什么我的服務器資源使用率這么低？，希望對您有用。如果有疑問，可以聯系我們。

最近在做提高資源使用效率的項目,有一些思考和大家分享一下.提高資源使用效率可以從很多方面下手,比如以下幾個方面都有很多工作可以做：

改進工作流程

提高員工工作效率

提高服務器資源使用率

提高軟件性能

這里只關注如何提高服務器的資源使用率.

除非業務處于高速發展期,新增流量帶來的收益遠大于新增服務器的成本,否則公司財務和部門大佬們就會開始關注服務器的資源使用率了.在新機器采購訂單提交到財務部門后,你需要有理由說明,為什么現有服務器的使用率這么低,你仍然需要訂購服務器來支撐X%的流量增長?

為什么服務器的資源使用率這么低?

為了把這個問題解釋清楚,讓我們先定義一個概念：

最高可用資源使用率：整體計算資源中,可用于滿足業務需求的最大計算資源的占比.

這個最高可用資源使用率適用于單個服務器,也適用于整個集群.最重要的一點是,這個值遠小于100%,而且一般服務器/集群的資源使用率遠小于最高可用資源使用率.

最高可用資源使用率主要受以下兩個因素限制：

冗余策略

這是第一個硬性指標,假設你的冗余策略是N+X,那么你的業務可用達到的最高可用資源使用率為：N/(N+X).

以N+1為例,這允許你的業務有一個最大的集群掛掉而不影響服務,理想情況下是你的每個集群規模都一樣大,掛掉任何一個損失都是一樣的,如果N=3,這時你的最高可用資源使用率為3/(3+1)=75%.注意這個值是假設你的每個集群規模都一樣大,實際中往往不是這樣的,所以你的最高可用資源使用率會小于75%!

隨著N的變大,最高可用資源使用率也會提高,如果N=7,那么你的最高可用資源使用率為7/(7+1)=87.5%.但是當N變的很大時,最高可用資源使用率帶來的收益會被運維成本的增加大幅削減.

響應時間

這是第二個硬性指標,響應時間會影響冗余策略的制定,但是這里我們不展開討論,將來有機會再詳細介紹.響應時間的大小會很大程度上制約最高可用資源使用率,為什么呢?在同樣流量的情況下,根據排隊論,不同的響應時間和服務隊列(對應到CPU,或者機器)對應著不同的最大資源使用率.

Utilizationcurve

假設你的業務由一個程序提供,這個程序每個副本需要16個CPU,那么根據排隊論,為了能夠在指定時間內完成業務請求,最高的資源使用率大約是81%.

加上冗余策略,還是以前面的N+1,N=3為例,該業務的最高可用資源使用率是75%*81%=61%.

這個最高可用資源使用率只是一個理論上限,實際上業務可以達到的資源使用率還受到很多其他因素影響,導致其最終使用率會遠小于這個理論值.

軟件性能問題

軟件的代碼編寫質量太差,參數設置不合理等都會影響資源的使用率,使得業務要在預定的響應時間返回結果,必須要保持較低的資源使用率.

組件間資源使用率差異

前面提到了,根據排隊論對性能的影響,不同的組件副本使用不同的CPU個數,導致的不同組件的最高可用資源使用率不同,進一步降低了總體資源使用率.

備用機器資源

為了應對臨時的機器維修,突發業務需求,業務會有額外的備用機器,這些備用機器一般會放在業務線自己的池子里面,會進一步的降低總體的資源使用率.

資源使用率計算方法

不同的資源使用率計算方法,會對外呈現不同的資源使用率,歷史平均使用率還是百分位使用率,是截然不同的兩個結果.

如何提高服務器的資源使用率?

前面提到了,對于一個N+1,N=3的業務,理論上最高可用資源使用率僅能達到61%,而實際中卻比61%小很多,能達到40%就很不錯了,那么如何從技術上來提高資源使用率,使其進一步的接近理論上限呢?

簡單容易實現的：

多線程更好的利用多核機器

根據排隊論,增加單個程序副本的CPU數目,可以有效提高資源使用率.

4CPUvs.16CPU

但是當線程過多時,會帶來contention等問題,以及NUMA架構帶來的遠程內存訪問都會影響資源使用率的提高.這里需要權衡,而不能一味的增加CPU和線程數目.

同一服務器上運行多個應用

既然一個程序不能最大化的利用一臺服務器的資源,那我們可以放多個不同的程序上去,通過共享來提高資源使用率.這個方法非常有效,但是也有它自己的問題,后面我們會提到.

增大響應時間

隨著資源使用率的提高,應用的響應時間會變長,如果在滿足現有業務需求的情況下,并不需要太快的響應時間,可以考慮通過增大響應時間來獲得更高的資源使用率.當然,這個方法是實際操作中使用的很少,因為響應時間增大很容易,但是要降低非常非常的難!

復雜實現難度高的：

資源分層

這其實也是通過共享資源來提高使用率,不同于直接在某臺服務器上運行多個程序,資源分層以后可以針對不同的層級提供不同的服務質量保證,例如保證高優先級程序的資源使用,當出現資源短缺時低優先級程序可以等待.

資源超賣

即使是通過分層的資源來提高使用率,不同的高優先級程序同時運行在一臺服務器上也不會同時處理峰值流量,利用這個特點,可以對計算資源超賣,來進一步提高資源使用率.

舉個簡單例子：服務器S有48個CPU,3個程序運行在這臺服務器上,分別請求了24,16和8個CPU,但是由于不同時處理峰值流量,在任意時刻該服務器的CPU使用率都不超過32個CPU,那么資源超賣就運行對剩余的16個CPU進行再次售賣.

提高資源使用率會帶來哪些問題和挑戰?

提高資源使用率有很多好處,但是事情都有兩面性,隨之而來的也有很多問題和挑戰.

裝箱問題(binpacking)

當有很多不同大小的應用,要運行在一組服務器上時,裝箱問題會降低資源的使用率.比如有100個應用總計需要1000個CPU,理論上只需要209臺48核的服務器,但是實際上由于裝箱問題,會需要250臺服務器.所以,解決裝箱問題是和資源共享伴生的一個技術難題.

隔離問題(badneighbours)

不同的應用有不同的特點,有IO密集型的也有CPU密集型的,有對延遲要求很高的也有只關心吞吐量的,這些不同的應用運行在同一臺服務器上,不可避免的對彼此產生影響,尤其是在機器的資源使用率較高的情況下.如何降低彼此的影響也是一個很難的課題.因為如果不能很好的隔離影響,應用則會選擇要么單獨運行要么申請更多的資源,從而導致資源使用率很低.

核算問題(resourceaccounting)

核算問題只存在于超賣的資源上,因為超賣的資源只能提供較低的服務質量保證,所以價格一定會更便宜,但是依然需要準確的衡量.

如何衡量提升資源使用率是否成功?

首先要保證的是,不能降低業務的穩定性和可靠性；其次是帶來的收益要大于成本；必須是一個持久的過程,而不是短暫的.

要權衡帶來的收益和成本,也許提升X%的資源使用率會增加YY毫秒的請求延遲,由此帶來的收入損失可能遠遠大于X%的提升帶來的收益.再有就是使用率的提升可能伴隨著運維成本的暴增,這些都是需要衡量然后取舍的.

結束語

提高服務器資源使用率,是一個跨越部門和技術邊界的問題：首先要確保的是最小化對業務的影響,通過準確的衡量系統計量應用對資源的使用情況,利用底層基礎設施實現資源共享并最小化隔離問題,從而最大程度的利用已有計算資源.

文中兩張照片來自論文ThinkingClearlyaboutPerformance,回復“utilization”獲得該論文電子版.

 

文章來自微信公眾號“云中慢步(cloudify)”：在硅谷原創分享分布式系統、數據中心生產環境、云計算前沿的實踐經驗和剖析研究

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4409.html