sFlow網(wǎng)絡(luò)流量采集器設(shè)計(jì)與性能控制研究

吳 爍，林南暉

（1.華南師范大學(xué)計(jì)算機(jī)學(xué)院，廣東 廣州 510631，汕頭大學(xué)網(wǎng)絡(luò)與信息中心，廣東 汕頭 515063；2.華南師范大學(xué)網(wǎng)絡(luò)中心，廣東 廣州 510631）

sFlow網(wǎng)絡(luò)流量采集器設(shè)計(jì)與性能控制研究

吳 爍1，林南暉2

（1.華南師范大學(xué)計(jì)算機(jī)學(xué)院，廣東 廣州 510631，汕頭大學(xué)網(wǎng)絡(luò)與信息中心，廣東 汕頭 515063；2.華南師范大學(xué)網(wǎng)絡(luò)中心，廣東 廣州 510631）

基于給出的sFlow采集器設(shè)計(jì)框架，研究了采集器的線程管理和性能監(jiān)測(cè)技術(shù)，設(shè)計(jì)了能適應(yīng)網(wǎng)絡(luò)流量變化，并長(zhǎng)期穩(wěn)定工作的采集器.

sFlow采集器；線程管理；性能監(jiān)測(cè)

0 引 言

流量監(jiān)測(cè)是網(wǎng)絡(luò)管理中一項(xiàng)重要任務(wù)，監(jiān)測(cè)數(shù)據(jù)為網(wǎng)絡(luò)的優(yōu)化、故障的發(fā)現(xiàn)、異常事件的預(yù)警提供了必不可少的依據(jù).當(dāng)今網(wǎng)絡(luò)的特點(diǎn)是規(guī)模大，結(jié)構(gòu)復(fù)雜，主干速度高（10 Gbps），應(yīng)用種類(lèi)多.傳統(tǒng)的網(wǎng)管與流量測(cè)量技術(shù)（SNMP、RMON、Sniffer等）已無(wú)法滿(mǎn)足現(xiàn)代網(wǎng)絡(luò)流量監(jiān)測(cè)的需要[1].在這種背景下，sFlow技術(shù)得到了越來(lái)越多的重視.

sFlow是InMon公司提出的網(wǎng)絡(luò)流量監(jiān)測(cè)技術(shù)，版本v4于2001年成為互聯(lián)網(wǎng)網(wǎng)絡(luò)流量監(jiān)測(cè)標(biāo)準(zhǔn)（RFC3176）[2]，最新版本是v5[3].盡管當(dāng)前已有不少支持sFlow流量采集及監(jiān)測(cè)的軟件[4]，但商業(yè)軟件功能、性能的限制，特別是原始流量數(shù)據(jù)訪問(wèn)權(quán)限的不足，都制約著流量分析研究的進(jìn)行.關(guān)于sFlow的相關(guān)研究和文獻(xiàn)報(bào)道多專(zhuān)注于構(gòu)建基于sFlow網(wǎng)絡(luò)流量監(jiān)測(cè)系統(tǒng)的整體方案或如何利用sFlow來(lái)達(dá)到特定監(jiān)測(cè)目的，很少詳細(xì)討論sFlow采集器的設(shè)計(jì).而對(duì)于sFlow報(bào)文信息內(nèi)容，多數(shù)文獻(xiàn)只簡(jiǎn)單描述其中部分字段，很少對(duì)信息內(nèi)容作深入探討.事實(shí)上，sFlow采集器是sFlow監(jiān)測(cè)系統(tǒng)最基礎(chǔ)的部分，沒(méi)有采集器，就無(wú)法進(jìn)行數(shù)據(jù)的采集、存儲(chǔ)以及后繼的分析.本文重點(diǎn)討論采集器的設(shè)計(jì)及實(shí)現(xiàn)細(xì)節(jié)，詳細(xì)解釋報(bào)文信息字段含義，以及在流量采集中的作用，隨后給出一個(gè)sFlow采集器總的設(shè)計(jì)框架.基于這個(gè)框架，再通過(guò)線程池管理、性能監(jiān)測(cè)、緩沖區(qū)調(diào)節(jié)等，使得采集器能適應(yīng)網(wǎng)絡(luò)流量的變化，從而長(zhǎng)期穩(wěn)定地工作.

1 sFlow技術(shù)

1.1 技術(shù)框架

基于sFlow技術(shù)的網(wǎng)絡(luò)流量監(jiān)測(cè)系統(tǒng)框架[5]如圖1所示，內(nèi)嵌在設(shè)備（交換機(jī)/路由器）里的專(zhuān)用集成電路ASIC對(duì)經(jīng)過(guò)設(shè)備的數(shù)據(jù)包進(jìn)行采樣，提供數(shù)據(jù)包自身信息；轉(zhuǎn)發(fā)/路由表提供與數(shù)據(jù)包相關(guān)的路徑信息；端口計(jì)數(shù)器提供端口統(tǒng)計(jì)信息.Agent將來(lái)自三種信息源的信息組裝成sFlow報(bào)文，發(fā)送到sFlow采集器.采集器接收sFlow報(bào)文后，按sFlow數(shù)據(jù)格式規(guī)范解析報(bào)文，得到有用的流量信息，供后續(xù)流量分析使用.可見(jiàn)，sFlow報(bào)文包含了sFlow系統(tǒng)監(jiān)測(cè)的所有數(shù)據(jù)，正確理解sFlow報(bào)文結(jié)構(gòu)以及各字段含義，對(duì)于采集器的設(shè)計(jì)是相當(dāng)重要的.

圖1 監(jiān)測(cè)系統(tǒng)框架

1.2 相關(guān)概念

1.2.1 采樣機(jī)制、樣本和記錄

sFlow是基于采樣的技術(shù)，Packet flow sampling按采樣率N對(duì)通過(guò)設(shè)備端口的網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行數(shù)據(jù)包采樣；Counter sampling按采樣間隔定時(shí)從端口計(jì)數(shù)器（interface counter）獲取各端口的統(tǒng)計(jì)信息.兩種采樣機(jī)制產(chǎn)生相應(yīng)的樣本：流樣本（flow sample）和計(jì)數(shù)器樣本（counter sample）.流樣本描述網(wǎng)絡(luò)數(shù)據(jù)包特性，不僅包含原始數(shù)據(jù)包的包頭信息，還可以包含與原始包傳送過(guò)程相關(guān)的信息.計(jì)數(shù)器樣本描述端口流量特性，同樣包含了多種豐富的計(jì)數(shù)信息.樣本中的信息是用記錄（record）的格式來(lái)組織各種信息的，相應(yīng)的有流記錄（flow record）和計(jì)數(shù)器記錄（counter record）.

1.2.2 sFlow報(bào)文

單個(gè)樣本的長(zhǎng)度比較小，只有IP數(shù)據(jù)包可支持的最大長(zhǎng)度的十幾分之一，但產(chǎn)生頻率高，數(shù)量多，用一個(gè)IP數(shù)據(jù)包發(fā)送一個(gè)樣本浪費(fèi)資源，所以將幾個(gè)樣本組裝起來(lái)發(fā)送，節(jié)省資源且不影響實(shí)時(shí)性.sFlow報(bào)文是網(wǎng)絡(luò)設(shè)備向sFlow采集器傳送樣本所使用的網(wǎng)絡(luò)報(bào)文，是一個(gè)UDP報(bào)文，由Agent采用XDR標(biāo)準(zhǔn)（RFC1832）封裝，其中包含了Agent的信息和若干個(gè)流樣本和計(jì)數(shù)器樣本.值得注意的是，每個(gè)sFlow報(bào)文中承載的是多個(gè)采樣樣本，而不是單一一個(gè)采樣樣本.如果誤把sFlow報(bào)文中的相關(guān)數(shù)據(jù)當(dāng)成一個(gè)采樣數(shù)據(jù)來(lái)統(tǒng)計(jì)，必然導(dǎo)致錯(cuò)誤結(jié)果.

1.3 報(bào)文結(jié)構(gòu)及信息字段

sFlow報(bào)文的結(jié)構(gòu)見(jiàn)圖2，sFlow報(bào)文由報(bào)文頭部、流樣本和計(jì)數(shù)器樣本的集合構(gòu)成.報(bào)文頭部主要是與Agent有關(guān)的信息，具體的字段見(jiàn)表1.Agent_address是產(chǎn)生報(bào)文的Agent地址.Sub_agent_id是Agent中各Sub Agent的標(biāo)識(shí)號(hào)，在分布式環(huán)境下，是由各個(gè)Sub Agent處理各自管轄的流量分支的.Datagram_SN可用于檢測(cè)sFlow報(bào)文是否丟失.由于各個(gè)Sub Agent的Uptime可能不同步，因此在設(shè)計(jì)中使用的是采集器接收到報(bào)文的時(shí)間.

圖2 報(bào)文結(jié)構(gòu)

表1 報(bào)文頭部結(jié)構(gòu)

流樣本和計(jì)數(shù)器樣本都是由樣本頭部以及若干個(gè)記錄構(gòu)成的.流樣本頭部主要是與數(shù)據(jù)源（交換機(jī)端口）、采樣參數(shù)有關(guān)的信息，具體字段見(jiàn)表2；計(jì)數(shù)器樣本頭部只有表2中的部分字段，意義相同，不再贅述.Data_format后12位用來(lái)區(qū)分樣本的類(lèi)別，根據(jù)類(lèi)別的不同，采集器進(jìn)入不同的程序分支繼續(xù)解析后面的字段.Sample_length可用于解析過(guò)程中的越界判別.Sample_SN標(biāo)識(shí)來(lái)自同一數(shù)據(jù)源（交換機(jī)端口等）的不同樣本，可用于檢測(cè)樣本是否丟失.Datasource_type_index（或Datasource_type，Datasource_index）描述數(shù)據(jù)來(lái)源，在后續(xù)的流量統(tǒng)計(jì)、分析過(guò)程都有重要作用.Drops可用于Agent的超荷告警.

表2 流樣本頭部結(jié)構(gòu)

續(xù)表2

sFlow標(biāo)準(zhǔn)v5[3]定義了16種流記錄和6種計(jì)數(shù)器記錄.除了原始包頭記錄（raw packet header record）的字段稍微復(fù)雜，其它記錄字段的名稱(chēng)都具較好的自描述性，不在此一一列舉.表3以原始包頭記錄為例說(shuō)明記錄的格式，其它記錄的詳細(xì)信息參見(jiàn)文獻(xiàn)［3］.Header_protocol標(biāo)識(shí)了Header字段對(duì)應(yīng)的包頭類(lèi)型，例如，Header_protocol=1說(shuō)明是以太網(wǎng)幀頭部，Header protocol=11說(shuō)明是IP包頭部.得到包頭類(lèi)型，就可按規(guī)定格式對(duì)包頭進(jìn)一步解析，進(jìn)而得到上層協(xié)議的相關(guān)信息，如端口號(hào)等.Header_size可用于包頭解析過(guò)程中的越界判別.正確理解了sFlow報(bào)文結(jié)構(gòu)及字段含義，解析sFlow報(bào)文就不存在大的問(wèn)題了.解析過(guò)程要注意的一點(diǎn)是，以字段為單位讀取多個(gè)字節(jié)后，要先對(duì)這些字節(jié)作網(wǎng)絡(luò)字符順序-主機(jī)字符順序的轉(zhuǎn)換，然后才轉(zhuǎn)換成該字段所對(duì)應(yīng)的數(shù)據(jù)格式.

表3 原始包頭記錄結(jié)構(gòu)

2 采集器設(shè)計(jì)

2.1 框架

采集器由管理控制線程、接收線程、解析線程、性能監(jiān)測(cè)線程構(gòu)成，見(jiàn)圖3.

管理控制線程根據(jù)配置信息初始化變量創(chuàng)建并啟動(dòng)其它線程.初始化工作完成后，管理控制線程負(fù)責(zé)處理性能監(jiān)測(cè)線程的結(jié)果或響應(yīng)用戶(hù)命令.用戶(hù)命令主要是修改各種配置信息.

圖3 采集器框架

接收線程循環(huán)讀取指定Socket端口（UDP6343）的數(shù)據(jù)包.在.Net中，UDPClient.receive采用阻止同步的工作模式，當(dāng)沒(méi)有數(shù)據(jù)包到達(dá)時(shí)，接收線程被阻塞，只有接收到數(shù)據(jù)包時(shí)，線程才會(huì)執(zhí)行后面的代碼.接收線程接收到UDP包后，首先判別包的來(lái)源地址是不是許可地址，丟棄非許可地址來(lái)源的包，提取許可包中的sFlow報(bào)文（去掉UDP頭部），然后連同報(bào)文接收的時(shí)間一起寫(xiě)入接收緩沖隊(duì)列ReceiveBuff；接著進(jìn)行緩沖判別，如果接收緩沖隊(duì)列已滿(mǎn)，則將緩沖隊(duì)列交解析線程解析，并創(chuàng)建新的緩沖隊(duì)列；最后，繼續(xù)下一接收操作.

對(duì)于接收緩沖隊(duì)列中的每個(gè)sFlow報(bào)文，解析線程通過(guò)構(gòu)造SQL語(yǔ)句片段的方式保存所需的字段信息，最后形成一個(gè)完整的SQL語(yǔ)句.為了不頻繁地連接數(shù)據(jù)庫(kù)，SQL語(yǔ)句被暫時(shí)存放在SQL語(yǔ)句隊(duì)列中，直到解析線程處理完接收緩沖隊(duì)列的所有報(bào)文，才執(zhí)行寫(xiě)入數(shù)據(jù)庫(kù)的操作.同一時(shí)間內(nèi)，系統(tǒng)有多個(gè)解析線程，并通過(guò)線程池來(lái)管理這些線程.

性能監(jiān)測(cè)線程定時(shí)向管理控制線程匯報(bào)系統(tǒng)工作狀態(tài)，發(fā)送錯(cuò)誤或超荷告警.

2.2 線程管理及線程池

報(bào)文采集是一個(gè)高速、海量的數(shù)據(jù)處理過(guò)程，采集器的設(shè)計(jì)不可避免地要涉及到多線程管理的問(wèn)題，這里主要是指多個(gè)解析線程的管理.

由于網(wǎng)絡(luò)流量變動(dòng)較大，固定數(shù)量線程輪詢(xún)方式不能很好地工作，既不能高效利用系統(tǒng)資源，也不能很好地適應(yīng)流量變化.當(dāng)網(wǎng)絡(luò)流量較低時(shí)，可能多個(gè)線程一直輪空；而當(dāng)網(wǎng)絡(luò)流量很高時(shí)，又會(huì)由于線程數(shù)不足、處理不及而導(dǎo)致丟包.如果增加線程數(shù)量，又由于訪問(wèn)公共緩沖區(qū)的需要而進(jìn)行互斥控制，系統(tǒng)性能也將隨著下降.采集器以被動(dòng)接收模式工作，只能盡力而為地處理接收到的數(shù)據(jù)包，在這種情況下，固定長(zhǎng)度的公共緩沖區(qū)無(wú)法滿(mǎn)足需求.但如果使用長(zhǎng)度可變的公共緩沖區(qū)，在基于垃圾回收機(jī)制的開(kāi)發(fā)工具（如JAVA、.Net）中，可能會(huì)由于內(nèi)存泄漏而使系統(tǒng)最終陷入癱瘓狀態(tài).一個(gè)簡(jiǎn)單的模型可避免使用公共緩沖區(qū)：每接收到一個(gè)報(bào)文就創(chuàng)建一個(gè)新線程進(jìn)行處理，處理完成后再銷(xiāo)毀線程釋放資源.但是，由于線程的創(chuàng)建、銷(xiāo)毀都要占用一定的CPU時(shí)間，在頻繁的任務(wù)請(qǐng)求過(guò)程中也會(huì)占用很大部分CPU資源，因此不適宜用于采集器的開(kāi)發(fā).

線程池技術(shù)可克服上述模型頻繁創(chuàng)建、銷(xiāo)毀線程的缺點(diǎn).線程池通常由1個(gè)監(jiān)視線程、n個(gè)任務(wù)線程以及任務(wù)等待隊(duì)列組成，n是線程池的尺寸，大小可以動(dòng)態(tài)調(diào)整.監(jiān)視線程負(fù)責(zé)指派和回收任務(wù)線程，監(jiān)視線程池繁忙狀態(tài)，維護(hù)線程池的大小.任務(wù)線程是負(fù)責(zé)完成具體任務(wù)的，可以為每個(gè)任務(wù)創(chuàng)建私有的緩沖區(qū)，任務(wù)完成后釋放緩沖區(qū).空閑的任務(wù)線程組成一個(gè)空閑線程隊(duì)列，阻塞在后臺(tái)，一直存在系統(tǒng)中，以節(jié)省創(chuàng)建和銷(xiāo)毀線程的開(kāi)銷(xiāo)，從而顯著提高系統(tǒng)的性能.

在本文設(shè)計(jì)的采集器中，線程池中的任務(wù)線程就是解析線程.接收線程為每個(gè)任務(wù)創(chuàng)建一個(gè)私有的緩沖隊(duì)列，當(dāng)這個(gè)隊(duì)列已滿(mǎn)時(shí)，接收線程調(diào)用ThreadPool.QueueUser-WorkItem向線程池提交處理請(qǐng)求.ThreadPool.QueueUserWorkItem傳遞了兩個(gè)參數(shù)，一個(gè)是私有緩沖隊(duì)列，一個(gè)則指示執(zhí)行任務(wù)所用的方法，這個(gè)方法的流程見(jiàn)圖3解析線程部分.當(dāng)有空閑線程時(shí)，線程池調(diào)用其中一個(gè)作為解析線程，待解析線程完成任務(wù)并釋放資源后，返回空閑線程隊(duì)列中；當(dāng)沒(méi)有空閑線程時(shí)，線程池將任務(wù)請(qǐng)求掛在任務(wù)等待隊(duì)列中.

線程池有最大線程數(shù)（MaxThreads）和最小空閑線程數(shù)（MinIdleThreads）兩個(gè)重要屬性.線程池中的線程（任務(wù)線程和空閑線程）總數(shù)是由MaxThreads決定的，但由于每個(gè)線程要分配堆棧資源，為了節(jié)省資源，線程池只保留數(shù)量等于MinIdleThreads的空閑線程.當(dāng)空閑線程數(shù)小于MinIdleThreads時(shí)，創(chuàng)建新的線程，創(chuàng)建前線程池有半秒的內(nèi)置遲延，以防止線程剛創(chuàng)建又被銷(xiāo)毀.但因?yàn)檫@個(gè)內(nèi)置延遲，有時(shí)候任務(wù)到達(dá)時(shí)仍需要等待一段時(shí)間才得以執(zhí)行，盡管正在運(yùn)行的線程并不多.因此，當(dāng)短期內(nèi)有許多任務(wù)要處理時(shí)，可以通過(guò)SetMinThreads來(lái)適當(dāng)增加空閑線程數(shù)[6]，會(huì)顯著增加系統(tǒng)的吞吐量.

2.3 性能監(jiān)測(cè)、調(diào)節(jié)及告警

sFlow報(bào)文是通過(guò)UDP傳輸?shù)?，由于此方式具有不可靠性，因此采集器無(wú)法保證不丟包，而sFlow技術(shù)基于采樣的流量統(tǒng)計(jì)方式具有一定的誤差率，少量的丟包并不影響統(tǒng)計(jì)結(jié)果.但采集器仍應(yīng)盡量降低丟包率，而且能報(bào)告丟包情況.Datagram_SN和Sample_SN可用于監(jiān)測(cè)丟包情況.性能監(jiān)測(cè)線程定期查詢(xún)前一分鐘收到的報(bào)文或樣本個(gè)數(shù)sum以及SN的最大與最小值，當(dāng)maxSN－minSN＋1＞sum時(shí)，向管理控制線程報(bào)告報(bào)文丟失事件.此外，性能監(jiān)測(cè)線程每隔半秒鐘查詢(xún)當(dāng)前系統(tǒng)性能狀態(tài)，如CPU利用率、內(nèi)存占用情況及線程數(shù)，將系統(tǒng)每分鐘的最大性能指標(biāo)記入性能日志中.

采集器可以針對(duì)隨網(wǎng)絡(luò)流量而變化的報(bào)文的到達(dá)速率作相應(yīng)的調(diào)整，同時(shí)結(jié)合接收緩沖隊(duì)列長(zhǎng)度及線程池MinIdleThreads的管理，以提高處理效率.

較長(zhǎng)的接收緩沖能應(yīng)付流量高峰期的突發(fā)流量，同時(shí)使CPU時(shí)間片得到更好的利用.但在流量比較低時(shí)，過(guò)長(zhǎng)的接收緩沖可能影響實(shí)時(shí)性能，而過(guò)短則會(huì)使同時(shí)運(yùn)行的線程過(guò)多，互斥訪問(wèn)頻繁發(fā)生，影響運(yùn)行效率.使用dotTrace工具（在www.jetbrains.com下載）分別測(cè)量每個(gè)線程被調(diào)用的次數(shù)及運(yùn)行時(shí)間，計(jì)算多種緩沖隊(duì)列長(zhǎng)度設(shè)置下的運(yùn)行效率，以找到合理的緩沖隊(duì)列長(zhǎng)度.測(cè)試雙CPU機(jī)器的結(jié)果是：在幾個(gè)流量不同的時(shí)間段內(nèi)，當(dāng)任務(wù)線程數(shù)為4～6個(gè)時(shí)，每個(gè)包的平均解析時(shí)間是比較短的.由此，可以根據(jù)任務(wù)線程的個(gè)數(shù)來(lái)調(diào)節(jié)緩沖隊(duì)列長(zhǎng)度，進(jìn)而使任務(wù)線程個(gè)數(shù)處于比較合理的區(qū)

其中N是新的緩沖區(qū)大小，C是調(diào)節(jié)前緩沖區(qū)的大小，T是前一分鐘最大任務(wù)線程數(shù).判別區(qū)間是[2，8]而不是[4，6]，是為了防止緩沖長(zhǎng)度在某個(gè)區(qū)間里來(lái)回震蕩調(diào)節(jié).

足夠的空閑線程數(shù)可保證解析任務(wù)立刻執(zhí)行，通過(guò)以下方式調(diào)節(jié)線程池的MinIdleThreads：每隔一分鐘，判斷最大與最小任務(wù)線程數(shù)之差，如果大于MinIdleThreads，則MinIdleThreads＋1；如果小于MinIdleThreads／2，則MinIdleThreads－1.調(diào)節(jié)過(guò)程中還要保證MinIdleThreads不小于CPU個(gè)數(shù).

受硬件條件的限制，采集器的處理能力有限，因此必須有出錯(cuò)告警和超荷告警機(jī)制.性能監(jiān)測(cè)線程要報(bào)告運(yùn)行中由于鏈路或設(shè)備故障造成的各種錯(cuò)誤信息，包括丟包數(shù)，非許可的Agent地址，解析錯(cuò)誤等.而超荷告警則包括高Drop數(shù)，高丟包數(shù)等.告警閾值通過(guò)配置文件定義，也可以在運(yùn)行期間由用戶(hù)重新設(shè)定.間，見(jiàn)公式（1），

3 實(shí)驗(yàn)環(huán)境及結(jié)果

3.1 實(shí)驗(yàn)環(huán)境

將采集器運(yùn)行在一臺(tái)PC（雙核Petium E2160@1.8 GHz，1 G內(nèi)存）上，采用SQLServer 2005作為后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)，安裝在服務(wù)器（4核Xeon3GHz，2G內(nèi)存）上.sFlow報(bào)文來(lái)自?xún)膳_(tái)核心交換機(jī)（Foundry MG8，F(xiàn)oundry RX4，采樣率分別配置為1/1 000和1/2 048）的4個(gè)10 Gbps和12個(gè)1 Gbps端口，監(jiān)測(cè)校園網(wǎng)主干端口的流出流量.

3.2 結(jié)果

最初，采用動(dòng)態(tài)創(chuàng)建線程方式時(shí)，采集器經(jīng)常出現(xiàn)丟包現(xiàn)象.緩沖區(qū)長(zhǎng)度為1時(shí)，每分鐘都會(huì)出現(xiàn)丟包，增大緩沖區(qū)長(zhǎng)度可使發(fā)生丟包的時(shí)間間隔變大，但創(chuàng)建解析線程要耗費(fèi)比較多的CPU時(shí)間，接收線程不能及時(shí)創(chuàng)建新的接收緩沖區(qū)，因此仍無(wú)法杜絕丟包現(xiàn)象.而采用常駐線程輪詢(xún)方式時(shí)，工作不穩(wěn)定，出現(xiàn)不規(guī)則的丟包現(xiàn)象，而且會(huì)不定期死機(jī).

改用線程池技術(shù)并引入調(diào)節(jié)機(jī)制后，在2009-07-12至2009-09-20期間持續(xù)運(yùn)行采集器.根據(jù)性能監(jiān)測(cè)日志記錄，CPU占用率低于5%，內(nèi)存使用維持在12～16 M之間.在此期間，每天采集樣本個(gè)數(shù)在15000000到19000000間，絕大部分時(shí)間的丟包率為0，偶爾（幾天中的某一秒鐘內(nèi)）有極少量（5～20個(gè)）樣本丟失，丟包率小于1/750 000.通過(guò)對(duì)Datagram_SN和Sample_SN丟失時(shí)間的記錄進(jìn)行對(duì)比，發(fā)現(xiàn)丟失并不是在采集器處理過(guò)程中發(fā)生的，而是在sFlow報(bào)文向采集器傳輸過(guò)程中丟失的（即sFlow報(bào)文并未到達(dá)采集器已丟失，這是由于UDP傳輸?shù)牟豢煽啃栽斐傻模?

圖 4、 5、 6 分別是實(shí)驗(yàn)?zāi)┢冢?009-09-17T00：00：00 至 2009-09-20T00：00：00）每小時(shí)采集的樣本數(shù)量、接收緩沖區(qū)平均長(zhǎng)度以及平均解析線程數(shù)量.如圖4所示，流量最高和最低時(shí)段所采集的樣本數(shù)量相差是比較懸殊的.對(duì)比圖4與圖5可見(jiàn)，緩沖區(qū)長(zhǎng)度隨著流量的變化而變化.如圖6所示，此期間解析線程數(shù)維持比較穩(wěn)定的數(shù)量.在高流量的時(shí)段，平均線程個(gè)數(shù)在4到6之間，在2.3節(jié)中提到，任務(wù)線程數(shù)在這個(gè)范圍內(nèi)，采集器的效率是比較高的.可見(jiàn)，在持續(xù)運(yùn)行了2個(gè)多月后，采集器仍保持良好的調(diào)節(jié)能力.實(shí)驗(yàn)結(jié)果表明，采用線程池技術(shù)方式的采集器能長(zhǎng)期持續(xù)穩(wěn)定地運(yùn)行.

圖4 每小時(shí)樣本數(shù)量

圖5 每小時(shí)平均緩沖區(qū)長(zhǎng)度

圖6 每小時(shí)平均解析線程數(shù)量時(shí)間

綜上可見(jiàn)，本文提出的sFlow采集器框架及技術(shù)設(shè)計(jì)能較好地適應(yīng)校園網(wǎng)絡(luò)流量變化，長(zhǎng)期穩(wěn)定工作.

[1] 劉國(guó)萍，左維.基于sFlow技術(shù)的通信網(wǎng)絡(luò)流量異常監(jiān)測(cè)方案[J].計(jì)算機(jī)工程，2007，33（6）：245-247.

[2]Phaal P， Panchen S， Mckee N.InMon Corporation’s sFlow： a method for monitoring traffic in switched and routed networks[EB/OL].http://www.ietf.org/rfc/rfc3176.txt，2001-09-15.

[3] Phaal P.sFlow version 5[EB/OL].http://www.sflow.org/sflow_version_5.txt，2008-04-27.

[4] sFlow.org.sFlow collectors[EB/OL].http://www.sflow.org/products/collectors.php，2009-10-15.

[5] InMon Corporation.sFlow in operation[EB/OL].http://www.sflow.org/process/process_full.htm，2009-03-09.

[6] MicroSoft Corporation.托管線程池[EB/OL].http：//msdn.microsoft.com/zh-cn/library/0ka9477y.aspx，2009-10-15.

Abstract：Based on a given designing framework for sFlow collector， threads management and performance monitoring techniques are studied and a collector with adaptive and longterm stability of traffic is designed and implemented.

Key words：sFlow collector； datagram format； thread pool

Research on Design and Control of sFlow Collector

WU Shuo1，LIN Nan-hui2

（1.School of Computer， South China Normal University,Guangzhou 510631， Guangdong， China； Network and Information Center， Shantou University， Shantou 515063， Guangdong， China； 2.Network Center， South China Normal University， Guangzhou 510631， Guangdong， China）

TP 393.07

A

1001-4217（2010）02-0064-09

2009-10-15

吳爍（1978-），女，廣東潮州人，碩士研究生.研究方向：計(jì)算機(jī)網(wǎng)絡(luò).E-mail：swu@stu.edu.cn

教育科研基礎(chǔ)設(shè)施IPv6技術(shù)升級(jí)和應(yīng)用示范項(xiàng)目（CNGI2008-084）