在本站的采訪中，Mark Wilding和Dan Behman對于Linux系統(tǒng)沖突問題的預(yù)防及修復(fù)提供了一種比較簡捷明了的方法。他們兩人共同出版了一本新書——《Self-Service Linux: Mastering the Art of Problem Determination》。
一般認(rèn)為，Linux服務(wù)器系統(tǒng)是不存在沖突的，然而些許時候該系統(tǒng)的沖突、停滯問題的確存在。對于應(yīng)用軟件層面的沖突或者停滯問題，與內(nèi)核層面有何不同呢?
Mark Wilding: 應(yīng)用軟件層面的沖突或者停滯問題只是限制于一個特定的線程或者進(jìn)程。這種沖突或者停滯問題不會導(dǎo)致在該相同系統(tǒng)上運(yùn)行的其他線程或者進(jìn)程的沖突或者停滯。然而，如果是在內(nèi)核層面上發(fā)生，那么它將影響到該系統(tǒng)中運(yùn)行的所有進(jìn)程。
系統(tǒng)的沖突和停滯，這二者有什么區(qū)別呢?
Dan Behman: 在任何一個層面，沖突和停滯這二者的屬性基本上是相同的。停滯發(fā)生在進(jìn)程或線程受阻的時候，此時是由于某種鎖定或者某些硬件資源的繁忙，從而該進(jìn)程或線程不得不等待。等待某些鎖定或資源的情況是經(jīng)常發(fā)生的，但是只有當(dāng)這種鎖定或者資源終無法實(shí)現(xiàn)的時候，才會引起系統(tǒng)停滯。
還有很重要的一點(diǎn)需要注意的是，停滯問題有時候可以提早的診斷出來。我的意思是，例如，某種資源的某個特定的時刻非常的繁忙，這是需要這種資源的進(jìn)程或線程就需要等待非常長的一段時間，直至該資源空閑下來。用戶經(jīng)常不了解資源的這種繁忙狀況，而只看到該進(jìn)程在等待，所以他就認(rèn)為系統(tǒng)發(fā)生了停滯，但實(shí)際上此時系統(tǒng)仍然在按照既定的工作流程進(jìn)行，只是速度比較慢。
而系統(tǒng)的沖突問題與上述的停滯是不同的，它主要是由于某種不可知的硬件或軟件錯誤而導(dǎo)致的。當(dāng)這種錯誤發(fā)生時，特殊的錯誤處理程序?qū)⒑芸赡軙{(diào)用那些診斷信息及報告，從而有希望能夠追蹤到這種錯誤的原因。
沖突問題可以看作是某種致命的問題，它需要完結(jié)后才能夠進(jìn)行分析。而停滯問題可以看作是實(shí)時的問題，它可以即時的進(jìn)行分析、解決。
我知道Linux有一個的優(yōu)勢就是在于它的源代碼的開放性;除此之外，還有別的原因致使Linux比其他操作系統(tǒng)的沖突問題容易解決嗎?
Behman: 伴隨著這種源代碼的開放性，在Linux系統(tǒng)的每一個層面都有著相當(dāng)多的參閱文件。同時，既然源代碼是開放的，那么它的開發(fā)團(tuán)隊(duì)也同樣是開放的。這樣以來，你就可以把所遇到的問題向Linux內(nèi)核的開發(fā)者求助，當(dāng)然包括初的那些開發(fā)人員，甚至Linus Torvalds本人，而這所有的求助程序也僅僅是發(fā)送一封電子郵件就可以了。而據(jù)我所知，Linux的這種能力是那些不開放源碼的操作系統(tǒng)所缺少的。
處理停滯問題有那些困難和挑戰(zhàn)呢?
Wilding: 一個應(yīng)用軟件的停滯問題是有著多種原因的，也包括那些可能由于內(nèi)核空間的問題所引起的停滯。這意味著有時候這些問題不是開發(fā)者所能夠控制的。但是這正是Linux的優(yōu)勢所在。所有的源代碼都是開放的，所以如果你遇到了某種進(jìn)程的內(nèi)核阻滯狀況，那么就可以聯(lián)系其源代碼，從而查看該進(jìn)程在內(nèi)核中是如何作用的。然而，在大部分情況下，是沒有必要進(jìn)行這么深層次研究的。為了探究進(jìn)程停滯的原因到底何在?應(yīng)用軟件的開發(fā)者需要認(rèn)真的研究這些軟件層面的狀況及證據(jù)(例如，堆棧的路徑等)。
對于用戶或者維護(hù)人員而言，他們一般不會了解應(yīng)用軟件的具體工作程序，也不會沒有能力進(jìn)入到源代碼層面進(jìn)行測試，這是遇到系統(tǒng)停滯問題可以靈活的進(jìn)行處理。例如，在某種情況下，進(jìn)程A在等待進(jìn)程B結(jié)束后所釋放的資源，而進(jìn)程B又在等待進(jìn)程A占有的資源。這就是所謂的“死鎖”，這也正是復(fù)雜應(yīng)用軟件中經(jīng)常出現(xiàn)的問題，可以作為停滯問題的一種診斷方案。
如果你不清楚進(jìn)程A及進(jìn)程B的具體等待原因，那么你甚至不需要明白這到底是不是“死鎖”的情況，而別無選擇的關(guān)掉這兩個進(jìn)程后重新開啟。正是這種類似情況，因此對于應(yīng)用軟件而言，進(jìn)行完全的資源及上鎖情況的跟蹤是十分重要的，這可以幫助解決這種比較棘手的問題。
Behman: 關(guān)于停滯問題的另一個挑戰(zhàn)在于，當(dāng)停滯問題發(fā)生時，進(jìn)程或者線程經(jīng)常不知道它被停滯了或者何時將被停滯。這種情況和沖突問題是不同的，當(dāng)沖突問題發(fā)生時，進(jìn)程可以截取大部分的信號，并且信號處理程序可以添加到平臺系統(tǒng)中來處理這些特殊情況，例如清理內(nèi)存，堆棧跟蹤等等。但是，當(dāng)停滯問題發(fā)生時，這種特殊的處理程序雖然不是完全不可能進(jìn)行，但是往往比較靈活，不太固定。
停滯問題發(fā)生時，往往去重新啟動該系統(tǒng)或者應(yīng)用軟件。有一點(diǎn)需要切記的是，發(fā)生停滯問題時，診斷該問題的一些資料和證據(jù)經(jīng)常被活動的內(nèi)核及應(yīng)用軟件所捕獲。如果你不收集這些重要的信息而立即重新啟動，那么你永遠(yuǎn)不知道如何去診斷這種問題，從而也就不可能阻止其將來的再次發(fā)生。
對于一些特殊重要的環(huán)境而言，系統(tǒng)的穩(wěn)定性及可靠性是與問題診斷及解決速度緊密相連。因此，需要堅持一種合理的思路，那就是“先收集錯誤信息，然后重新啟動”。
與沖突問題對比，當(dāng)遇到停滯問題時，首先要做的事情是什么呢?
Behman: 處理內(nèi)核層面的停滯問題與處理應(yīng)用軟件層面的停滯是有著很大不同的。
如果你問的是關(guān)于應(yīng)用軟件層面。當(dāng)沖突問題發(fā)生時，有著一種稱為“信號處理”的特殊功能來調(diào)用處理各種各樣的信息，例如內(nèi)存中的信息，堆棧的跟蹤反饋等。所以一般情況下，遇到?jīng)_突問題時，首要的問題就是收集、整理、分析這些數(shù)據(jù)。
而在停滯問題發(fā)生時，這種數(shù)據(jù)不會自動的收集，而這往往是一種人工的操作過程。收集停滯狀態(tài)數(shù)據(jù)的兩個關(guān)鍵點(diǎn)在于追蹤輸出結(jié)果以及堆棧的跟蹤反饋。這種追蹤輸出結(jié)果的方式能夠得出該進(jìn)程作用情況的信息，因?yàn)樗谝恢钡谋O(jiān)視該進(jìn)程;這些信息例如，該進(jìn)程是否仍然在作用等等。而堆棧的跟蹤反饋可以給出目前進(jìn)程作用的源代碼部分。這對于開發(fā)人員是非常重要的，這樣以來他們就可以研究該進(jìn)程停滯問題產(chǎn)生的原因。
對于沖突及停滯問題，其主要的原因是什么呢?
Wilding: 對于沖突問題而言，我們可以把它的主要原因分為兩種，一種是預(yù)防型的，另一種是錯誤處理型的。預(yù)防型沖突是內(nèi)核或應(yīng)用軟件由于遇到了嚴(yán)峻的形勢而產(chǎn)生沖突問題的情況。而軟件意識到這種問題，并產(chǎn)生一種“自殺式”的方法以阻止錯誤的進(jìn)一步發(fā)生，從而避免更加嚴(yán)重的問題出現(xiàn)。而對于錯誤處理型的沖突，它意味著內(nèi)存中有著某些不合法的內(nèi)容進(jìn)入，幾乎都是一些程序的錯誤。在這種情況下，硬件探測到這種應(yīng)用軟件，然后發(fā)送信號去阻止該軟件的進(jìn)程。
對于停滯問題而言，也一般存在著兩種原因狀況。一種是進(jìn)程或線程等待資源的情況，這不一定能否解決。而其他的進(jìn)程或線程約束著該資源(例如，上鎖)，這樣該進(jìn)程或線程在等待時，其還占據(jù)著資源，從而其他進(jìn)程或線程也只能等待。一個例子就是某個進(jìn)程對占據(jù)的重要資源上鎖，而其自身在漫無目的接收因特網(wǎng)的信息。第二中比較常見的原因就是一種“依賴回路式”的等待，在此兩個或者多個進(jìn)程在互相等待它方的資源，從而陷入“死鎖”。這種情況的解決方法可以是釋放一個鎖，或者在某個空間中共享內(nèi)存等。
在這些沖突以及停滯的情形之下，管理者們有哪些基本的調(diào)查研究規(guī)則可以應(yīng)用呢?
Wilding: 一個的基本準(zhǔn)則就是有組織的參加工作。很重要的一點(diǎn)就是把收集的數(shù)據(jù)有規(guī)則的放在一個明確的地點(diǎn)，這樣將來能夠很容易的找到。這對于那些同時遇到多個問題的情況尤為有用。
Behman: 另一個基本的準(zhǔn)則就是要定量的收集數(shù)據(jù)，而不是定性的收集數(shù)據(jù)。例如，“昨天晚上6點(diǎn)，系統(tǒng)內(nèi)存利用較低”，這是定性的觀測。這在問題處理中的作用不大。關(guān)于該例子的定量的版本應(yīng)該要收集并保存那些所有的輸出的數(shù)據(jù)命令，以及其他一些相關(guān)的診斷命令。目的就是在于收集足夠的數(shù)據(jù)，這樣就可以盡可能的避免問題的再次發(fā)生;這就是“一次到位式”的方法，而不需要問題重復(fù)出現(xiàn)后，多次收集才能夠得到比較完整的數(shù)據(jù)。