張慧嬙,程 華
(江南計算技術研究所,江蘇 無錫 214083)
性能監測工具可以實時監測系統的運行狀態及資源使用情況[1-2],包括CPU、內存、磁盤、網絡等。近年來,隨著“綠色計算”[3]概念的提出,低功耗成為軟件設計、工具選擇時的重要考量[4]。頻繁監測使用高頻的程序(如操作系統)時,監測工具給系統帶來的性能、功耗負載不容忽視,必須引起重視。因此,除了實現的功能,了解性能監測工具運行中的性能、功耗情況十分必要,是選擇合適的監測工具時必須考慮的重要因素。
Linux系統中提供了豐富的性能監測工具[2],既有針對單個單元的監測工具,如fdisk查看硬盤分區信息,free查看內存使用情況,iostat實時記錄整個CPU與接口設備的I/O狀態;也有涵蓋多個單元的全面系統監測工具,如top動態監測進程的工作狀態及運行情況,sar從多方面對系統活動進行報告,常用于全日監測系統狀態,collectl則可以監測幾乎全部的系統單元。不同監測工具采集不同種類和數量的硬件性能事件,占用的資源和消耗的能源也不同。使用時應根據需求選擇合適的工具,才能有效實現系統監測與性能調試。
理想的性能監測工具應具備兩方面的特性:(1)監測的全面性。應覆蓋CPU、磁盤、內存、網絡等多個監測項目,實現系統單元的細粒度監測;(2)輕量級、低負載。占用系統資源盡量少,對系統運行的影響應盡可能小。當前,相關文獻中對監測工具的分析主要集中在功能實現方面[5-7],對資源消耗情況的分析較少或不夠全面[8-10]。
針對性能監測工具缺乏全面的資源、能耗分析這一問題,文中設計了定量測評實驗。選取free、iostat、ifstat、sar和collectl等主流Linux性能監測工具,通過實驗測量得到了典型監測工具的性能和功耗數據。
目前流行的大多數性能監測工具都是通過讀取/proc文件系統下特定的編碼文件[11],經過一定的編碼解釋后輸出成可讀的形式,來實現特定系統單元的實時性能監測。/proc文件系統是Linux內核的一個虛擬文件系統[12],不僅提供了Linux內核的當前狀態,還包含了系統硬件以及詳細的進程信息,例如內存管理、進程相關、文件系統、設備驅動程序、系統總線、電源管理、終端、系統控制參數、網絡等,幾乎涵蓋了內核的所有部分。/proc系統以文件的形式提供了內核與進程之間的通信接口,用戶或應用程序可以通過/proc系統動態訪問內核內部數據結構、讀取系統的相關信息,還可以通過改變/proc下相應的文件來改變內核設置。另一方面,計算機系統中提供了豐富的硬件性能計數器[13-14]和傳感器[15-17],可直接采集系統的硬件信息和活動數據,并通過相應的驅動將檢測到的硬件信息提供給操作系統,某些性能監測數據便是通過讀取這些特定的配置文件獲得。
最早的性能監測工具產生于Unix系統中,便于系統管理員進行系統維護和性能調節。隨著Linux系統的流行,這些工具大多經過一定程度的改寫以適用于各個Linux系統發行版。隨著Linux內核的不斷升級、計算機硬件設備的不斷完善,性能監測工具更加豐富,覆蓋的監測項目更加全面,監測的數據也更加豐富和準確。根據監測單元的數目及監測數據的類型,現有的性能監測工具可大致分為以下三類:
(1)子系統性能監測工具:監測一個或少數幾個子系統,提供特定子系統的全面性能監測數據。典型的如free和iostat,其中free屬于procps包,1992年由Brian Edmonds發布,用于在終端顯示內存和交換空間的使用情況,包括已用內存、buffers、cache等,簡易實用,幾乎所有系統管理員日常都會用到;iostat是sysstat系統監測軟件包的一部分,由Sebastien Godard于1998年使用C語言發布,匯總了單個磁盤的使用信息,可報告CPU及磁盤使用情況,包括塊設備的讀和寫,跟蹤存儲設備的性能,用于調整系統配置取得磁盤之間更好的I/O負載平衡。
(2)全系統細粒度性能監測工具:監測多個子系統,能提供多個子系統全面細粒度的性能監測數據。全系統細粒度監測工具功能強大,應用最為廣泛的是sar和collectl。其中,sar工具也屬于Sysstat包,最早寫于1999年,隨后不斷完善,成為Linux系統監測的全能工具,可以統計實時數據或歷史數據,收集、報告和保存系統的不同活動指標,包括CPU使用情況、文件讀寫情況、磁盤I/O狀況等詳細信息,幫助用戶全方位監測系統,找出性能瓶頸;collectl作為后起之秀,2003年由Mark Seger采用perl語言寫成,經過多年發展,如今已成為一個出色的輕量級全系統監測工具,可以覆蓋眾多系統單元、報告豐富資源信息,在功能方面既和sar有重合點,又展現出了很多不同于sar的細節和特性,例如增加了對計算機集群的監測支持,可以單獨扮演ps、top等其他實用監測工具的角色。
(3)全系統概要監測工具:可用于監測多個子系統,描述各系統總體運行情況的概要統計數據。前面介紹的top便是典型的全系統概要監測工具,top提供了一系列系統范圍的概要統計信息,包括CPU利用率、平均負載、內存及交換空間使用情況等,還可以監測運行最多的進程/任務狀態,根據CPU用量等對進程進行排序,每隔一定間隔刷新屏幕。使用top命令,用戶可快速掌握當前主要系統部件的大致性能情況,并對資源占用較高的進程實行專門監測。在此基礎上,許多學者對top工具進行了不同的改進。由于top對/proc系統拍快照,無法監測在快照之前結束的壽命較短的程序[1],針對此情況,Gerlof Langeveld等于2000年發布了atop工具,使用進程核算技術,對短壽命的程序進行了捕捉顯示;此外,Hisham Muhammad提供了一個更為友好的top工具——htop,可以以更加多彩的方式顯示更加豐富的統計信息,并對重要數據進行高亮顯示。
有關各監測工具的使用方法和原理,官網或者man手冊都有詳細的說明信息,為用戶選擇合適的監測工具提供了有用的參考。然而,無論是官網還是學術界,目前很難找到針對各個性能監測工具自身性能、功耗等占用資源情況的分析和比較。
功能往往是選擇監測工具時的首要考慮因素,然而當頻繁監測某個系統部件時,較小的性能監測工具也可能給系統負載帶來不容忽視的影響。理想的性能監測工具不僅應能滿足對系統單元的全面有效監測,還應盡可能少地占用系統資源,減少對系統的性能影響,提高監測數據的精確度。因此,在使用Linux系統進行部分復雜作業時,工具自身占用資源情況也應在選擇性能監測工具時考慮在內。
結合監測工具特點及操作系統性能指標,文中將從功能、性能、功耗三個維度對監測工具進行測評。
2.1.1 功 能
監測工具的功能主要體現在監測部件及監測項上,能否持續監測、監測時間粒度、輸出格式等也是要考量的方面。一般來說,通過查看官網或man手冊及相關文獻,可以對工具的功能做到比較全面的了解。
2.1.2 性 能
工具的性能體現在監控特定部件時,對CPU及內存的占用情況。文中采用top工具實時采樣監測進程占用CPU及內存資源的情況,重復多次對采樣結果取平均值,獲得監測工具的性能評估。
2.1.3 功 耗

當前Linux系統應用領域越來越廣,其運行載荷也隨之復雜多樣化;同時,針對Linux系統的性能監測工具越來越多,無法對所有工具一一測評。因此,文中采取變量遞增式的方法,針對幾種常用工具的性能功耗進行測評,旨在為選擇Linux性能監測工具提供思路。
實驗使用不同監測工具,對同一部件進行監測,并在不同運行負載的條件下,對比各工具性能及功耗指標,最終通過結果分析,給出工具選擇策略。實驗過程可以描述為
{G1,G2,…,Gn,P}=H(x_load,y_tool)
其中,x_load為運行負載;y_tool為測評對象工具;H為2.1節中的測試過程;G1~Gn分別表示不同部件在當前環境下的性能指標;P為當前環境下的工具功耗。
具體實驗步驟如下:
Step1:相同負載條件下,針對不同的同部件監測工具測評與比較。
實驗過程可以描述為:
{G1,G2,…,Gn,P}=H(x_load=c,y_tool)
其中,c表示常量,即負載不變。
對一款工具性能進行測評與橫向比較,必須限定其使用條件,在同環境下運行不同工具,能直觀反映某一工具對具體使用環境的匹配程度;但同時,此方法得出的實驗結論只能適用于相同或者相近的工具使用環境,在使用條件變化時,該方法得出的結論不具有通用性。
Step2:不同負載條件下,針對不同的同部件監測工具測評與比較。
為進一步驗證第一步的結論,本步驟中加入了負載條件的變化,實驗過程可以描述為:
{G1,G2,…,Gn,P}=H(x_load,y_tool)
當使用環境變化時,不同工具的性能功耗也隨之改變,只有在對各種使用環境和限制下的工具進行比較后,才能找到不同條件下監測工具選擇的最優解。
3.1.1 實驗對象
針對CPU、內存、磁盤、網絡等關鍵系統部件,從子系統、全系統細粒度性能監測工具中各選取了一些典型的性能監測工具作為測評對象,包括iostat、free、ifstat、sar以及collectl。
它們的主要監控命令如表1所示。

表1 常用監控命令
free、iostat及ifstat這三個子系統監測工具的功能比較單一,只能監測一個或少數幾個系統單元,sar和collectl的功能相對強大,監測單元眾多,監測數據豐富,涵蓋了常用的分系統。和sar相比,collectl還可以監測nfs、lustre以及內部通信數據,用于計算機集群的性能監測;此外,collectl還提供slabs(系統對象緩存)數據的采集。
3.1.2 實驗環境
實驗選用臺式微機的具體軟硬件環境參數如表2所示。
選取Mersenne、lmbench、unixbench等以及系統空載狀態作為CPU、內存、磁盤、系統整體的負載場景。其中,Mersenne為計算和存儲密集型程序,系統接近滿負荷運行;lmbench[17]與unixbench為經典的系統級Benchmark,平均負載低于1,空載時只有一些守護進程運行,系統負載接近0。由于網絡測試的特殊性,單獨選取netperf和系統空載狀態用于測評網絡監測工具。

表2 實驗環境配置
使用子系統監測工具iostat監測CPU與磁盤,free監測內存,ifstat監測網絡,全系統監測工具sar、collectl依次監測前述系統部件及系統整體。將監測同一部件的不同工具數據進行對比。
3.2.1 性能測試結果
性能測評實驗的數據如表3所示。

表3 監控工具占用資源數據
整體來看,五種監測工具使用時占用的系統資源都比較小,CPU利用率最大為1.004%。隨著系統由滿負荷運行降低到空載狀態,各監測工具的CPU利用率均呈現了先減小后增大的趨勢。這是因為Mersenne時單一任務運行,監測工具等待隊列較短,Idle時系統空載,監測工具優先級較高[2,18],這兩種情況下性能工具占用較多的CPU資源,而Lmbench、Unixbench時多任務執行,監測工具優先級較低,等待隊列較長,因此占用CPU資源較少。Netperf與系統空載狀態接近,工具占用CPU變化情況不明顯。
當監測相同的部件時,子系統監測工具比sar和collectl使用特定命令監測具有更大的優勢,前者的CPU利用率均低于0.1%,CPU占用率至少降低30%。對比兩個全系統細粒度的性能監測工具,相同負載下監測相同的子系統,collectl的CPU利用率相較sar至少降低15%。在內存占用率上,無論系統負載高低,無論被測單元種類,free、iostat以及sar占用的內存資源非常小,接近0,collectl則穩定在0.7%。
3.2.2 功耗測試結果
功耗測評實驗的數據如表4所示。

表4 監測工具平均功耗及占總功耗比例
注:因空載時系統功耗接近0,在計算占總功耗比例時未把idle情況考慮入內
排除一些奇異點,總體而言,所有監測工具對系統的能耗負載較小,最大不超過4 W,所占總功耗比例最大為3.02%。子系統監測工具的平均功耗普遍比對應的全系統工具監測命令降低至少30%,占總功耗比例不超過0.67;sar和collectl這兩個全系統監測工具在監測特定單元時功耗差異不明顯,普遍維持在2%以下,但當監測系統整體時,collectl在各種系統負載情況下的耗能表現都稍優于sar,普遍低了0.3~1.5 W,至少減少了7%的能耗。
從實驗結果可以看出,當監測系統分部件時,子系統監測工具的性能及功耗均優于使用相應命令的全系統監測工具。這是因為子系統監測工具框架更為簡單,只需讀取少數的系統文件;而全系統監測工具因為功能的多樣性,底層框架更為復雜,盡管只監測單一部件,依然需要占用較多資源維護整體框架。當監測系統整體時,與sar相比,collectl在性能和功耗方面具有較明顯的優勢。這得益于collectl使用了“實用報表提取語言”Perl寫成,與寫成sar的C語言相比,Perl語言集成了強大的正則表達式功能,能夠很容易地操作文本、提取有用的信息、快速處理大批量數據,這在讀取/proc系統、解碼處理相關文件時具有很大優勢。
綜上,得出如下結論:
(1)作為典型的分系統監測工具,free、iostat和ifstat簡單實用,實現特定子系統的性能監測的同時,占用的系統資源、能耗都很小;sar和collectl作為全系統細粒度監測工具,功能強大,不僅實現了豐富的系統單元監測項目,支持豐富的數據輸出和表現形式,而且在不同的系統負載測試下,均展現了出色的輕量級低負載特性。
(2)實驗設定四種監測工具的采集頻率均為每秒一次,實際使用時根據需要調整到合適的監測頻率,如每分鐘一次等,此時監測工具對系統的資源、能耗負載將會更低。
(3)給出工具選擇策略:如需監測特定的子系統,選擇對應的分系統監測工具,會比使用特定的全系統監測命令占用更少的資源;而如果需要同時監測多個子系統或者監測系統整體,全系統細粒度監測工具將是不錯的選擇,首先按照具體的功能差異進行選擇,當功能特性均滿足時,collectl將比sar更具性能及功耗上的優勢。
性能監測是系統運維調優的重要一環,隨著計算機硬件的不斷完善、Linux內核的不斷升級,涌現出一大批功能各異、性能出色的性能監測工具。從計算機硬件到計算機軟件,從CPU到內存到硬盤到網絡,多樣的性能監測工具覆蓋了面向各系統單元的監測需求,且不斷完善改進,向著高精度、低負載的方向發展。
文中選取了幾款典型的Linux系統性能監測工具,設計了針對性的測評實驗,從功能、性能、功耗多個維度進行了測試分析,發現不同的工具在不同使用環境下所表現出的性能功耗不盡相同。在使用時,應根據實際情況選擇滿足功能需求、占用系統資源較少、消耗能源較低的合適的性能監測工具,盡量降低持續監測給系統帶來的運行負載和性能影響。
目前,面向單個物理主機的性能監測工具已基本滿足應用需求,亟需在面向資源共享的虛擬化環境和面向資源整合的大規模數據中心環境下,提供精準、低負載、全系統視圖的性能監測工具。隨著大規模數據中心的興起,虛擬化技術盛行,如何衡量同一物理主機上每臺虛擬機的實際資源使用情況,對單個虛擬機的細粒度性能事件進行實時監測,是亟待解決的問題。