徐茂

（廣州廣晟數(shù)碼技術(shù)有限公司，廣東 廣州 510640）

流媒體服務(wù)器性能調(diào)優(yōu)關(guān)鍵點(diǎn)分析

徐茂

（廣州廣晟數(shù)碼技術(shù)有限公司，廣東 廣州 510640）

近年來，隨著流媒體業(yè)務(wù)的普及，以及基于流媒體服務(wù)的硬件和軟件平臺(tái)的發(fā)展，對(duì)流媒體服務(wù)器的性能調(diào)優(yōu)提出了新的挑戰(zhàn)。首先在概述了流媒體服務(wù)器發(fā)展背景、面臨挑戰(zhàn)的基礎(chǔ)上，提出性能調(diào)優(yōu)的重要性；然后分析流媒體服務(wù)器常見的性能瓶頸表征；最后結(jié)合實(shí)際案例，給出常用的性能調(diào)優(yōu)方法和技巧。

流媒體；性能瓶頸；性能調(diào)優(yōu)；性能數(shù)據(jù)監(jiān)控；IO/CPU/內(nèi)存密集

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，流媒體服務(wù)已經(jīng)廣泛應(yīng)用到人們生活的各個(gè)方面，既為工作提供了便利，也豐富了社會(huì)娛樂生活。而流媒體業(yè)務(wù)的蓬勃擴(kuò)張，使傳統(tǒng)的流媒體服務(wù)系統(tǒng)面臨極大的挑戰(zhàn)。

流媒體通常指音視頻等多媒體技術(shù)在互聯(lián)網(wǎng)上的傳輸，典型的流媒體服務(wù)涵蓋了音視頻等媒體信息的存儲(chǔ)、編解碼、分發(fā)、傳輸?shù)榷喾N技術(shù)。流媒體服務(wù)器的性能指標(biāo)既包括了并發(fā)、吞吐、響應(yīng)時(shí)間等常見參數(shù)，也包括音視頻服務(wù)質(zhì)量、直播切換時(shí)間等比較有特色的元素。

流媒體服務(wù)器系統(tǒng)售價(jià)通常以并發(fā)和吞吐為衡量指標(biāo)，考慮到當(dāng)前的硬件成本逐漸下降，主流流媒體服務(wù)器已經(jīng)開始采用較高配置的硬件，多CPU、高內(nèi)存、光口的2U/4U設(shè)備已經(jīng)被廣泛引入[1]，基于這些新硬件的性能調(diào)優(yōu)和以往也有了較大的區(qū)別，而基于新硬件的性能調(diào)優(yōu)討論比較少，本文將基于新硬件進(jìn)行討論，致力于補(bǔ)充這個(gè)方向的實(shí)踐積累。

1 性能瓶頸分析

流媒體服務(wù)是一種資源消耗集中的服務(wù)，流媒體服務(wù)器性能調(diào)優(yōu)通常會(huì)碰到多種資源使用瓶頸，性能瓶頸的分析是性能調(diào)優(yōu)的基礎(chǔ)，為性能調(diào)優(yōu)提供方向，并為調(diào)優(yōu)策略的有效性提供數(shù)據(jù)支持。

流媒體服務(wù)器一般采用Linux系統(tǒng)，而Linux提供了豐富的性能監(jiān)控計(jì)數(shù)器，基于這些計(jì)數(shù)器收集到的數(shù)據(jù)，可以分析和定位服務(wù)器性能瓶頸，本章節(jié)將重點(diǎn)從CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等角度深入分析各種瓶頸出現(xiàn)的表征。

1.1 CPU

常用CPU監(jiān)控命令是top[2]和mpstat[2]，top啟動(dòng)后可以在交互區(qū)輸入“1”來查看多CPU服務(wù)器的各個(gè)CPU的負(fù)載詳情，而mpstat直接查看各個(gè)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，該部分?jǐn)?shù)據(jù)基于Linux的/proc/stat文件，更新單位是ticks，ticks就是系統(tǒng)時(shí)鐘中斷的時(shí)間間隔，ticks和內(nèi)核中的HZ值有關(guān)，在內(nèi)核編譯時(shí)可配置，CentOS 6.4，HZ=1 000，ticks=1/HZ=1 ms。Top/mpstat看到的CPU，其中：%us=（User time+Nice time）×100%/CPU時(shí)間，%sy=（System time+Hard Irq time+softwareIRQ time）/CPU時(shí)間[3]。

監(jiān)控?cái)?shù)據(jù)時(shí)，首先看%id，它表征了空閑CPU時(shí)間比例。若%id接近0，表示CPU即將耗盡，在此基礎(chǔ)上可以繼續(xù)分析各個(gè)類型的CPU比例是否存在異常以及是否還有優(yōu)化空間，比較重要的有%us，%sy，%wa，%si四個(gè)，分別代表用戶、系統(tǒng)、IO、軟中斷的CPU占用情況；若%id超過10%，表示CPU有較多空閑，基本可以判定CPU不構(gòu)成瓶頸。

對(duì)于多核CPU而言，需要觀察每個(gè)CPU的情況，任意一個(gè)CPU耗盡都會(huì)構(gòu)成性能瓶頸，另外CPU 0很關(guān)鍵，由它來負(fù)責(zé)多個(gè)CPU間的調(diào)度，若CPU 0比較高，則會(huì)影響多核的調(diào)度，從而降低整體CPU性能，通常而言，應(yīng)用程序盡量避免對(duì)CPU 0的占用。

1.2 磁盤

磁盤監(jiān)控使用iostat/iotop[2]等命令，iostat可以看到每個(gè)磁盤的使用情況，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表示單位時(shí)間內(nèi)的讀寫IO請(qǐng)求，avgrq-sz表征了平均每次IO請(qǐng)求的塊大小，avgqu-sz表征了單位時(shí)間內(nèi)的IO隊(duì)列長度，await代表平均每次IO請(qǐng)求的等待時(shí)間，svctm表示了平均每次IO請(qǐng)求的服務(wù)時(shí)間，%util則表示磁盤使用率。

首先觀察%util值，若%util遠(yuǎn)低于100%，則表示在統(tǒng)計(jì)時(shí)間內(nèi)磁盤負(fù)載比較低，不構(gòu)成性能瓶頸，這時(shí)候可以觀察一下其他參數(shù)是否有異常，比如svctm，有時(shí)候即使是輕負(fù)載，若磁盤老化或異常，也會(huì)使服務(wù)時(shí)間過高。

若%util接近或達(dá)到100%，需要繼續(xù)觀察其他屬性，以定位資源耗盡的原因，若rrqm/s+wrqm/s很大，代表收到的IO請(qǐng)求頻繁，可以考慮通過減少請(qǐng)求頻率來優(yōu)化，這種情況下avgqu-sz和await應(yīng)該也都比較大；若svctm比較大，則表示磁盤的服務(wù)時(shí)間較長，可能是磁盤老化故障，也有可能是請(qǐng)求數(shù)據(jù)過多（avgrq-sz比較大）；avgrq-sz和吞吐成正比，和響應(yīng)時(shí)間成反比，應(yīng)用層調(diào)整每次請(qǐng)求的文件塊大小，可以影響到這個(gè)值的大小，同時(shí)影響到吞吐和響應(yīng)時(shí)間。

機(jī)械磁盤的性能由尋址時(shí)間、旋轉(zhuǎn)時(shí)間和讀寫時(shí)間三部分決定，磁盤內(nèi)外磁道的尋址時(shí)間有明顯差別，而對(duì)于數(shù)據(jù)密集性的多媒體服務(wù)器而言，為了充分利用硬件，存儲(chǔ)比例通常達(dá)到硬盤容量的70%以上，因此性能測試及調(diào)優(yōu)時(shí)需要同時(shí)考慮到內(nèi)外磁道的性能區(qū)別。

1.3 內(nèi)存

內(nèi)存監(jiān)控可以使用free，top和vmstat命令[2]，其中swap代表磁盤上交換分區(qū)的使用情況，一旦產(chǎn)生了swap，若非必要或機(jī)器重啟，swap不會(huì)清零，因此內(nèi)存瓶頸或耗盡的表征不是swap不為0，而是swap不斷增大。若從vmstat監(jiān)控來看，si/so表示每秒從磁盤讀入虛擬內(nèi)存的大小或從虛擬內(nèi)存寫入磁盤的大小，如果兩個(gè)值在一段時(shí)間內(nèi)都大于0，表示物理內(nèi)存不夠用或者內(nèi)存泄露了，需要頻繁地使用到swap空間。

1.4 網(wǎng)絡(luò)

使用sar可以查看網(wǎng)卡使用情況，根據(jù)網(wǎng)卡的使用率可以判定網(wǎng)卡硬件瓶頸。對(duì)于傳輸層瓶頸，可以使用netstat[2]和tcpdump[2]來看，比如查看netstat Recv-Q和Send-Q，若發(fā)送隊(duì)列和接收隊(duì)列比較大，且持續(xù)增加，代表了應(yīng)用層網(wǎng)絡(luò)發(fā)送或接收出現(xiàn)了阻塞，而使用tcp?dump可以觀察到TCP傳輸層的問題，若出現(xiàn)了Ze?ro-Window，表示發(fā)送或接收緩存區(qū)已滿，導(dǎo)致TCP流控啟動(dòng)。

1.5 文件句柄

使用lsof[2]和ulimit[2]命令，查看每個(gè)進(jìn)程開啟的文件句柄和系統(tǒng)的文件打開限制數(shù)，若進(jìn)程開啟文件句柄大于配置的閾值，則進(jìn)程運(yùn)行就會(huì)出錯(cuò)。

2 性能調(diào)優(yōu)案例分析

2.1 系統(tǒng)配置

硬件采用超微4U Server，配置如下：intel Xeon 2.00 GHz×24，Disk：7 500轉(zhuǎn)；軟件流服務(wù)模塊采用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)

性能測試時(shí)出現(xiàn)過以下幾種CPU的問題，并給出了對(duì)應(yīng)的解決方法：

1）多核CPU使用不均衡

（1）讓出CPU 0，盡量少使用CPU 0；

（2）靜態(tài)綁定不同進(jìn)程或進(jìn)程中的不同線程到不同的CPU上。

2）部分CPU si/sys過高

（1）si過高為多個(gè)網(wǎng)卡的軟中斷分配不均衡，為系統(tǒng)軟中斷調(diào)度缺陷，靜態(tài)綁定軟中斷可以解決；

（2）sys過高是系統(tǒng)調(diào)用太多引起，使用strace命令，跟蹤查看系統(tǒng)調(diào)用情況，找出使用較多并耗時(shí)較多的系統(tǒng)調(diào)用，比如fopen/read/write/fseek等，改進(jìn)應(yīng)用層設(shè)計(jì)，減少系統(tǒng)調(diào)用。

2.2.2 磁盤調(diào)優(yōu)

尋址時(shí)間比重在60%～70%之間，順序讀寫避免了這部分消耗，因此磁盤的隨機(jī)度性能遠(yuǎn)低于磁盤的順序讀性能?？紤]到流媒體服務(wù)一般是100 Mbyte以上的視頻文件，具備順序讀的可能性，若想提升磁盤吞吐，必須考慮到盡量減少隨機(jī)讀比例。

磁盤調(diào)優(yōu)實(shí)際就是結(jié)合應(yīng)用場景，找出一個(gè)適合的磁盤使用方法，也就是在吞吐、時(shí)延、并發(fā)三個(gè)指標(biāo)之間找一個(gè)均衡點(diǎn)。本案例采用兩個(gè)策略來優(yōu)化磁盤性能：1）調(diào)大每次提交的讀寫塊大小，由原有的64 kbyte，提高到256 kbyte；2）加入預(yù)讀機(jī)制，預(yù)先讀取1 Mbyte數(shù)據(jù)。實(shí)踐結(jié)果表明，這兩種策略促使性能提升了20%左右。

2.2.3 網(wǎng)絡(luò)調(diào)優(yōu)

1）網(wǎng)卡綁定模式

高性能的流媒體服務(wù)器硬件通常采用高性能的服務(wù)器配置，4～12個(gè)千兆網(wǎng)卡，或2～4個(gè)萬兆網(wǎng)卡，為提高網(wǎng)卡利用率，需要采用系統(tǒng)支持的網(wǎng)卡bonding技術(shù)，bonding模式有多種，各種模式的應(yīng)用方向和性能有區(qū)別，一般采用mode 0，mode 2和mode 6，mode 2具有IP親緣性，容易引起網(wǎng)卡負(fù)載失衡，mode 6在大壓力情況下，經(jīng)常出現(xiàn)丟包問題，實(shí)踐證明mode 0最為穩(wěn)定和高效，缺陷需要在交換機(jī)上進(jìn)行相應(yīng)的配置。

2）傳輸協(xié)議層

分布式文件系統(tǒng)DFS和流服務(wù)應(yīng)用程序之間采用的也是基于TCP的網(wǎng)絡(luò)傳輸，TCP使用滑動(dòng)窗口機(jī)制實(shí)現(xiàn)流控，測試時(shí)發(fā)現(xiàn)由于發(fā)送和接收速度不匹配，導(dǎo)致TCP窗口經(jīng)常變?yōu)?，極大地影響了二者之間的傳輸效率。改進(jìn)方法有兩個(gè)：（1）在二者之間進(jìn)行適配，這種方法實(shí)現(xiàn)比較困難，且不利于在DFS層面實(shí)現(xiàn)預(yù)讀；（2）在二者之間添加一個(gè)適配層，使用一個(gè)內(nèi)存buf?fer做緩存，這種方法實(shí)現(xiàn)容易，效率較高。實(shí)際改進(jìn)時(shí)使用了方法2，實(shí)踐證明，緩存適配層的引入有效解決了zero-window的問題。

2.2.4 流服務(wù)層調(diào)優(yōu)

該流媒體服務(wù)系統(tǒng)提供了支持多種終端（PC/pad/ phone/STB）Http Live Steaming[5]服務(wù)，為增加服務(wù)的適配性，減少文件系統(tǒng)開銷，在服務(wù)器端使用的是虛擬切片技術(shù)，即磁盤存儲(chǔ)的是完整的ts文件，由應(yīng)用程序在內(nèi)存中完成切片。

由于HLS服務(wù)采用的是TCP短連接，上下片段間無任何關(guān)聯(lián)，而每次請(qǐng)求ts片段（片段長度默認(rèn)是10 s）服務(wù)器就需要去重新fopen文件，讀取完畢再fclose文件，時(shí)間消耗和CPU消耗都比較大，為了降低這種消耗，本文引入了文件句柄池，設(shè)計(jì)一張hash表在內(nèi)存中緩存打開過的文件句柄，根據(jù)最后訪問時(shí)間和更新時(shí)間等信息定時(shí)更新緩存表數(shù)據(jù)，保證較高的命中率。經(jīng)過這種改進(jìn)，HLS vod性能接近普通vod性能的80%。

2.2.5 其他

在性能測試時(shí)，還遇到了兩種情況：1）CPU虛高，%us消耗和實(shí)際的計(jì)算量不匹配，分析應(yīng)用程序的設(shè)計(jì)，發(fā)現(xiàn)由輪詢間隔太小引發(fā)，CPU空轉(zhuǎn)嚴(yán)重，增加輪詢間隔或更改輪詢機(jī)制，CPU使用降低了30%；2）從性能計(jì)數(shù)器分析，看不出明顯的性能瓶頸，但響應(yīng)時(shí)間很大，并發(fā)數(shù)無法維持，播放出現(xiàn)卡頓，經(jīng)過分析是由并發(fā)調(diào)度中不恰當(dāng)?shù)幕コ庖鸬摹?/p>

3 結(jié)論

通過上述幾個(gè)方向的調(diào)優(yōu)，流媒體服務(wù)器性能得到明顯的提升，使用碼率為800 kbit/s的VBR H.264片源測試，吞吐穩(wěn)定在8 Gbit/s以上，平均響應(yīng)時(shí)間?0.5 s，CPU使用高于90%，磁盤使用率在70%左右，基本達(dá)到了硬件極限。

分析中發(fā)現(xiàn)，接下來可以考慮兩個(gè)方向的優(yōu)化：1）繼續(xù)降低CPU user time的使用，對(duì)于流服務(wù)而言，計(jì)算量比較小，CPU消耗仍然遠(yuǎn)高于理論值，空耗和等待比較多，仍然有較大優(yōu)化空間；2）考慮使用緩存技術(shù)，對(duì)于熱點(diǎn)節(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

【本文獻(xiàn)信息】徐茂.流媒體服務(wù)器性能調(diào)優(yōu)關(guān)鍵點(diǎn)分析[J].電視技術(shù)，2014，38（12）.