面向通信領域的系統監控軟件模塊的設計與實現

摘 要：給出了在通信領域的嵌入式應用中系統監控模塊的基本功能和各部分功能的具體實現方案。

關鍵詞：死循環;死鎖;系統監控;調度頻率

中圖分類號：TP311.11文獻標志碼：A

文章編號：1001-3695(2007)06-0259-03

在面向通信領域的嵌入式實時應用軟件系統設計中，系統監控是了解目標系統資源使用情況和目標系統運行狀態的窗口，其監測的對象一般應包括CPU負荷統計、是否發生進程死循環、是否產生死鎖、進程調度頻率統計、目標系統當前各進程的狀態和資源占有情況、內存的使用情況、定時器的使用情況以及異常發生時的恢復策略等。另外，系統監控還得提供一定的“干涉”手段，對目標系統運行過程中出現的各種不符合邏輯的情況可以通過調整資源的使用等方式來保障系統的可靠性、穩定性和實時性。

1 系統監控軟件模塊的整體設計框架

嵌入式實時應用系統一般都是采取基于優先級的任務調度方式。鑒于系統監控的特殊地位，在實際的設計實現中，實現系統監控功能的任務往往被設置成系統中所有任務的最高優先級，并通過睡眠→ 喚醒→運行→睡眠的循環方式運行，其整體的流程框架如圖1所示。

圖1 系統監測流程圖

其中設計中主要應考慮的因素有：睡眠時間的長短，其他事件喚醒監控任務的時機，對耗時較長的功能部分是否考慮另設進程單獨處理等，這些主要應從系統的可靠性、穩定性和實時性等方面綜合權衡考慮。

2 系統監控軟件模塊各部分功能的具體實現方案

2．1 CPU負荷統計

CPU負荷統計是在某個時間段內所有應用任務運行時間占CPU時間總量的的比例，其計算方法如下：

(1)首先獲得時間基準StandardTime。時間基準的獲得，即編制一段標準代碼StandardCode，運行StandardCode標準代碼N次，所花費的時間就為StandardTime。為計算方便，基準時間的單位用時鐘Tick數來表示。系統每秒的時鐘Tick數為Ticks。

(2)生成一個優先級最低的空閑任務，在空閑任務中循環執行標準代碼StandardCode，并對執行次數計數。假設在給定時間間隔T內StandardCode執行次數為n。

(3)CPU占有率百分比CPUUseRate計算公式為CPURate=100-100×n×StandardTime/N×T×Ticks

(4)每統計一次后，空閑任務的計數清零。

當創建了一個最低優先級的空閑任務后，系統任務可分為兩大類：空閑任務和非空閑任務，而空閑任務只用在沒有其他任務或進程可運行的時候才能有機會運行。因此，只要知道空閑任務運行的時間比例即可得到CPU的利用率。在實現中，可通過在任務切換時掛入鉤子函數的方式來得到空閑任務被調度運行的時刻和被搶占剝奪運行的時刻，兩者之差就是空閑任務該次運行的時間，在一個固定時間段里將每次空閑任務運行的時間累加起來，就可得到空閑任務在固定時間段里所占用的CPU時間。

在負荷過重的情形下，可以通過殺死占用運行時間較多的低優先級任務來保障系統可靠穩定的運行。

2．2 進程死循環與死鎖檢測

系統死鎖和程序死循環的檢測一直是多任務程序設計特別是操作系統設計的難題。在嵌入式應用中，考慮到其實時性的要求，不可能采取較復雜的算法來檢測和最終解決這些問題，只能采取一些近似的算法“模糊”地進行，其檢測方法描述如下：

在進程控制塊中增加用于死循環、死鎖檢測的兩個域：進程上一段檢測時間段內的運行（調度）次數和本次檢測時間段的運行（調度）次數，當系統監監控任務運行時，根據這兩個域值進行判斷，經過若干次的檢測后，如果二者的值相同，該任務處于運行狀態，且CPU 利用率較高，可以近似地判斷該進程進入了死循環；如果某進程組或所有進程(空閑進程和監控進程除外)是處于因臨界資源的競爭引起的阻塞狀態就可近似地認為該進程組或整個系統處于死鎖狀態，這二者均可通過殺死一些較低優先級的進程來解決，若實在不行，只得考慮系統重啟，并給出現場信息。同時，還可通過二者的差值來判斷系統是否有進程運行次數過于頻繁，如果兩者相差超過了某個閾值，可認為運行過頻，給出警告信息。

2.3 存儲單元利用情況檢測

2.3.1 通信應用領域內存管理的實現方法

嵌入式實時操作系統中的內存管理是保障應用實時性和可靠性的重要因素。在通信領域的應用中，內存申請往往呈現各種相同數據結構(即相同大小內存塊)的大量申請現象。為了提高內存管理的實時性能和可維護性，一般采用如圖2所示的內存管理方式。

每個應用程序模塊保留自己所需一塊較大的內存區，再將該內存區劃分為若干內存池。每個內存池由若干尺寸相同的內存塊組成，為了有效地管理和監控內存的使用情況，每一內存池使用一內存池控制頭存儲其管理統計信息，該結構部分內容描述如下：

內存池中每一內存塊用一內存塊控制頭來描述和控制，其部分組成信息描述如下：

由于有了這些結構，使得內存的分配和釋放性能得到很大的提高，同時大大減少了內存碎片率，并可提供一定的內存分配與釋放的調試和維護信息。內存池控制結構描述中的加黑斜體部分為監控模塊要輸出的內存池統計信息，這必然要求在內存塊分配與釋放時進行相應的操作統計。同時，每一內存區也對應有如下的統計信息：

這樣，通過對這些控制結構的訪問，便能輸出較詳盡的內存監控信息。由于對內存的分配限于設定的內存區中，內存分配失敗的情形便不可避免了。對于通信領域的有些應用來說，內存分配失敗有可能導致災難性的后果，解決的辦法主要有兩種：靜態預留和動態自適應調整。靜態預留的方法是在每一內存池中專門保留一定數量的內存塊給高優先級進程，在一定程度上確保關鍵任務的內存需求得到滿足。動態自適應是當某一內存池中的無空閑內存或空閑內存數量少于某一臨界值時，從其他內存池中調整一些過來，為以后在該內存池上的內存申請作準備，內存池動態調整功能可放在系統監控任務中完成。

2.3.2 內存池動態調整算法

為了合理地進行內存池動態調整，在內存池控制結構中增加一些信息域：最少內存塊數閾值，該內存池最近是否未訪問標志，該內存池是否從未訪問標志等。增加兩個標志，主要利用了內存訪問的局部性原理，每當有內存申請時，對這兩標志復位。在內存塊釋放時，對該內存池的最近是否未訪問標志置位。具體的調整步驟描述如下：

遍歷當前模塊內存區內各內存池控制頭，查找是否有剩余空閑塊數小于最少內存塊數閾值的內存池，如不存在這樣的內存池，動態調整結束；否則，嘗試按下面的步驟對該內存池進行擴容：

(1)對塊尺寸大于待擴容內存池塊尺寸的所有內存池依次查找，直到遇到一內存池滿足：內存池從未有進程申請過；剩余空閑塊數大于其最少內存塊數閾值；若存在這樣的內存池，從該池空閑塊隊列摘下一塊，轉步驟(4)；否則，轉步驟(2)。

(2)對塊尺寸大于待擴容內存池塊尺寸的所有內存池依次查找，直到遇到一內存池滿足：該內存池最近無用戶任務訪問過；該池中剩余內存空閑塊數大于其內存塊總數的一定比例值；該池中剩余空閑塊數大于其最少內存塊數閾值，若存在這樣的內存池，從該池空閑塊隊列摘下一塊，轉到步驟(4)，否則轉到步驟(3)。

(3)對塊尺寸大于待擴容內存池塊尺寸的所有內存池依次查找，直到遇到一內存池滿足：該池中剩余空閑塊數大于其內存塊總數的一定比例值；剩余空閑塊數大于最少內存塊數閾值若存在這樣的內存池，從該池空閑塊隊列摘下一塊，轉步驟(4)，否則調整結束。

(4)把摘下的空閑內存塊塊逐級分拆到包括待擴容內存池在內的多個內存池中。之所以采取逐級分拆的方式是因為若找到的內存塊遠遠大于待擴容內存池中的內存塊，全部分配給它對以后的再調整不公平，則造成整個內存向低端內存池（內存塊尺寸較小的內存池）聚集現象特別嚴重，故除了待擴容內存池外，對塊尺寸大于待擴容內存池而小于空閑塊來源內存池塊尺寸的內存池都準備給予擴容，由于不同內存池中的內存塊大小往往為2n關系，實現逐級分拆的算法比較簡單。

考慮到時間性能的問題，調整算法一般不考慮調整低端內存池中內存到高端內存池中。同時，如果模塊分區不多，則算法也可以考慮不同模塊內存分區之間的動態調整。由于同一內存區內內存池不會劃分太多（一般小于10個），動態調整對系統的時間性能影響則不會太大。

2．4 定時器監控

在通信領域的軟件設計中，定時器管理也是至關重要。如大型程控交換中的呼叫管理，有的應用任務有可能需設置成千上萬的定時器，如何在實現中對這些“海量”定時器進行合理的組織和管理往往成為提高整個應用系統性能的瓶頸。在通信領域，主要有以下幾類定時器：①絕對定時器——時間表示為具體的年月日時分秒等；②相對定時器——時間表示為以系統當前運行時刻為起點的時鐘滴答數(Ticks);③循環定時器——以給定的時間間隔循環計時。定時器的監控主要是輸出當前各種類定時器的使用數量及系統能接受的最大定時器數目和有可能遺漏的時鐘滴答數等，這就要求在定時器的申請、釋放及時鐘中斷處理時對相應的統計信息進行及時更新。

2．5 異常恢復策略

面對實際應用中的各種復雜情形，要求系統完全健壯是不可能的，因此當監控發現系統可能產生致命錯誤時，采取必要的恢復校正措施是必不可少的。在面向通信領域的應用中，一種較通用的異常處理流程框架如圖3所示。該流程框架包含三部分：初始化部分、異常必要信息處理部分和異常守護處理部分。在異常處理初始化部分中，首先以許多實時操作系統提供的異常“鉤子函數”的方式掛入相應的異常處理函數，然后創建異常信號量和異常守護任務。異常發生時，由異常處理函數通過釋放異常信號量來激活異常守護任務，并在守護任務中執行用戶掛接的異常恢復策略。

圖3 面向通信領域的異常處理流程圖

3 結束語

通信領域的軟件設計中，系統監控是保障系統的可靠性、穩定性和實時性的重要因素。如何準確地檢測到系統存在的問題并能對問題給出一定的預防或解決辦法理論上都可以由監控軟件模塊來完成；但是由于監控任務優先運行的特點，如果其處理量太大，會擠占應用任務的CPU時間，從而又使整個系統的實時性能下降。一般而言，監控任務只處理那些耗時較小并對整個系統性能影響至關重要的監控功能。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。