流媒體服務器性能調優關鍵點分析

徐茂

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

流媒體服務器性能調優關鍵點分析

徐茂

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

近年來，隨著流媒體業務的普及，以及基于流媒體服務的硬件和軟件平臺的發展，對流媒體服務器的性能調優提出了新的挑戰。首先在概述了流媒體服務器發展背景、面臨挑戰的基礎上，提出性能調優的重要性；然后分析流媒體服務器常見的性能瓶頸表征；最后結合實際案例，給出常用的性能調優方法和技巧。

流媒體；性能瓶頸；性能調優；性能數據監控；IO/CPU/內存密集

隨著互聯網技術的發展，流媒體服務已經廣泛應用到人們生活的各個方面，既為工作提供了便利，也豐富了社會娛樂生活。而流媒體業務的蓬勃擴張，使傳統的流媒體服務系統面臨極大的挑戰。

流媒體通常指音視頻等多媒體技術在互聯網上的傳輸，典型的流媒體服務涵蓋了音視頻等媒體信息的存儲、編解碼、分發、傳輸等多種技術。流媒體服務器的性能指標既包括了并發、吞吐、響應時間等常見參數，也包括音視頻服務質量、直播切換時間等比較有特色的元素。

流媒體服務器系統售價通常以并發和吞吐為衡量指標，考慮到當前的硬件成本逐漸下降，主流流媒體服務器已經開始采用較高配置的硬件，多CPU、高內存、光口的2U/4U設備已經被廣泛引入[1]，基于這些新硬件的性能調優和以往也有了較大的區別，而基于新硬件的性能調優討論比較少，本文將基于新硬件進行討論，致力于補充這個方向的實踐積累。

1 性能瓶頸分析

流媒體服務是一種資源消耗集中的服務，流媒體服務器性能調優通常會碰到多種資源使用瓶頸，性能瓶頸的分析是性能調優的基礎，為性能調優提供方向，并為調優策略的有效性提供數據支持。

流媒體服務器一般采用Linux系統，而Linux提供了豐富的性能監控計數器，基于這些計數器收集到的數據，可以分析和定位服務器性能瓶頸，本章節將重點從CPU、內存、磁盤、網絡等角度深入分析各種瓶頸出現的表征。

1.1 CPU

常用CPU監控命令是top[2]和mpstat[2]，top啟動后可以在交互區輸入“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，該部分數據基于Linux的/proc/stat文件，更新單位是ticks，ticks就是系統時鐘中斷的時間間隔，ticks和內核中的HZ值有關，在內核編譯時可配置，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]。

監控數據時，首先看%id，它表征了空閑CPU時間比例。若%id接近0，表示CPU即將耗盡，在此基礎上可以繼續分析各個類型的CPU比例是否存在異常以及是否還有優化空間，比較重要的有%us，%sy，%wa，%si四個，分別代表用戶、系統、IO、軟中斷的CPU占用情況；若%id超過10%，表示CPU有較多空閑，基本可以判定CPU不構成瓶頸。

對于多核CPU而言，需要觀察每個CPU的情況，任意一個CPU耗盡都會構成性能瓶頸，另外CPU 0很關鍵，由它來負責多個CPU間的調度，若CPU 0比較高，則會影響多核的調度，從而降低整體CPU性能，通常而言，應用程序盡量避免對CPU 0的占用。

1.2 磁盤

磁盤監控使用iostat/iotop[2]等命令，iostat可以看到每個磁盤的使用情況，iotop可以看到IO消耗從高到低的列表。Iostat看到的基本參數包括：rrqm/s，wrqm/s，r/s，w/s，rkB/s，wkB/s，avgrq-sz，avgqu-sz，await，svctm，%util，其中rrqm/s和wrqm/s表示單位時間內的讀寫IO請求，avgrq-sz表征了平均每次IO請求的塊大小，avgqu-sz表征了單位時間內的IO隊列長度，await代表平均每次IO請求的等待時間，svctm表示了平均每次IO請求的服務時間，%util則表示磁盤使用率。

首先觀察%util值，若%util遠低于100%，則表示在統計時間內磁盤負載比較低，不構成性能瓶頸，這時候可以觀察一下其他參數是否有異常，比如svctm，有時候即使是輕負載，若磁盤老化或異常，也會使服務時間過高。

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

機械磁盤的性能由尋址時間、旋轉時間和讀寫時間三部分決定，磁盤內外磁道的尋址時間有明顯差別，而對于數據密集性的多媒體服務器而言，為了充分利用硬件，存儲比例通常達到硬盤容量的70%以上，因此性能測試及調優時需要同時考慮到內外磁道的性能區別。

1.3 內存

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

1.4 網絡

使用sar可以查看網卡使用情況，根據網卡的使用率可以判定網卡硬件瓶頸。對于傳輸層瓶頸，可以使用netstat[2]和tcpdump[2]來看，比如查看netstat Recv-Q和Send-Q，若發送隊列和接收隊列比較大，且持續增加，代表了應用層網絡發送或接收出現了阻塞，而使用tcp?dump可以觀察到TCP傳輸層的問題，若出現了Ze?ro-Window，表示發送或接收緩存區已滿，導致TCP流控啟動。

1.5 文件句柄

使用lsof[2]和ulimit[2]命令，查看每個進程開啟的文件句柄和系統的文件打開限制數，若進程開啟文件句柄大于配置的閾值，則進程運行就會出錯。

2 性能調優案例分析

2.1 系統配置

硬件采用超微4U Server，配置如下：intel Xeon 2.00 GHz×24，Disk：7 500轉；軟件流服務模塊采用Py?thon Twister框架，數據庫使用mysql，文件系統使用類GFS[4]的分布是文件系統DFS，操作系統使用CentOS 6.4版本，ext4虛擬文件系統。

2.2 調優策略

2.2.1 CPU調優

性能測試時出現過以下幾種CPU的問題，并給出了對應的解決方法：

1）多核CPU使用不均衡

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

（2）靜態綁定不同進程或進程中的不同線程到不同的CPU上。

2）部分CPU si/sys過高

（1）si過高為多個網卡的軟中斷分配不均衡，為系統軟中斷調度缺陷，靜態綁定軟中斷可以解決；

（2）sys過高是系統調用太多引起，使用strace命令，跟蹤查看系統調用情況，找出使用較多并耗時較多的系統調用，比如fopen/read/write/fseek等，改進應用層設計，減少系統調用。

2.2.2 磁盤調優

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

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

2.2.3 網絡調優

1）網卡綁定模式

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

2）傳輸協議層

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

2.2.4 流服務層調優

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

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

2.2.5 其他

在性能測試時，還遇到了兩種情況：1）CPU虛高，%us消耗和實際的計算量不匹配，分析應用程序的設計，發現由輪詢間隔太小引發，CPU空轉嚴重，增加輪詢間隔或更改輪詢機制，CPU使用降低了30%；2）從性能計數器分析，看不出明顯的性能瓶頸，但響應時間很大，并發數無法維持，播放出現卡頓，經過分析是由并發調度中不恰當的互斥引起的。

3 結論

通過上述幾個方向的調優，流媒體服務器性能得到明顯的提升，使用碼率為800 kbit/s的VBR H.264片源測試，吞吐穩定在8 Gbit/s以上，平均響應時間?0.5 s，CPU使用高于90%，磁盤使用率在70%左右，基本達到了硬件極限。

分析中發現，接下來可以考慮兩個方向的優化：1）繼續降低CPU user time的使用，對于流服務而言，計算量比較小，CPU消耗仍然遠高于理論值，空耗和等待比較多，仍然有較大優化空間；2）考慮使用緩存技術，對于熱點節目降低磁盤壓力，提升內存利用率。

[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

【本文獻信息】徐茂.流媒體服務器性能調優關鍵點分析[J].電視技術，2014，38（12）.