基于動(dòng)態(tài)追蹤的自愈操作系統(tǒng)故障監(jiān)測(cè)技術(shù)

史佳龍，朱怡安，陸 偉，柴瑞亞

1.西北工業(yè)大學(xué) 計(jì)算機(jī)學(xué)院，西安 710072

2.西北工業(yè)大學(xué) 軟件與微電子學(xué)院，西安 710072

1 引言

隨著各類嵌入式系統(tǒng)應(yīng)用日益廣泛，對(duì)其可靠性和安全性的需求也隨之提高[1-2]。具備自愈能力的操作系統(tǒng)可在無(wú)需人工干預(yù)的情況下自動(dòng)發(fā)現(xiàn)、診斷并修復(fù)故障，進(jìn)而使得操作系統(tǒng)在遭遇系統(tǒng)失效時(shí)，還能夠繼續(xù)為用戶程序提供服務(wù)，可以有效減少當(dāng)前操作系統(tǒng)內(nèi)核在出現(xiàn)故障部分或全部服務(wù)失效時(shí)帶來(lái)的損失[3]，對(duì)提高系統(tǒng)可靠性有重要的意義。自愈操作系統(tǒng)中將系統(tǒng)的自愈過(guò)程抽象為監(jiān)測(cè)、診斷和恢復(fù)三個(gè)自主元素，作為自愈操作系統(tǒng)對(duì)故障的感知手段，故障監(jiān)測(cè)可以使操作系統(tǒng)具備自主發(fā)現(xiàn)故障的能力[4]，是自愈操作系統(tǒng)實(shí)現(xiàn)自主故障定位診斷及恢復(fù)的基礎(chǔ)，在自愈操作系統(tǒng)研究中具有重要的意義。當(dāng)前已有的操作系統(tǒng)故障監(jiān)測(cè)技術(shù)大都需要硬件支持或?qū)ο到y(tǒng)代碼進(jìn)行修改，本文根據(jù)已有研究中對(duì)操作系統(tǒng)內(nèi)核故障分類和故障點(diǎn)分布的研究，針對(duì)內(nèi)核中動(dòng)態(tài)內(nèi)存分配和資源競(jìng)爭(zhēng)相關(guān)故障提出了一種基于動(dòng)態(tài)追蹤的故障監(jiān)測(cè)技術(shù)，在Linux操作系統(tǒng)中該機(jī)制利用操作系統(tǒng)支持的斷點(diǎn)機(jī)制以可加載內(nèi)核模塊的形式實(shí)現(xiàn)，不需要對(duì)原系統(tǒng)進(jìn)行擴(kuò)展或修改，并通過(guò)故障注入實(shí)驗(yàn)對(duì)提出的監(jiān)測(cè)技術(shù)的有效性從故障檢測(cè)率、誤報(bào)率、系統(tǒng)負(fù)載和監(jiān)測(cè)延時(shí)幾方面進(jìn)行了驗(yàn)證。

2 基于動(dòng)態(tài)追蹤的故障監(jiān)測(cè)技術(shù)

操作系統(tǒng)故障監(jiān)測(cè)技術(shù)可分為基于異常事件、基于時(shí)間和基于系統(tǒng)性能指標(biāo)三類?；诋惓Ｊ录谋O(jiān)測(cè)技術(shù)主要通過(guò)感知系統(tǒng)中出現(xiàn)的異常事件來(lái)進(jìn)行故障感知[5]，其能夠監(jiān)測(cè)的故障類型有限，且一般需要對(duì)原系統(tǒng)代碼進(jìn)行修改；基于時(shí)間的監(jiān)測(cè)典型代表為定時(shí)器機(jī)制[6]，當(dāng)系統(tǒng)出現(xiàn)故障導(dǎo)致定時(shí)器未被周期性重置時(shí)，則認(rèn)為操作系統(tǒng)或某個(gè)部件出現(xiàn)故障，無(wú)法精確診斷出現(xiàn)了何種故障以及定位故障點(diǎn)，有時(shí)需要在原有系統(tǒng)中增加必要的軟件模塊或特定硬件；基于系統(tǒng)指標(biāo)的監(jiān)測(cè)技術(shù)通過(guò)對(duì)整體操作系統(tǒng)性能指標(biāo)異常值的監(jiān)測(cè)實(shí)現(xiàn)對(duì)故障的監(jiān)測(cè)[7-8]，通過(guò)故障映射模型實(shí)現(xiàn)較為精確的故障診斷，但模型的建立大都需要訓(xùn)練過(guò)程以達(dá)到較好的監(jiān)測(cè)效果，可移植性無(wú)法得到保證。

已有研究中在設(shè)計(jì)故障監(jiān)測(cè)技術(shù)時(shí)，大都沒(méi)有對(duì)目標(biāo)系統(tǒng)的故障分類和分布進(jìn)行分析，故其適用性無(wú)法得到保證，當(dāng)前已有的基于語(yǔ)義匹配的代碼靜態(tài)分析[9-10]和利用操作系統(tǒng)崩潰現(xiàn)場(chǎng)數(shù)據(jù)進(jìn)行故障點(diǎn)分析[11]的研究結(jié)果表明，操作系統(tǒng)中的故障往往集中分布在特定內(nèi)核位置。針對(duì)在操作系統(tǒng)中內(nèi)核故障造成影響較應(yīng)用程序故障更為嚴(yán)重的問(wèn)題，Deshpande等人[12]進(jìn)一步將操作系統(tǒng)的故障歸結(jié)為以下四類：非法指針訪問(wèn)、程序邏輯中預(yù)先設(shè)定的崩潰點(diǎn)、內(nèi)存泄露、同步機(jī)制的不恰當(dāng)使用導(dǎo)致的資源競(jìng)爭(zhēng)。四類故障中，除去人為設(shè)定的內(nèi)核崩潰點(diǎn)，內(nèi)核中的故障點(diǎn)集中于內(nèi)存分配使用及回收、資源競(jìng)爭(zhēng)同步等方面，且非法指針的訪問(wèn)造成在很多情形下是由于內(nèi)存分配使用不當(dāng)、同步不當(dāng)導(dǎo)致的數(shù)據(jù)覆蓋造成的。在Linux中由于內(nèi)核程序共享執(zhí)行空間，單點(diǎn)的故障會(huì)傳播到整個(gè)內(nèi)核進(jìn)而影響其他程序的執(zhí)行，甚至造成系統(tǒng)整體失效[13]。

針對(duì)Linux操作系統(tǒng)，基于以上內(nèi)核故障點(diǎn)的分析，本文將內(nèi)核中內(nèi)存分配和資源競(jìng)爭(zhēng)操作相關(guān)的故障作為主要監(jiān)測(cè)目標(biāo)，而此類操作在內(nèi)核中往往表現(xiàn)為統(tǒng)一的方法調(diào)用（將其定義為內(nèi)核關(guān)鍵方法），因此故障的產(chǎn)生與關(guān)鍵方法的不恰當(dāng)使用存在直接的因果關(guān)系。通過(guò)動(dòng)態(tài)追蹤內(nèi)核方法調(diào)用，可以對(duì)導(dǎo)致內(nèi)核全局?jǐn)?shù)據(jù)狀態(tài)遷移的方法調(diào)用進(jìn)行記錄，依據(jù)設(shè)定的規(guī)則對(duì)記錄的調(diào)用序列和數(shù)據(jù)進(jìn)行分析，可實(shí)現(xiàn)對(duì)故障的監(jiān)測(cè)和定位。圖1中為本文提出的基于動(dòng)態(tài)追蹤的故障監(jiān)測(cè)架構(gòu)，內(nèi)核動(dòng)態(tài)追蹤機(jī)制由三部分構(gòu)成，監(jiān)測(cè)斷點(diǎn)定義模塊設(shè)定需要監(jiān)測(cè)的關(guān)鍵方法；監(jiān)測(cè)數(shù)據(jù)采集模塊用于記錄系統(tǒng)調(diào)用的執(zhí)行序列，將每次方法調(diào)用的內(nèi)核上下文信息以及調(diào)用參數(shù)、返回值信息存儲(chǔ)到監(jiān)測(cè)信息鏈表中；故障診斷模塊依據(jù)追蹤信息和設(shè)計(jì)的規(guī)則進(jìn)行故障診斷并輸出診斷結(jié)果。

圖1 內(nèi)核動(dòng)態(tài)追蹤機(jī)制架構(gòu)

自旋鎖機(jī)制是操作系統(tǒng)中廣泛使用的一種資源同步機(jī)制，已有的研究成果中也將其列為主要故障點(diǎn)，根據(jù)內(nèi)核動(dòng)態(tài)追蹤架構(gòu)，圖2中描述了操作系統(tǒng)中監(jiān)測(cè)自旋鎖相關(guān)故障的過(guò)程，通過(guò)在自旋鎖獲取內(nèi)核方法和自旋鎖釋放內(nèi)核方法調(diào)用前后設(shè)置監(jiān)測(cè)斷點(diǎn)，可以對(duì)內(nèi)核中獲取和釋放自旋鎖的操作信息進(jìn)行記錄，并通過(guò)全局鏈表的方式進(jìn)行保存，在進(jìn)行內(nèi)核信息采集時(shí)，需要注意分析當(dāng)前方法調(diào)用導(dǎo)致的內(nèi)核狀態(tài)變化，確定斷點(diǎn)處理程序類型為應(yīng)當(dāng)在關(guān)鍵方法之前或者之后執(zhí)行，如當(dāng)使用__raw_spin_lock_bh獲取自旋鎖時(shí)會(huì)關(guān)閉系統(tǒng)軟中斷，此時(shí)若要監(jiān)測(cè)鎖釋放操作__raw_spin_unlock_bh則斷點(diǎn)處理程序應(yīng)當(dāng)在釋放鎖關(guān)鍵方法之后執(zhí)行，因?yàn)閮?nèi)核在關(guān)中斷的狀態(tài)下操作監(jiān)測(cè)數(shù)據(jù)鏈表可能導(dǎo)致內(nèi)核卡死。在進(jìn)程調(diào)用do_exit方法退出時(shí)，檢查監(jiān)測(cè)隊(duì)列中是否存在于當(dāng)前要退出進(jìn)程相關(guān)的記錄，通過(guò)對(duì)記錄中的信息分析進(jìn)行故障診斷。

圖2 內(nèi)核自旋鎖故障監(jiān)測(cè)實(shí)例

Hector[13]、Lockout[14]使用代碼靜態(tài)分析的方法也實(shí)現(xiàn)了對(duì)內(nèi)核故障點(diǎn)的追蹤，但實(shí)際系統(tǒng)在運(yùn)行過(guò)程中時(shí)，由于內(nèi)核中中斷、搶占等機(jī)制的存在，靜態(tài)代碼分析的故障追蹤并不能完全發(fā)現(xiàn)系統(tǒng)中可能存在的故障，而本文中提出的監(jiān)測(cè)技術(shù)可以偵測(cè)到內(nèi)核中實(shí)際的調(diào)用序列和上下文信息，對(duì)故障實(shí)現(xiàn)更為有效的監(jiān)測(cè)。

3 故障監(jiān)測(cè)器實(shí)現(xiàn)

3.1 監(jiān)測(cè)器架構(gòu)

故障監(jiān)測(cè)器由監(jiān)測(cè)模塊和數(shù)據(jù)顯示兩個(gè)主要模塊構(gòu)成，其中監(jiān)測(cè)模塊以可加載內(nèi)核模塊的形式實(shí)現(xiàn)，可以根據(jù)需求動(dòng)態(tài)地加載到內(nèi)核中運(yùn)行，針對(duì)不同類型的故障可同時(shí)加載多個(gè)故障監(jiān)測(cè)器，而數(shù)據(jù)顯示模塊在用戶態(tài)實(shí)現(xiàn)，顯示界面使用wxPython程序庫(kù)設(shè)計(jì)實(shí)現(xiàn)，實(shí)現(xiàn)故障監(jiān)測(cè)結(jié)果的顯示，兩個(gè)模塊以系統(tǒng)日志為數(shù)據(jù)交互媒介。故障監(jiān)測(cè)模塊的實(shí)現(xiàn)包括監(jiān)測(cè)點(diǎn)、監(jiān)測(cè)數(shù)據(jù)鏈表和斷點(diǎn)處理程序三部分，其中監(jiān)測(cè)點(diǎn)可定義為Jprobe、Kretprobe和Kprobe三類，分別用于獲取內(nèi)核調(diào)用參數(shù)、返回值以及調(diào)用棧信息；監(jiān)測(cè)數(shù)據(jù)鏈表用于存儲(chǔ)監(jiān)測(cè)信息；斷點(diǎn)處理程序根據(jù)采集到的內(nèi)核信息對(duì)監(jiān)測(cè)數(shù)據(jù)鏈表進(jìn)行維護(hù)，可令其在斷點(diǎn)發(fā)生之前或之后執(zhí)行，在程序退出時(shí)分析監(jiān)測(cè)數(shù)據(jù)鏈表數(shù)據(jù)，從而進(jìn)行故障診斷。

3.2 資源競(jìng)爭(zhēng)故障監(jiān)測(cè)

以自旋鎖相關(guān)故障為例說(shuō)明對(duì)資源競(jìng)爭(zhēng)類故障的監(jiān)測(cè)方法，主要是通過(guò)對(duì)鎖獲取函數(shù)、鎖釋放函數(shù)以及進(jìn)程退出函數(shù)的監(jiān)測(cè)實(shí)現(xiàn)對(duì)故障的定位診斷，其中使用的監(jiān)測(cè)方法以及相應(yīng)的斷點(diǎn)處理程序功能描述如表1所示。

對(duì)于監(jiān)測(cè)到的每一次鎖操作，監(jiān)測(cè)程序動(dòng)態(tài)分配一個(gè)結(jié)構(gòu)體來(lái)記錄鎖操作相關(guān)數(shù)據(jù)，監(jiān)測(cè)記錄結(jié)構(gòu)體中會(huì)記錄鎖指針、獲取鎖的進(jìn)程以及鎖類型和當(dāng)前進(jìn)程執(zhí)行上下文（flags），并維護(hù)一個(gè)監(jiān)測(cè)記錄鏈表來(lái)記錄操作系統(tǒng)中當(dāng)前鎖的申請(qǐng)釋放情況。在監(jiān)測(cè)到某一個(gè)進(jìn)程的釋放鎖操作后，查詢監(jiān)測(cè)鏈表并將其中對(duì)應(yīng)的信息刪除，在監(jiān)測(cè)到某個(gè)進(jìn)程的退出操作時(shí)（Linux中進(jìn)程在退出時(shí)都會(huì)調(diào)用統(tǒng)一的接口do_exit），對(duì)監(jiān)測(cè)鏈表執(zhí)行相同查詢過(guò)程，若發(fā)現(xiàn)不存在該進(jìn)程相關(guān)記錄，則說(shuō)明該進(jìn)程的鎖操作沒(méi)有出現(xiàn)獲取而沒(méi)有釋放的錯(cuò)誤，否則說(shuō)明當(dāng)前進(jìn)程在退出時(shí)沒(méi)有完全釋放其占有的鎖，可能造成資源競(jìng)爭(zhēng)導(dǎo)致系統(tǒng)故障，此時(shí)監(jiān)測(cè)程序會(huì)向系統(tǒng)日志中輸出相關(guān)的故障信息，供顯示模塊讀取。

3.3 動(dòng)態(tài)內(nèi)存分配監(jiān)測(cè)

同對(duì)資源競(jìng)爭(zhēng)類故障的監(jiān)測(cè)原理相同，對(duì)內(nèi)核動(dòng)態(tài)內(nèi)存分配的監(jiān)測(cè)是通過(guò)對(duì)vmalloc和vfree以及do_exit方法的監(jiān)測(cè)實(shí)現(xiàn)的，具體說(shuō)明見(jiàn)表2。

對(duì)于監(jiān)測(cè)到的每一次動(dòng)態(tài)內(nèi)存分配操作，監(jiān)測(cè)程序動(dòng)態(tài)分配一個(gè)結(jié)構(gòu)體來(lái)記錄內(nèi)存操作相關(guān)數(shù)據(jù)，對(duì)于每一個(gè)動(dòng)態(tài)內(nèi)存分配操作，監(jiān)測(cè)記錄結(jié)構(gòu)體中會(huì)記錄分配的內(nèi)存指針、獲取內(nèi)存的進(jìn)程并維護(hù)一個(gè)監(jiān)測(cè)記錄鏈表來(lái)記錄操作系統(tǒng)中當(dāng)前動(dòng)態(tài)內(nèi)存的申請(qǐng)釋放情況。監(jiān)測(cè)鏈表的維護(hù)與自旋鎖監(jiān)測(cè)鏈表類似，若監(jiān)測(cè)到當(dāng)前進(jìn)程在退出操作后存在未釋放的內(nèi)存時(shí)，說(shuō)明當(dāng)前進(jìn)程出現(xiàn)了內(nèi)存泄露故障，此時(shí)向系統(tǒng)日志輸出相應(yīng)的故障信息。

3.4 監(jiān)測(cè)結(jié)果顯示

關(guān)鍵方法監(jiān)測(cè)模塊以內(nèi)核模塊的形式根據(jù)監(jiān)測(cè)需求動(dòng)態(tài)加載到操作系統(tǒng)中在內(nèi)核態(tài)運(yùn)行，其監(jiān)測(cè)信息會(huì)輸出到系統(tǒng)日志文件中，用戶態(tài)的顯示程序會(huì)以固定的時(shí)間間隔讀取日志文件中的信息，進(jìn)行解析并顯示在程序界面中，如圖3中所示，從界面顯示框中用戶可以獲取內(nèi)核中每個(gè)進(jìn)程申請(qǐng)釋放鎖和內(nèi)存的信息，如288號(hào)進(jìn)程獲取了地址為f4a881eb的自旋鎖，根據(jù)3.2節(jié)和3.3節(jié)中描述的監(jiān)測(cè)規(guī)則若監(jiān)測(cè)到當(dāng)前系統(tǒng)中出現(xiàn)故障，顯示模塊會(huì)從系統(tǒng)日志文件中讀取相應(yīng)信息并顯示。

表1 自旋鎖相關(guān)操作監(jiān)測(cè)方法列表

表2 內(nèi)核動(dòng)態(tài)內(nèi)存分配相關(guān)操作監(jiān)測(cè)方法列表

圖3 監(jiān)測(cè)結(jié)果顯示界面

4 實(shí)驗(yàn)結(jié)果及分析

本文中采用故障注入實(shí)驗(yàn)的方法對(duì)故障監(jiān)測(cè)器的有效性從故障監(jiān)測(cè)率、誤報(bào)率、系統(tǒng)的負(fù)載以及故障監(jiān)測(cè)延時(shí)等方面進(jìn)行分析驗(yàn)證。實(shí)驗(yàn)計(jì)算機(jī)配置為AMD速龍II雙核 P360（2.3 GHz雙核），2.0 GB內(nèi)存，500 GB硬盤，內(nèi)核版本為L(zhǎng)inux 3.5。為了模擬系統(tǒng)真實(shí)的運(yùn)行環(huán)境，在進(jìn)行故障注入實(shí)驗(yàn)時(shí)選取了Unixbench 5.1.2測(cè)評(píng)集模擬系統(tǒng)運(yùn)行負(fù)載，選用了多個(gè)負(fù)載測(cè)試集以保證對(duì)內(nèi)核關(guān)鍵方法調(diào)用的覆蓋率。故障庫(kù)以內(nèi)核模塊的形式實(shí)現(xiàn)，在負(fù)載執(zhí)行流中以一定的時(shí)間間隔動(dòng)態(tài)加載到內(nèi)核運(yùn)行，并記錄監(jiān)測(cè)到的故障總數(shù)，通過(guò)系統(tǒng)在加載故障監(jiān)測(cè)器加載前后的Unixbench在各個(gè)負(fù)載集下的系統(tǒng)評(píng)分，可以對(duì)故障監(jiān)測(cè)器對(duì)系統(tǒng)造成的負(fù)載做出評(píng)估。

故障注入實(shí)驗(yàn)的故障庫(kù)包含資源競(jìng)爭(zhēng)（鎖的不恰當(dāng)使用如重復(fù)獲取同一個(gè)鎖、程序退出時(shí)不釋放占用的資源）和內(nèi)存泄露故障，分別選取context1、dhry、fstime、shell8、pipe、spawn、syscall、excel等標(biāo)準(zhǔn)測(cè)試集作為負(fù)載，在其正常執(zhí)行流內(nèi)分別注入上述兩種類型的故障各50次，記錄每個(gè)負(fù)載執(zhí)行流在完成時(shí)監(jiān)測(cè)到的故障總數(shù)，結(jié)果如圖4所示，從結(jié)果中可知，監(jiān)測(cè)器對(duì)79.25%的故障進(jìn)行有效監(jiān)測(cè)，但在shell8和execl負(fù)載流的執(zhí)行上下文中不允許進(jìn)行中斷操作，否則會(huì)導(dǎo)致內(nèi)核中數(shù)據(jù)不一致問(wèn)題，甚至出現(xiàn)oops現(xiàn)象，而本文中設(shè)計(jì)的監(jiān)測(cè)技術(shù)則需要利用中斷產(chǎn)生斷點(diǎn)進(jìn)行信息采集，因此監(jiān)測(cè)器在此時(shí)無(wú)法對(duì)內(nèi)存泄露類故障進(jìn)行有效的監(jiān)測(cè)。在shell8和spawn負(fù)載中會(huì)產(chǎn)生大量并發(fā)進(jìn)程并分配到兩個(gè)CPU核上并發(fā)執(zhí)行，由于每次創(chuàng)建進(jìn)程退出進(jìn)程操作都會(huì)執(zhí)行斷點(diǎn)處理程序，在短時(shí)間內(nèi)會(huì)觸發(fā)大量中斷，kprobe斷點(diǎn)機(jī)制在執(zhí)行斷點(diǎn)處理程序之前會(huì)產(chǎn)生int3和debug中斷，在本實(shí)驗(yàn)中會(huì)導(dǎo)致系統(tǒng)死機(jī)，因此在spawn和shell8負(fù)載流下對(duì)資源競(jìng)爭(zhēng)類錯(cuò)誤的監(jiān)測(cè)效果較差。

圖4 故障注入實(shí)驗(yàn)結(jié)果

在context1負(fù)載集下進(jìn)行內(nèi)存泄露故障監(jiān)測(cè)時(shí)，監(jiān)測(cè)到的故障總數(shù)超過(guò)了50次，雖然可能是由于操作系統(tǒng)中存在內(nèi)存泄露故障造成的，但本文中將監(jiān)測(cè)到的非人為注入的故障視為誤報(bào)，實(shí)驗(yàn)結(jié)果表明監(jiān)測(cè)器在監(jiān)測(cè)到的636次故障中僅存在兩次誤報(bào)。

監(jiān)測(cè)器對(duì)整體系統(tǒng)的負(fù)載主要是由于在內(nèi)核中產(chǎn)生中斷采集監(jiān)測(cè)信息以及對(duì)監(jiān)測(cè)隊(duì)列數(shù)據(jù)的維護(hù)造成的，Unixbench可以給出的在不同負(fù)載流下實(shí)驗(yàn)計(jì)算機(jī)在加載故障監(jiān)測(cè)器前后的評(píng)分值，根據(jù)評(píng)分值可計(jì)算出監(jiān)測(cè)器加載后系統(tǒng)性能下降了0.59%，故障監(jiān)測(cè)器對(duì)系統(tǒng)造成的負(fù)載較小，具體評(píng)分值如圖5所示。

圖5 監(jiān)測(cè)器負(fù)載分析結(jié)果

基于系統(tǒng)性能指標(biāo)的故障監(jiān)測(cè)技術(shù)中數(shù)據(jù)采樣周期的設(shè)置會(huì)直接影響到故障監(jiān)測(cè)延時(shí)，對(duì)該類型故障監(jiān)測(cè)器進(jìn)行故障監(jiān)測(cè)延時(shí)評(píng)估的時(shí)候往往通過(guò)設(shè)置不同的監(jiān)測(cè)周期來(lái)進(jìn)行實(shí)驗(yàn)，研究[15]中提出的基于貝葉斯模型的進(jìn)程級(jí)故障監(jiān)測(cè)器在FDP和SWIMBOX兩類負(fù)載下的故障監(jiān)測(cè)延時(shí)分別為（100.26±136.76）ms和（100±33.33）ms；基于系統(tǒng)I/O吞吐量進(jìn)行故障監(jiān)器[16]僅使用了I/O吞吐量這一個(gè)性能指標(biāo)，且沒(méi)有復(fù)雜的故障判別模型，對(duì)于不同類型的故障監(jiān)測(cè)延時(shí)差別較大，對(duì)于某些故障可能在很長(zhǎng)的時(shí)間內(nèi)無(wú)法進(jìn)行有效的監(jiān)測(cè)。

表3 基于時(shí)間的故障監(jiān)測(cè)技術(shù)監(jiān)測(cè)延時(shí)

基于時(shí)間的故障監(jiān)測(cè)技術(shù)大都需要增加額外的硬件或者軟件機(jī)制支持定時(shí)機(jī)制，帶來(lái)了與具體進(jìn)程或者系統(tǒng)的通信開(kāi)銷，根據(jù)在使用管道、Socket、無(wú)線網(wǎng)絡(luò)三種通信方法[8]時(shí)其延時(shí)監(jiān)測(cè)結(jié)果如表3中所示。

本文中提出的監(jiān)測(cè)機(jī)制以內(nèi)核模塊的形式實(shí)現(xiàn)，可以動(dòng)態(tài)地加載到內(nèi)核中運(yùn)行，采用中斷的方式進(jìn)行數(shù)據(jù)記錄和分析，減少了與特定進(jìn)程或者硬件進(jìn)行通信的開(kāi)銷，故障監(jiān)測(cè)延時(shí)實(shí)驗(yàn)結(jié)果如圖6所示，從圖中數(shù)據(jù)可知，監(jiān)測(cè)的延時(shí)明顯小于基于時(shí)間和系統(tǒng)指標(biāo)的監(jiān)測(cè)技術(shù)。由于對(duì)故障數(shù)據(jù)的采集和監(jiān)測(cè)是通過(guò)中斷方式實(shí)現(xiàn)，監(jiān)測(cè)的延時(shí)不會(huì)受到監(jiān)測(cè)器具體配置的影響如性能指標(biāo)采樣周期等。

圖6 監(jiān)測(cè)器故障監(jiān)測(cè)延時(shí)實(shí)驗(yàn)結(jié)果

此外從實(shí)驗(yàn)結(jié)果中可以看出，對(duì)資源競(jìng)爭(zhēng)類故障的監(jiān)測(cè)延時(shí)要明顯小于對(duì)內(nèi)存泄露類故障的監(jiān)測(cè)延時(shí)，這是由于資源競(jìng)爭(zhēng)類故障往往和操作系統(tǒng)內(nèi)的臨界區(qū)相關(guān)，為了提高系統(tǒng)的整體運(yùn)行效率臨界區(qū)執(zhí)行時(shí)間一般很短暫，且和多核中斷搶占上下文相關(guān)，因此可在臨界區(qū)執(zhí)行結(jié)束退出時(shí)較快地偵測(cè)到故障，而對(duì)于內(nèi)存泄露類的故障，由于其分配內(nèi)存往往存在延時(shí)且可能導(dǎo)致該進(jìn)程睡眠，因此對(duì)于此類故障監(jiān)測(cè)的延時(shí)要長(zhǎng)于資源競(jìng)爭(zhēng)類故障。

5 結(jié)論

故障監(jiān)測(cè)技術(shù)為自愈操作系統(tǒng)提供對(duì)故障的自主感知能力，是故障診斷和恢復(fù)的基礎(chǔ)，根據(jù)已有的操作系統(tǒng)故障分布研究成果，本文提出了一種基于動(dòng)態(tài)追蹤的故障監(jiān)測(cè)技術(shù)，通過(guò)三類監(jiān)測(cè)點(diǎn)的插入可以有效地監(jiān)測(cè)內(nèi)核中動(dòng)態(tài)內(nèi)存分配和資源競(jìng)爭(zhēng)相關(guān)的故障，并通過(guò)錯(cuò)誤注入實(shí)驗(yàn)驗(yàn)證了該技術(shù)的可行性，實(shí)現(xiàn)的故障監(jiān)測(cè)器可以在較低系統(tǒng)負(fù)載的條件下對(duì)注入的故障進(jìn)行有效的監(jiān)測(cè)，且故障誤報(bào)率很低，監(jiān)測(cè)延時(shí)較已有的基于時(shí)間和系統(tǒng)性能指標(biāo)的監(jiān)測(cè)技術(shù)明顯降低。

[1]Barbosa R.Layered fault tolerance for distributed embedded systems[M].[S.l.]：Chalmers University of Technology，2008.

[2]Schneider C，Barker A，Dobson S.A survey of self-healing systems frameworks[J].Software：Practice and Experience，2014.

[3]Hamann P S，Perry R L.Compensation recommendations，US patent 20，140，032，382[P].2014.

[4]Asghari S A，Kaynak O，Taheri H.An investigation into soft error detection efficiency at operating system level[J].The Scientific World Journal，2014.

[5]Abaffy J，Krajcovic T.Software support for multiple hardware watchdog timers in the linux OS[J].Applied Electronics，2010：17-19.

[6]David F M，Campbell R H.Building a self-healing operating system[C]//Third IEEE International Symposium on Dependable，Autonomic and Secure Computing，2007：3-10.

[7]Zhu Y，Li Y，Xue J，et al.What is system hang and how to handle it[C]//Software Reliability Engineering（ISSRE）.

[8]Abaffy J，Kraj?ovi? T.Multiple software watchdog timers in the linux OS[M]//Emerging Trends in Computing，Informatics，Systems Sciences，and Engineering.[S.l.]：Springer，2013：759-765.

[9]Palix N，Thomas G，Saha S，et al.Faults in Linux：ten years later[C]//ACM SIGARCH Computer Architecture News，ACM，2011：305-318.

[10]Chou A，Yang J，Chelf B，et al.An empirical study of operating systems errors[Z].ACM，2001.

[11]Lisong L，Peter P，Tschudin S，et al.Oops!What about a Million Kernel Oopses?RT-0436[R].2013.

[12]Deshpande B D.System and methods for self-healing from operating system faults in kernel/supervisory mode，US Patent 20，140，032，962[P].2014.

[13]Saha S，Lozi J P，Thomas G，et al.Hector：detecting resource-release omission faults in error-handling code for systems software[C]//43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks.IEEE，2013：1-12.

[14]Kheradmand A，Kasikci B，Candea G.Lockout：efficient testing for deadlock bugs[R].2014.

[15]Bovenzi A，Cinque M，Cotroneo D，et al.OS-level hang detection in complex software systems[J].International Journal of Critical Computer-Based Systems，2011，2：352-377.

[16]Cotroneo D，Natella R，Russo S.Assessment and improvement of hang detection in the Linux operating system[C]//Reliable Distributed Systems，2009：288-294.