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

來源:互聯網
上載者:User

標籤:des   http   io   使用   ar   strong   檔案   2014   art   

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

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

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

 

5、用kdump工具核心故障定位執行個體

A) 部署Kdump

部署 kdump 收集故障資訊的步驟如下:

(1)設定好相關的核心啟動參數

在 /boot/grub/menu.lst 中加入如下內容

  1. crashkernel=[email protected] nmi_watchdog=1 

其中crashkernel參數是用來為kdump的核心預留記憶體的; nmi_watchdog=1 是用來啟用NMI中斷的, 我們在未確定故障是否關閉了中斷的情況下, 需要部署NMI watchdog才能確保觸發panic. 重啟系統確保設定生效

(2)設定好相關的sysctl核心參數

在/etc/sysctl.conf 中最後加入一行

  1. kernel.softlookup_panic = 1  

該設定確保softlock發生時會調用panic, 從而觸發kdump行為執行 #>sysctl -p 確保設定生效

(3)配置 /etc/kdump.conf

在 /etc/kdump.conf 中加入如下幾行內容

  1. ext3 /dev/sdb1  
  2. core-collector makedumpfile -c –message-level 7 -d 31 -i /mnt/vmcoreinfo  
  3. path /var/crash  
  4. default reboot 

其中 /dev/sdb1 是用於放置dumpfile 的檔案系統, dumpfile 檔案放置在/var/crash下, 要事先在/dev/sdb1分區下建立/var/crash 目錄. “-d 31”指定對dump內容的過濾層級,這參數對於dump分區放不下全部記憶體內容或使用者不想讓dumping中斷業務太長時間時很重要. vmcoreinfo 檔案放置在 /dev/sdb1 分區的 / 目錄下, 需要使用如下命令產生:

#>makedumpfile -g //vmcoreinfo -x /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux

“vmlinux” 檔案是由kernel-debuginfo 包提供的,在運行makedumpfile 之前需要安裝相應核心的 kernel-debuginfo 和 kernel-debuginfo-common 兩個包,該兩個包需從 http://ftp.redhat.com 下載. “default reboot” 用來告訴kdump, 收集完dump資訊後重啟系統

(4)啟用kdump

運行 #>service kdump start 命令,你會看到,在成功完成的情況下會在/boot/目錄下產生一個initrd-2.6.18-128.el5.x86_64kdump.img 檔案,該檔案就是kdump載入的核心的 initrd檔案,收集dump資訊的工作就是在該initrd的啟動環境下進行的. 查看/etc/init.d/kdump指令碼的代碼,你可看到其中會調用mkdumprd命令建立用於dump的initrd檔案

1、測試Kdump部署的有效性

為了測試kdump部署的有效性,本人寫了如下一個核心模組,通過insmod 載入該核心模組, 就能產生一個核心線程,在10秒左右後,佔據100%的CPU,在20秒左右後觸發kdump. 系統重啟後,檢查/oracle分區/var/crash 目錄下的內容,就能確認vmcore檔案是否產生.

  1. Zqfthread.c #include   
  2. #include   
  3. #include   
  4. #include   
  5. #include   
  6. #include   
  7.  
  8. MODULE_AUTHOR("[email protected]");   
  9. MODULE_DESCRIPTION("A module to test ....");   
  10. MODULE_LICENSE("GPL");   
  11.  
  12. static struct task_struct *zqf_thread;   
  13. static int zqfd_thread(void *data);   
  14.  
  15. static int zqfd_thread(void *data)   
  16. {   
  17. int i=0;   
  18.  
  19. while (!kthread_should_stop()) {   
  20. i++;   
  21. if ( i < 10 ) {   
  22. msleep_interruptible(1000);   
  23. printk("%d seconds\n", i);   
  24. }   
  25. if ( i == 1000 ) // Running in the kernel   
  26. i = 11 ;   
  27. }   
  28. return 0;   
  29. }   
  30. static int __init zqfinit(void)   
  31. {   
  32. struct task_struct *p;   
  33.  
  34. p = kthread_create(zqfd_thread, NULL,"%s","zqfd");   
  35.  
  36. if ( p ) {   
  37. zqf_thread = p;   
  38. wake_up_process(zqf_thread); // actually start it up   
  39. return(0);   
  40. }   
  41.  
  42. return(-1);   
  43. }   
  44.  
  45. static void __exit zqffini(void)   
  46. {   
  47. kthread_stop(zqf_thread);   
  48. }   
  49.  
  50. module_init(zqfinit);   
  51. module_exit(zqffini)  
  52.  
  53. Makefile obj-m += zqfthread.o  
  54. Making #> make -C /usr/src/kernels/2.6.32-71.el6.x86_64/ M=`pwd` modules 

2、用crash 工具分析vmcore 檔案

用crash 命令分析vmcore 的命令列格式如下所示. 用crash開啟vmcore後,主要是用dmesg及 bt 命令列印出問題的執行路徑的call trace, 用dis 反組譯碼出代碼,最終確認call trace對應的C源碼中的位置,再進行邏輯分析.

  1. #>crash /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux /boot/System.map-2.6.18-128.el5.x86_64 ./vmcore 

 

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

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。