徐茂
(廣州廣晟數(shù)碼技術(shù)有限公司,廣東 廣州 510640)
流媒體服務器性能調(diào)優(yōu)關(guān)鍵點分析
徐茂
(廣州廣晟數(shù)碼技術(shù)有限公司,廣東 廣州 510640)
近年來,隨著流媒體業(yè)務的普及,以及基于流媒體服務的硬件和軟件平臺的發(fā)展,對流媒體服務器的性能調(diào)優(yōu)提出了新的挑戰(zhàn)。首先在概述了流媒體服務器發(fā)展背景、面臨挑戰(zhàn)的基礎(chǔ)上,提出性能調(diào)優(yōu)的重要性;然后分析流媒體服務器常見的性能瓶頸表征;最后結(jié)合實際案例,給出常用的性能調(diào)優(yōu)方法和技巧。
流媒體;性能瓶頸;性能調(diào)優(yōu);性能數(shù)據(jù)監(jiān)控;IO/CPU/內(nèi)存密集
隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展,流媒體服務已經(jīng)廣泛應用到人們生活的各個方面,既為工作提供了便利,也豐富了社會娛樂生活。而流媒體業(yè)務的蓬勃擴張,使傳統(tǒng)的流媒體服務系統(tǒng)面臨極大的挑戰(zhàn)。
流媒體通常指音視頻等多媒體技術(shù)在互聯(lián)網(wǎng)上的傳輸,典型的流媒體服務涵蓋了音視頻等媒體信息的存儲、編解碼、分發(fā)、傳輸?shù)榷喾N技術(shù)。流媒體服務器的性能指標既包括了并發(fā)、吞吐、響應時間等常見參數(shù),也包括音視頻服務質(zhì)量、直播切換時間等比較有特色的元素。
流媒體服務器系統(tǒng)售價通常以并發(fā)和吞吐為衡量指標,考慮到當前的硬件成本逐漸下降,主流流媒體服務器已經(jīng)開始采用較高配置的硬件,多CPU、高內(nèi)存、光口的2U/4U設備已經(jīng)被廣泛引入[1],基于這些新硬件的性能調(diào)優(yōu)和以往也有了較大的區(qū)別,而基于新硬件的性能調(diào)優(yōu)討論比較少,本文將基于新硬件進行討論,致力于補充這個方向的實踐積累。
流媒體服務是一種資源消耗集中的服務,流媒體服務器性能調(diào)優(yōu)通常會碰到多種資源使用瓶頸,性能瓶頸的分析是性能調(diào)優(yōu)的基礎(chǔ),為性能調(diào)優(yōu)提供方向,并為調(diào)優(yōu)策略的有效性提供數(shù)據(jù)支持。
流媒體服務器一般采用Linux系統(tǒng),而Linux提供了豐富的性能監(jiān)控計數(shù)器,基于這些計數(shù)器收集到的數(shù)據(jù),可以分析和定位服務器性能瓶頸,本章節(jié)將重點從CPU、內(nèi)存、磁盤、網(wǎng)絡等角度深入分析各種瓶頸出現(xiàn)的表征。
1.1 CPU
常用CPU監(jiān)控命令是top[2]和mpstat[2],top啟動后可以在交互區(qū)輸入“1”來查看多CPU服務器的各個CPU的負載詳情,而mpstat直接查看各個CPU的資源使用情況。CPU占用率信息基本樣式如下:Cpu0:0.0%us,0.2%sy,0.0%ni,98.3%id,1.4%wa,0.0%hi,0.0%si,0.0%st,該部分數(shù)據(jù)基于Linux的/proc/stat文件,更新單位是ticks,ticks就是系統(tǒng)時鐘中斷的時間間隔,ticks和內(nèi)核中的HZ值有關(guān),在內(nèi)核編譯時可配置,CentOS 6.4,HZ=1 000,ticks=1/HZ=1 ms。Top/mpstat看到的CPU,其中:%us=(User time+Nice time)×100%/CPU時間,%sy=(System time+Hard Irq time+softwareIRQ time)/CPU時間[3]。
監(jiān)控數(shù)據(jù)時,首先看%id,它表征了空閑CPU時間比例。若%id接近0,表示CPU即將耗盡,在此基礎(chǔ)上可以繼續(xù)分析各個類型的CPU比例是否存在異常以及是否還有優(yōu)化空間,比較重要的有%us,%sy,%wa,%si四個,分別代表用戶、系統(tǒng)、IO、軟中斷的CPU占用情況;若%id超過10%,表示CPU有較多空閑,基本可以判定CPU不構(gòu)成瓶頸。
對于多核CPU而言,需要觀察每個CPU的情況,任意一個CPU耗盡都會構(gòu)成性能瓶頸,另外CPU 0很關(guān)鍵,由它來負責多個CPU間的調(diào)度,若CPU 0比較高,則會影響多核的調(diào)度,從而降低整體CPU性能,通常而言,應用程序盡量避免對CPU 0的占用。
1.2 磁盤
磁盤監(jiān)控使用iostat/iotop[2]等命令,iostat可以看到每個磁盤的使用情況,iotop可以看到IO消耗從高到低的列表。Iostat看到的基本參數(shù)包括:rrqm/s,wrqm/s,r/s,w/s,rkB/s,wkB/s,avgrq-sz,avgqu-sz,await,svctm,%util,其中rrqm/s和wrqm/s表示單位時間內(nèi)的讀寫IO請求,avgrq-sz表征了平均每次IO請求的塊大小,avgqu-sz表征了單位時間內(nèi)的IO隊列長度,await代表平均每次IO請求的等待時間,svctm表示了平均每次IO請求的服務時間,%util則表示磁盤使用率。
首先觀察%util值,若%util遠低于100%,則表示在統(tǒng)計時間內(nèi)磁盤負載比較低,不構(gòu)成性能瓶頸,這時候可以觀察一下其他參數(shù)是否有異常,比如svctm,有時候即使是輕負載,若磁盤老化或異常,也會使服務時間過高。
若%util接近或達到100%,需要繼續(xù)觀察其他屬性,以定位資源耗盡的原因,若rrqm/s+wrqm/s很大,代表收到的IO請求頻繁,可以考慮通過減少請求頻率來優(yōu)化,這種情況下avgqu-sz和await應該也都比較大;若svctm比較大,則表示磁盤的服務時間較長,可能是磁盤老化故障,也有可能是請求數(shù)據(jù)過多(avgrq-sz比較大);avgrq-sz和吞吐成正比,和響應時間成反比,應用層調(diào)整每次請求的文件塊大小,可以影響到這個值的大小,同時影響到吞吐和響應時間。
機械磁盤的性能由尋址時間、旋轉(zhuǎn)時間和讀寫時間三部分決定,磁盤內(nèi)外磁道的尋址時間有明顯差別,而對于數(shù)據(jù)密集性的多媒體服務器而言,為了充分利用硬件,存儲比例通常達到硬盤容量的70%以上,因此性能測試及調(diào)優(yōu)時需要同時考慮到內(nèi)外磁道的性能區(qū)別。
1.3 內(nèi)存
內(nèi)存監(jiān)控可以使用free,top和vmstat命令[2],其中swap代表磁盤上交換分區(qū)的使用情況,一旦產(chǎn)生了swap,若非必要或機器重啟,swap不會清零,因此內(nèi)存瓶頸或耗盡的表征不是swap不為0,而是swap不斷增大。若從vmstat監(jiān)控來看,si/so表示每秒從磁盤讀入虛擬內(nèi)存的大小或從虛擬內(nèi)存寫入磁盤的大小,如果兩個值在一段時間內(nèi)都大于0,表示物理內(nèi)存不夠用或者內(nèi)存泄露了,需要頻繁地使用到swap空間。
1.4 網(wǎng)絡
使用sar可以查看網(wǎng)卡使用情況,根據(jù)網(wǎng)卡的使用率可以判定網(wǎng)卡硬件瓶頸。對于傳輸層瓶頸,可以使用netstat[2]和tcpdump[2]來看,比如查看netstat Recv-Q和Send-Q,若發(fā)送隊列和接收隊列比較大,且持續(xù)增加,代表了應用層網(wǎng)絡發(fā)送或接收出現(xiàn)了阻塞,而使用tcp?dump可以觀察到TCP傳輸層的問題,若出現(xiàn)了Ze?ro-Window,表示發(fā)送或接收緩存區(qū)已滿,導致TCP流控啟動。
1.5 文件句柄
使用lsof[2]和ulimit[2]命令,查看每個進程開啟的文件句柄和系統(tǒng)的文件打開限制數(shù),若進程開啟文件句柄大于配置的閾值,則進程運行就會出錯。
2.1 系統(tǒng)配置
硬件采用超微4U Server,配置如下:intel Xeon 2.00 GHz×24,Disk:7 500轉(zhuǎn);軟件流服務模塊采用Py?thon Twister框架,數(shù)據(jù)庫使用mysql,文件系統(tǒng)使用類GFS[4]的分布是文件系統(tǒng)DFS,操作系統(tǒng)使用CentOS 6.4版本,ext4虛擬文件系統(tǒng)。
2.2 調(diào)優(yōu)策略
2.2.1 CPU調(diào)優(yōu)
性能測試時出現(xiàn)過以下幾種CPU的問題,并給出了對應的解決方法:
1)多核CPU使用不均衡
(1)讓出CPU 0,盡量少使用CPU 0;
(2)靜態(tài)綁定不同進程或進程中的不同線程到不同的CPU上。
2)部分CPU si/sys過高
(1)si過高為多個網(wǎng)卡的軟中斷分配不均衡,為系統(tǒng)軟中斷調(diào)度缺陷,靜態(tài)綁定軟中斷可以解決;
(2)sys過高是系統(tǒng)調(diào)用太多引起,使用strace命令,跟蹤查看系統(tǒng)調(diào)用情況,找出使用較多并耗時較多的系統(tǒng)調(diào)用,比如fopen/read/write/fseek等,改進應用層設計,減少系統(tǒng)調(diào)用。
2.2.2 磁盤調(diào)優(yōu)
尋址時間比重在60%~70%之間,順序讀寫避免了這部分消耗,因此磁盤的隨機度性能遠低于磁盤的順序讀性能??紤]到流媒體服務一般是100 Mbyte以上的視頻文件,具備順序讀的可能性,若想提升磁盤吞吐,必須考慮到盡量減少隨機讀比例。
磁盤調(diào)優(yōu)實際就是結(jié)合應用場景,找出一個適合的磁盤使用方法,也就是在吞吐、時延、并發(fā)三個指標之間找一個均衡點。本案例采用兩個策略來優(yōu)化磁盤性能:1)調(diào)大每次提交的讀寫塊大小,由原有的64 kbyte,提高到256 kbyte;2)加入預讀機制,預先讀取1 Mbyte數(shù)據(jù)。實踐結(jié)果表明,這兩種策略促使性能提升了20%左右。
2.2.3 網(wǎng)絡調(diào)優(yōu)
1)網(wǎng)卡綁定模式
高性能的流媒體服務器硬件通常采用高性能的服務器配置,4~12個千兆網(wǎng)卡,或2~4個萬兆網(wǎng)卡,為提高網(wǎng)卡利用率,需要采用系統(tǒng)支持的網(wǎng)卡bonding技術(shù),bonding模式有多種,各種模式的應用方向和性能有區(qū)別,一般采用mode 0,mode 2和mode 6,mode 2具有IP親緣性,容易引起網(wǎng)卡負載失衡,mode 6在大壓力情況下,經(jīng)常出現(xiàn)丟包問題,實踐證明mode 0最為穩(wěn)定和高效,缺陷需要在交換機上進行相應的配置。
2)傳輸協(xié)議層
分布式文件系統(tǒng)DFS和流服務應用程序之間采用的也是基于TCP的網(wǎng)絡傳輸,TCP使用滑動窗口機制實現(xiàn)流控,測試時發(fā)現(xiàn)由于發(fā)送和接收速度不匹配,導致TCP窗口經(jīng)常變?yōu)?,極大地影響了二者之間的傳輸效率。改進方法有兩個:(1)在二者之間進行適配,這種方法實現(xiàn)比較困難,且不利于在DFS層面實現(xiàn)預讀;(2)在二者之間添加一個適配層,使用一個內(nèi)存buf?fer做緩存,這種方法實現(xiàn)容易,效率較高。實際改進時使用了方法2,實踐證明,緩存適配層的引入有效解決了zero-window的問題。
2.2.4 流服務層調(diào)優(yōu)
該流媒體服務系統(tǒng)提供了支持多種終端(PC/pad/ phone/STB)Http Live Steaming[5]服務,為增加服務的適配性,減少文件系統(tǒng)開銷,在服務器端使用的是虛擬切片技術(shù),即磁盤存儲的是完整的ts文件,由應用程序在內(nèi)存中完成切片。
由于HLS服務采用的是TCP短連接,上下片段間無任何關(guān)聯(lián),而每次請求ts片段(片段長度默認是10 s)服務器就需要去重新fopen文件,讀取完畢再fclose文件,時間消耗和CPU消耗都比較大,為了降低這種消耗,本文引入了文件句柄池,設計一張hash表在內(nèi)存中緩存打開過的文件句柄,根據(jù)最后訪問時間和更新時間等信息定時更新緩存表數(shù)據(jù),保證較高的命中率。經(jīng)過這種改進,HLS vod性能接近普通vod性能的80%。
2.2.5 其他
在性能測試時,還遇到了兩種情況:1)CPU虛高,%us消耗和實際的計算量不匹配,分析應用程序的設計,發(fā)現(xiàn)由輪詢間隔太小引發(fā),CPU空轉(zhuǎn)嚴重,增加輪詢間隔或更改輪詢機制,CPU使用降低了30%;2)從性能計數(shù)器分析,看不出明顯的性能瓶頸,但響應時間很大,并發(fā)數(shù)無法維持,播放出現(xiàn)卡頓,經(jīng)過分析是由并發(fā)調(diào)度中不恰當?shù)幕コ庖鸬摹?/p>
通過上述幾個方向的調(diào)優(yōu),流媒體服務器性能得到明顯的提升,使用碼率為800 kbit/s的VBR H.264片源測試,吞吐穩(wěn)定在8 Gbit/s以上,平均響應時間?0.5 s,CPU使用高于90%,磁盤使用率在70%左右,基本達到了硬件極限。
分析中發(fā)現(xiàn),接下來可以考慮兩個方向的優(yōu)化:1)繼續(xù)降低CPU user time的使用,對于流服務而言,計算量比較小,CPU消耗仍然遠高于理論值,空耗和等待比較多,仍然有較大優(yōu)化空間;2)考慮使用緩存技術(shù),對于熱點節(jié)目降低磁盤壓力,提升內(nèi)存利用率。
[1] MOLYNEAUX L.The art of application performanced testing [M].3rd ed.[S.l.]:Wiley,2011.
[2] Linuxmanpages[EB/OL].[2014-03-02].http://www.linuxmanpages. com/.
[3] Linux CPU占用率原理與精確度分析[EB/OL].[2014-03-02]. http://ilinuxkernel.com.
[4]GHEMAWAT S,GOBIOFF H,LEUNG S.The google file system [EB/OL]. [2014-03-02].http://pan.baidu.com/share/link?shareid= 2544600225&uk=3256658338&fid=1071906213170227.
[5] HTTP live streaming[EB/OL].[2014-03-02].http://zh.wikipedia. org/wiki/HTTP_Live_Streaming.
TN919;TP393
A
??雯
2014-03-23
【本文獻信息】徐茂.流媒體服務器性能調(diào)優(yōu)關(guān)鍵點分析[J].電視技術(shù),2014,38(12).