紅帽Linux故障定位技術詳解與執行個體(2)

標籤：http   os   io   使用   ar   strong   檔案   資料   2014   

紅帽Linux故障定位技術詳解與執行個體(2)2011-09-28 14:26 圈兒 BEAREYES.COM 我要評論(0) 字型大小：T | T

線上故障定位就是在故障發生時, 故障所處的作業系統環境仍然可以訪問，故障處理人員可通過console, ssh等方式登入到作業系統上，在shell上執行各種操作命令或測試程式的方式對故障環境進行觀察，分析，測試，以定位出故障發生的原因。

AD：2014WOT全球軟體技術峰會北京站 課程視頻發布

 

3、核心故障情形及處理

（1）核心panic

panic是核心最直接的故障定位報告，發生panic時，核心已經認為故障定位已經導致作業系統不再具備正常啟動並執行條件了. 當發生panic時，Linux會將所有CPU的中斷和進程調度功能都關掉，所以這時系統是沒有任何反應的，如果使用者啟動的是圖形介面，則在螢幕上也看不到任何關於panic的資訊.

我們通常遇到的，機器沒反應，ping不通的情況，絕大部分都是panic. Panic發生時，核心直接在console上列印導致panic的代碼位置的呼叫堆疊, 傳統的使用者用串口串連到機器上來收集console上的列印資訊, 但串口這種方式，顯然用起來不方便, 現在的Linux, 如RHEL5,RHEL6， 都採用kdump的方法來收集panic時的資訊. 在配置好kdump的情況下，panic時系統會用kexec載入並切換到一個新的核心上(放置在預先分配的記憶體位置)，並用磁碟或網路等將系統的全部或部分記憶體資料儲存起來.

用kdump收集到panic的資料後，使用者用crash工具就能直接查看導致panic的代碼路徑.

panic一般是很直觀的，panic的堆棧資訊能直接反映出導致bug的原因，如MCE故障，NMI故障, 資料結構分配失敗等. 但有時panic是因為核心主動發現了關鍵的資料結構不一致性，這種不一致性是什麼時候，什麼代碼導致的，並不清楚，可能還需要多次測試用SystemTap這樣的工具進行捕捉

（2）多處理機環境核心執行路徑產生的死結

核心死結和panic不一樣，產生死結時，核心並不主動的使自己處於掛起狀態. 但核心死結發生時，兩個以上的CPU的執行路徑在核心態不能推進了，處於互相阻塞狀態, 而且是100%的佔用CPU(用的spin-lock)，直接或間接的導致全部CPU上的進程無法調度. 核心死結又分兩種情況:

- 涉及到中斷內容相關的死結. 這種情況的死結，最少一個CPU上的中斷被屏蔽了.系統可能沒法響應ping請求. 由於有一個CPU已經沒法響應中斷，其上的local APIC定時中斷沒法工作，可以用NMI Watchdog的方法來檢測出來(檢查local APIC handler維護的計數器變數)，NMI Watchdog可以在其處理常式中調用panic(), 使用者就可以用kdump收集記憶體資訊，從而分析各死結CPU上的呼叫堆疊，查處導致死結的邏輯原因.

- 不涉及中斷內容相關的死結. 這種情況的死結，各CPU上的中斷都是正常的，系統能對ping請求作出反應，這時NMI Watchdog無法被觸發. 在 2.6.16之前的核心中,並沒有一種很好的方法來處理這種情形. 在RHEL5, RHEL6 核心中， 每個CPU上提供了一個watchdog核心線程，在死結出現的情況下，死結CPU上的watchdog核心線程沒法被調度(即使它是最高優先順序的即時進程),它就沒法update相應的counter變數，各CPU的NMI Watchdog中斷會周期性的檢查其CPU對應的counter, 發現沒有updated, 會調用panic()，使用者就可用kdump收集記憶體資訊，分析各死結CPU上的呼叫堆疊，查處導致死結的邏輯原因.

（3）核心的oops或warning

oops 和warning和panic類似的地方是，他們都是因核心發現了不一致而主動報告的異常. 但oops和warning導致的問題嚴重程度要比panic輕很多，以致於核心處理該問題時不需要使系統掛起. 產生oops和warning, 核心通常已經在dmesg中記錄了相當的資訊，特別是oops, 至少會列印出現故障的地方的call trace. Oops也可轉換成panic/kdump來進行offline-debugging, 只要將/proc/sys/kernel下的panic_on_oops變數設定為1就行了.

產生oops和warning的直接原因有很多，如核心中的segment fault, 或核心發現的某資料結構的counter值不對, 而segment fault 和counter值的變化還有更深層次的原因，通常並不能從核心dmesg的資訊中看出來，解決這種問題的是要用SystemTap進行probe, 如發現某counter的值不對，就用SystemTap做一個probe來記錄所有代碼對該counter的訪問, 然後再進行分析.

定位oops和warning會比定位應用程式的記憶體訪問故障定位困難很多，因為在核心並不能象用valgrind去trace應用程式一樣跟蹤資料結構的分配和使用方式.

2、其他(硬體相關)故障

機器自動重啟是一種常見的故障情形，一般是由硬體如實體記憶體故障引起的，軟體的故障只會導致死結或panic, 核心中幾乎沒有代碼在發現問題的情況下去reboot機器. 在/proc/sys/kernel目錄下有個參數“panic”, 其值如果設定為非0，則在panic發生若干秒後，核心會重啟機器. 現在高端的PC伺服器，都在努力用軟體來處理實體記憶體故障，如MCA的 “HWPoison”方法會將故障的物理頁隔離起來，Kill掉故障頁所在的進程就可以了，RHEL6現在已經支援 “HWPoison”. 那些不具備MCA能力的機器，實體記憶體故障時，不會產生MCE異常，直接由硬體機制reboot機器

4、RHEL6 上的Debugging技術介紹

（1）Kdump故障定位收集和crash分析

kdump就是用來在核心panic的情況下收集系統記憶體資訊的, 使用者也可在online情況下用sysrq的‘c‘鍵觸發. Kdump 採用沒有汙染的核心來執行dump工作，所以其比以前的diskdump, lkcd方法更可靠. 使用kdump，使用者可選擇將資料dump到本地碟或網路上，也可通過定義makedumpfile的參數過濾要收集的記憶體資訊，已減少kdump所需要的停機時間

Crash就是對kdump的資訊進行分析的工具.其實際就是gdb的一個wrapper. 使用crash時，最好安裝kernel-debuginfo包，這樣能解析kdump收集的核心資料的符號資訊. 用crash來定位問題的能力，完全取決於使用者對核心代碼的理解和分析能力

參考 “#>man kdump.conf”, “#>man crash”, “#>man makedumpfile”學習怎樣使用kdump和crash. 訪問 http://ftp.redhat.com可下載debuginfo檔案

（2）用systemTap定位bug

systemtap 屬於probe類的定位工具,它能對核心或使用者代碼的指定位置進行probe, 當執行到指定位置或訪問指定位置的資料時，使用者定義的probe函數自動執行，可列印出該位置的呼叫堆疊，參數值，變數值等資訊. systemtap選擇進行probe的位置很靈活，這是systemtap的強大功能所在. Systemtap的probe點可包括如下幾個方面:

- 核心中全部系統調用，核心及模組中全部函數的入口或出口點

- 自訂的定時器probe點

- 核心中任意指定的代碼或資料訪問位置

- 特定使用者進程中任意制定的代碼或資料訪問位置

- 各個功能子系統預先設定的若干probe點，如tcp,udp,nfs,signal各子系統都預先設定了很多探測點

systemTap的指令碼用stap指令碼語言來編寫，指令碼代碼中調用stap提供的API進行統計，列印資料等工作，關於stap語言提供的API函數，參考 “#> man stapfuncs”. 關於systemTap的功能和使用可參考 “#> man stap”, “#> man stapprobes”

（3）ftrace

ftrace 是linux核心中利用tracepoints基礎設施實現的事件追蹤機制，它的作用在於能比較清楚的給出在一定時間內系統或進程所執行的活動，如函數調用路徑，進程切換流等. Ftrace可用於觀察系統各部分的latency,以便進行即時應用的最佳化； 它也可以通過記錄一段時間內的核心活動來協助故障定位. 如用以下方法可trace某個進程在一端時間的函數調用情況

1. #> echo “function” > /sys/kernel/debug/tracing/current_tracer  
2. #> echo “xxx” > /sys/kernel/debug/tracing/set_ftrace_pid  
3. #> echo 1 > /sys/kernel/debug/tracing/tracing_enabled 

除tracing函數調用外，ftrace還可tracing系統的進程切換，喚醒，塊裝置訪問，核心資料結構分配等活動. 注意，tracing和profile是不同的，tracing記錄的是一段時間內的全部活動，而不是統計資訊，使用者可以通過/sys/kernel/debug/tracing下的buffer_size_kb設定緩衝區的大小, 以記錄更長時間的資料.

關於ftrace的具體使用可參考核心源碼Documenation/trace下的內容

（4）oprofile 和 perf

oprofile和perf都是對系統進行profile(抽樣，統計)的工具，它們主要用來解決系統和應用的效能問題. perf功能更強大，更全面,同時perf的使用者空間工具和核心源碼一起維護和發布，讓使用者能及時的享受perf核心新增加的特徵. Perf 是在RHEL6中才有，RHEL5中沒有Perf. Oprofile和perf 都使用現代CPU中具有的硬體計數器進行統計工作，但perf還可以使用核心中定義的 “software counter”及 “trace points”, 所以能做更多的工作. Oprofile的抽樣工作利用 CPU的NMI中斷來進行，而perf既可以利用NMI中斷也可利用硬體計數器提供的周期性中斷. 使用者能很容易用perf來oprofile一個進程或系統的執行時間分布，如

1. #> perf top -f 1000 -p  

還可以利用系統定義的 “software counter”和各子系統的 “trace points” 對子系統進行分析, 如

1. #>perf stat -a -e kmem:mm_page_alloc -e kmem:mm_page_free_direct -e kmem:mm_pagevec_free sleep 6 

能統計6秒內kmem子系統的活動 (這一點實際是利用ftrace提供的tracepoints來實現)

我認為有了perf, 使用者就沒必要使用oprofile了

 

 

紅帽Linux故障定位技術詳解與執行個體(2)