基于System Tap的Linux服務器性能分析系統(tǒng)的設計與實現(xiàn)

裴歐亞，康慕寧，張 磊

（西北工業(yè)大學 計算機學院，陜西 西安 710072）

隨著Linux操作系統(tǒng)在大型服務器上的廣泛應用，對系統(tǒng)的性能提出了更高的要求。因此Linux系統(tǒng)開發(fā)人員希望通過對Linux系統(tǒng)進行性能測試，定位系統(tǒng)瓶頸，分析引起性能問題的原因。系統(tǒng)的性能不能通過單一指標來判定，必須通過系統(tǒng)的整體性（綜合指標）來判定。Linux作為全球最廣泛使用的開源操作系統(tǒng)，其超高的性價比，決定了對此內(nèi)核的可視化性能分析研究具有重要的學術意義及深遠的教育意義。

可視化其實質(zhì)是利用計算機的圖形圖像技術，把各種數(shù)據(jù)信息轉換成合適的圖形圖像在屏幕上表示出來。這一過程涉及到圖形學、和人機交互等領域知識?；赟ystemTap的Linux服務器性能分析系統(tǒng)通過SystemTap，在Linux內(nèi)核的合適位置添加探針，當啟動檢測時，以事件追蹤機制實時進行數(shù)據(jù)的收集、解析，最終以可視化的界面呈現(xiàn)給用戶。用戶可以通過可視化界面直觀的對系統(tǒng)的資源利用率及運行狀況進行性能分析和優(yōu)化。

1 性能分析系統(tǒng)設計分析

針對為滿足Linux服務器性能分析的需求，結合SystemTap及 “事件追蹤機制”等技術方式，經(jīng)過分析得到Linux性能數(shù)據(jù)共分為以下3個部分：進程/線程的實時運行狀態(tài)；進程間的通信狀況；以及對系統(tǒng)資源的占用狀況。

要想完成以上性能數(shù)據(jù)的收集、分析及可視化等功能，需要做好以下幾個方面。首先服務器端應能實時收集性能數(shù)據(jù)，并且能確保將收集到的性能數(shù)據(jù)傳回客戶端；其次客戶端能正確解析服務器段傳回的性能數(shù)據(jù)，即將數(shù)據(jù)轉換成可視化數(shù)據(jù)；最后可視化模塊能將最終結果呈現(xiàn)給用戶。

本系統(tǒng)在軟件架構上基于C/S結構，server端負責接收命令、收集數(shù)據(jù)及發(fā)送數(shù)據(jù)，client端負責控制、解析數(shù)據(jù)及顯示數(shù)據(jù)，很好的滿足了用戶提出的“盡量減小對服務器性能影響”的需求。

C/S（Client/Server）模式即客戶端服務器端架構，它可以采用任何通信協(xié)議，客戶端包含一個或多個在用戶的電腦上運行的程序，客戶端向服務器端發(fā)送請求命令，由服務器處理響應并將信息返還給客戶端，再由客戶端處理服務器的返回信息并將處理結果顯示給用戶。雖然B/S架構是對C/S架構的改進，但是C/S相較于B/S，其具有的響應速度快，對服務器性能影響較輕的特性，決定了本系統(tǒng)必須使用C/S架構。

2 總體設計

該性能分析系統(tǒng)的系統(tǒng)結構圖如圖1所示，在對目標服務器進行測量時，首先目標服務器必須開啟Server端服務；接著Client端向Server端發(fā)送開始監(jiān)測命令，Serevr端收到開始命令、啟動監(jiān)測并記錄數(shù)據(jù)；然后Client端向Server端發(fā)送終了監(jiān)測命令，Server端收到終了命令、停止監(jiān)測并將數(shù)據(jù)傳回Client端；最后Client端先調(diào)用解析模塊將Server端傳回的數(shù)據(jù)解析，然后調(diào)用可視化模塊將解析的結果以圖形化方式顯示給用戶。

圖1 系統(tǒng)結構圖Fig.1 Structure diagram of performance analysis system

3 性能分析系統(tǒng)軟件設計

該性能分析系統(tǒng)軟件采用C/S架構，客戶端功能：向服務器端發(fā)送控制命令、接受服務器端數(shù)據(jù)、數(shù)據(jù)解析及數(shù)據(jù)可視化功能，服務器端功能：接受客戶端命令后回傳性能數(shù)據(jù)和收集性能數(shù)據(jù)。為了日后的更新、維護和拓展，在設計過程中采用模塊化的思想，因此將客戶端劃分為通信模塊，數(shù)據(jù)解析模塊，數(shù)據(jù)顯示模塊。服務器端劃分為通信模塊，數(shù)據(jù)收集模塊。系統(tǒng)軟件設計的結構圖如圖2所示。

圖2 系統(tǒng)軟件設計結構圖Fig.2 diagram of the software analysis system

在軟件設計中，數(shù)據(jù)收集模塊主要用來實現(xiàn)對Linux服務器性能數(shù)據(jù)的收集；服務器端的通信模塊主要用來接受客戶端發(fā)送來的命令，通過該模塊可以控制數(shù)據(jù)收集模塊的啟用開關，并且能將收集到的性能數(shù)據(jù)傳回客戶端；客戶端的通信模塊主要用來向服務器端發(fā)送命令以及接受服務器端傳回的性能數(shù)據(jù)；數(shù)據(jù)解析模塊主要用來將性能數(shù)據(jù)解析成可視化的數(shù)據(jù)；數(shù)據(jù)顯示模塊主要用來將可視化的結果以圖形化界面方式呈現(xiàn)給用戶。

4 性能分析系統(tǒng)重要模塊的設計與實現(xiàn)

4.1 數(shù)據(jù)收集模塊

為了收集linux實時的運行數(shù)據(jù)，必須借助于System Tap[1-6]，在Linux kernel源代碼的關鍵之處加上探針，并為所加探針新規(guī)處理函數(shù)（保存獲取的內(nèi)核數(shù)據(jù)）。一旦探針被觸發(fā)，被觸發(fā)探針的處理函數(shù)立即保存獲取的內(nèi)核數(shù)據(jù)。

例如：創(chuàng)建進程（sched_process_fork）處添加探針及探針處理函數(shù)如下：

實現(xiàn)數(shù)據(jù)收集模塊的難點有以下3點：

第一點：確定探針添加的位置。探針添加的位置決定能獲取何種類型的linux內(nèi)核數(shù)據(jù)。此外SystemTap的探針處理是以中斷方式處理的，而linux內(nèi)核在某些代碼處不允許產(chǎn)生中斷（中斷會導致系統(tǒng)宕機等問題），再加上SystemTap理論上可以在linux內(nèi)核任意位置添加探針，所以添加探針的操作必須小心謹慎。因此需要開發(fā)人員必須熟悉linux內(nèi)核某個功能或全部功能的源代碼及處理邏輯流程。

第二點：探針處理函數(shù)的高并發(fā)導致的“寫競爭”。每一個探針都關聯(lián)一個寫內(nèi)存的處理函數(shù)。在負載很重的服務器上，同一個探針不間斷被觸發(fā)，或多個探針同時被觸發(fā)，都會導致多個處理函數(shù)競爭同一個內(nèi)存塊。因此必須為內(nèi)存塊填加寫互斥鎖，實現(xiàn)內(nèi)存塊的互斥訪問。本系統(tǒng)為實現(xiàn)寫內(nèi)存互斥，定義了一個全局的靜態(tài)變量（變更靜態(tài)變量值的操作是原子操作）。每一個處理函數(shù)寫內(nèi)存之前都要先判斷靜態(tài)變量的值。如果為TRUE則可繼續(xù)進行后續(xù)操作；否則，將阻塞。

第三點：長時間測量。經(jīng)過實驗：單臺小型服務器在高負荷工作時，少量探針（hooks）每秒產(chǎn)生的需要保存的數(shù)據(jù)就高達40M，因此只能將收集的數(shù)據(jù)寫入磁盤保存。為了避免頻繁寫磁盤對服務器正常I/O操作產(chǎn)生影響，同時加快寫磁盤的速率，盡可能避免因磁盤寫速率低造成的數(shù)據(jù)丟失。本系統(tǒng)采用如下設計：

在內(nèi)存中申請3塊大小為64M （可由用戶手動設置，默認最小 64M）的內(nèi)存空間，編號為 BufferNo0，BufferNo1，BufferNo2。這3塊內(nèi)存按編號從小到大循環(huán)使用。只有當當前的內(nèi)存空間為空并且前一塊內(nèi)存空間寫滿的情況下，才能向當前的內(nèi)存空間寫數(shù)據(jù)。每一塊內(nèi)存都有互斥鎖，保證同時只有一個探針的處理函數(shù)向可寫內(nèi)存塊寫數(shù)據(jù)。每當一塊空間寫滿，立刻將該寫滿的內(nèi)存塊中的數(shù)據(jù)轉移至磁盤，同時清空該內(nèi)存塊，為接下來需要保存的數(shù)據(jù)準備空間。

4.2 數(shù)據(jù)解析模塊

從服務器端傳回的性能數(shù)據(jù)是以二進制的形式保存的，用戶幾乎不可能快速通過查閱二進制信息來分析服務器的狀況。因此必須將二進制形式的數(shù)據(jù)解析成方便用戶查閱及可視化模塊使用的數(shù)據(jù)格式。

長時間的收集使得最終收集的數(shù)據(jù)量高達數(shù)G（目前最大支持4G），因此解析大數(shù)據(jù)的性能成了本性能分析系統(tǒng)的瓶頸。

為了提升解析數(shù)據(jù)的效率，最終選取了Windows操作系統(tǒng)提供的內(nèi)存文件映射技術。內(nèi)存映射文件技術是由一個內(nèi)存映射文件是由一個文件到一塊內(nèi)存的映射，使進程虛擬地址空間的某個區(qū)域與磁盤上某個文件的部分或全部內(nèi)容建立映射。建立映射后，通過該映射區(qū)域可以直接對被映射的磁盤文件進行訪問，而不必執(zhí)行文件的I/O操作，也無需對文件內(nèi)容進行緩沖處理，就好像整個被映射的文件都加載到了內(nèi)存一樣。

運行內(nèi)存映射主要有以下幾個步驟：

1）用函數(shù)CreateFile（），以適當?shù)姆绞絼?chuàng)建或打開一個文件核心對象；2）將函數(shù)CreateFile（）返回的文件句柄作為參數(shù)，調(diào)用函數(shù)CreateFileMapping（），創(chuàng)建一個內(nèi)存文件映射對象；3）調(diào)用函數(shù)MapViewOfFile（）將整個文件的部分區(qū)域或者全部映射到內(nèi)存；4）用函數(shù)MapViewOfFile（）返回的指針來讀寫文件；5）調(diào)用函數(shù)UnMapViewOfFile（）來解除文件映射；6）調(diào)用函數(shù) CloseHandle（）來關閉內(nèi)存映射文件；7）調(diào)用函數(shù)CloseHandle（）來關閉文件核心對象[7]。

4.3 數(shù)據(jù)顯示模塊

數(shù)據(jù)顯示模塊主要是將數(shù)據(jù)解析模塊生成的可視化數(shù)據(jù)以圖形界面的方式呈現(xiàn)給用戶。為了消除重繪過程中產(chǎn)生的閃屏問題，采用了雙緩沖機制來繪制圖像[8]。

可視化界面沿著水平時間軸 （單位/s）真實地還原了linux服務器運行時，進程調(diào)度、磁盤調(diào)度、系統(tǒng)資源（cpu、disk等）的占用率。

可視化界面[9]截圖如圖3所示。

圖3 可視化界面截圖Fig.3 The screenshot of visualization interface

圖3的左側是Linux運行時所有進程的列表，包括進程名、進程ID及線程ID。右側就是進程動作狀況表示區(qū)域，顯示所有進程/線程實時運行狀況。進程/線程對Cpu和磁盤的使用狀況只分為兩種狀態(tài)：執(zhí)行中和等待即空閑狀態(tài)，分別標記不同的顏色進行區(qū)分。當不同進程進行通信時，以不同的顏色進行區(qū)分通信的方式，如信號、PIPE（管道）、NPIPE（無名管道）、MESSAGE等方式。

圖3中顯示了進程號和線程號均是4389的進程Xorg與進程號和線程號均是4727的進程gnome-terminal之間通信的動作。

5 性能分析系統(tǒng)應用

某一產(chǎn)品軟件，客戶端和服務器端通信開銷突然從0.5 s增加至4 s。由于邏輯復雜，開發(fā)人員短時間內(nèi)無法分析出問題原因，通過使用本系統(tǒng)，使內(nèi)核狀況可視化，只用一個小時就將問題點明確，快速解決了該問題。

通過可視化測量結果，進行詳細分析，發(fā)現(xiàn)一個問題見圖4中第一幅圖虛線框列出的問題：1。

圖4 可視化性能分析實例Fig.4 The example of Visualization performance analysis

問題：CPU等待/空閑區(qū)間過多

根據(jù)問題應采取以下措施進行改善：

1）CPU等待/空閑區(qū)間的原因檢討；

2）減少進程間的通信次數(shù)；

通過以上兩點對代碼進行改善，再次運行后，對比發(fā)現(xiàn)：改善前需要9.75 s的處理時間，改善后只需要1.95 s（約1/5）。

注：上下兩幅圖倍率，區(qū)間相同 （時間間隔6 s）

6 結 論

本軟件系統(tǒng)采用模塊化設計，提高了系統(tǒng)的可擴展性和可維護性，便于二次開發(fā)。該軟件系統(tǒng)采用了友好的界面設計，目前已交付某大型跨國IT企業(yè)使用，主要用于分析該企業(yè)大中型服務器的性能。實際應用情況表明，該系統(tǒng)顯著地縮短了解決服務器性能問題所需的時間，同時該系統(tǒng)還具有操作簡單，穩(wěn)定可靠、人機交互良好等特點，達到了要求。

但是本系統(tǒng)還有以下不足：

1）在Linux操作系統(tǒng)中添加的‘探針’數(shù)量較少，導致獲取的性能數(shù)據(jù)不足。

2）Linux服務器將內(nèi)存數(shù)據(jù)轉移至磁盤過程中，由于探針產(chǎn)生的數(shù)據(jù)量過大，會導致部分需要收集的數(shù)據(jù)丟失。

3）可視化界面對性能數(shù)據(jù)的顯示粒度略顯粗糙。

因此，后期將對以上不足進行仔細分析并逐一解決，進一步完善本文所描述的性能分析系統(tǒng)。

[1]李云華.Linux內(nèi)核調(diào)試新秀System Tap[R].程序員，2010，（3）:127-127.

[2]Frank Ch.Eigler.Systemtap tutorial[EB/OL].（2013）[2013-08-20].http://www.sourceware.org/systemtap/tutorial.pdf

[3]SystemTap Language Reference[EB/OL].（2013）[2013-08-20].http://www.sourceware.org/systemtap/langref.pdf

[4]薛偉偉.軟件性能測試和分析方法的研究與應用 [D].西安:西北工業(yè)大學，2013.

[5]謝雨辰.基于SystemTap的Kprobes與Relayfs的開發(fā)[D].吉林:吉林大學，2007.

[6]Prasad V，Cohen W，Eigler F，etal.Locating system problems using dynamic instrumentation[C]//Linux Symposium，2005:49-64.

[7]馬禮，李敬喆，葛根焰，等.一種基于多核環(huán)境的海量數(shù)據(jù)快速讀取方法[J].計算機研究與發(fā)展，2011（48）:63-67.MA Li，LI Jing-zhe，GE Gen-yan，et al.Quick-Read means ofmass data based on multi-core environment[J].Journal of Computer Research and Development，2011（48）:63-67.

[8]明日科技，孫秀梅，王雪，等.Visaul C++典型模塊與項目實戰(zhàn)大全[M].北京：電子工業(yè)出版社，2012.

[9]王卉，趙政文，齊萬華.基于Windows運行過程可視化的軟件性能分析[J].微處理機，2013（1）:45-48.WANG Hui，ZHAO Zheng-wen，QI Wan-hua.Software performance analysis of visualized software based on windows operating[J].Microprocessors，2013（1）:45-48.