現象：Linux系統卡慢甚至卡死的現象
問題定位：
首先查看系統版本，雖然對于解決此問題沒有太大作用，但是方便自己向公司同事或領導報告此事，總得是要有系統版本的
如果是自己公司的作業系統，那么查看系統版本可能有專門的命令，比如我們公司的Kylin作業系統查看系統版本使用：
cat /etc/.productinfo
一、接下來了解當前系統正在運行使用的應用大概都有哪些，如果系統桌面已經卡死，無法看到運行的應用，可以終端ssh連接上此電腦，（如果ssh都已經連接不上了，要么是sshd服務也調不起來了，要么是此電腦與其他電腦的網本來就不通，可以嘗試ctrl+alt+F2切到字符終端，在字符終端查看行程等）
先使用top實時查看一下行程占cpu以及記憶體的情況，因為top是實時重繪的，比較直觀
但與此同時，top也有弊端，當行程占資源變化比較快的時候，行程跳來跳去，不方便確認行程名稱，所以這個時候用ps命令
使用ps -aux可以查看哪些行程占cpu或者記憶體較高，如果有的行程的值不是特別確定是否正常，可以在其他電腦同環境的情況下也查看一下做一下對比，如果有行程占cpu或記憶體的比例特別高，且居高不下，基本就可以確定是該行程卡死了，如果需要急切恢復，可以kill -9殺行程來恢復，
因為排查到這里只是排查出來是哪一個行程，但這個行程可能是某個服務的子行程，系統環境下如果裝了好多的軟體，那就需要確定這個行程屬于哪個軟體應用的，如果需要查看到底哪個應用出了問題，就需要根據之前查出來的例外行程進一步查，可以通過行程ID一點點查看父行程，直到追溯到其應用行程名，此程序中，如果發現應用名已基本顯示出來了，繼續往上追溯，很有可能查出來父行程是系統本身的行程，比如systemd行程，查到類似于這樣的地方的時候其實已經追溯“過頭了”，
根據行程ID往上追溯父行程的方式是：
1、確定了某一個例外行程之后，根據那個行程的ID，使用
ps -ef | grep 行程ID
然后會顯示出來該行程對應的父行程（PPID）
2、中間往上追溯的程序是一樣的，但是要注意判別是否到臨界
至此是卡死時能夠切換到終端輸命令時的排查手段，但有的時候現實情況并非如此，有可能當時電腦卡死時，sshd服務調不起來導致沒辦法另找一臺電腦ssh連過去查資訊，也有可能與此同時，ctrl+alt+F2切字符終端的時候也切不過去了，這個時候有兩種可能，一種是系統卡的死死的，一種是硬體出問題了，比如硬碟故障了，檔案系統直接不作業了，在以上情況下，在保留現狀的情況下基本沒有什么好排查的了，能做的就是檢查一下硬體狀態，比如硬碟燈亮不亮，以及畫面最后停留在什么情況下，方便判斷死機前大概都做了哪些操作，
在這里需要提醒一下的是
1、在到現場排查問題之前，盡量不要讓用戶輕易恢復故障現場，現象還在的時候比較好排查問題，但是系統一重啟可能就不太好查了，因為重啟能解決99%的問題，但是重啟后卡死現象可能就不出現了，那么想要判斷之前死機的原因可能就不太好查，畢竟日志能記錄的例外資訊是有限的
2、卡死之前客戶都做了哪些操作這是必須要問的，因為如果之后確實沒有通過日志排查出來哪里出了問題，那也基本可以從用戶那里獲得一些資訊，方便自己對某些可能出現此現象的原因做一個大致的判斷
二、接下來說一下在完全卡死，不能切終端，也不能ssh進去的時候怎么辦
此時，保留的故障現場已經基本沒什么好查的了，因為命令什么的都用不了，接下來再把問題記錄清楚然后重啟恢復現狀，開始排查日志，看能不能獲得有用的資訊
1、首先是messages日志，/var/log目錄下，messages日志記錄的資訊是比較全的，所以一般先排查這個，
用vim編輯器打開后，可以先搜索Runtime journal，定位一下卡死之前系統什么時間開機的，messages日志資訊里的各種資訊都有，可以搜最左側的時間，快速定位發生故障時的那段時間的日志，也可以通過關鍵字“failed” “error”“false”等搜索一下看有沒有錯誤日志，如果有一些稀奇古怪的日志不要緊，有的可能是軟體應用運行時的正常日志資訊，如果確定不了那段日志里的資訊到底算不算一種例外，那么可以找其他電腦做對比
2、其次是服務日志（這個是確定了哪個應用的問題時查這個），一般在/var/log底下也會有那些應用對應的日志資訊，日志名可能跟軟體名或軟體對應的行程名差不多，當然也不排除有的軟體做的日志資訊不往messages里寫，也不保存在/var/log下，有可能是在軟體安裝的路徑或者其他相關路徑下
3、dmesg日志，該日志是記錄系統最近一次開機時加載的驅動資訊，以及開機后鍵鼠等硬體的一些回應資訊，查看該日志可以看一下有沒有什么報錯之類的
4、Xorg.0.log日志，該日志是記錄的圖形化服務相關的一些日志資訊，看一下圖形化服務方面有什么例外沒
5、lightdm.log日志，該日志是和登錄界面相關的一些日志資訊，如果系統卡死的時候是在用戶登錄界面的時候卡死了，這個日志就有必要也看一眼
6、.xsession-errors日志，該日志在用戶家目錄下（root用戶的是在/root下，普通用戶是在/home/username/下），是隱藏檔案，該日志資訊是某用戶環境下的圖形化日志資訊
如果日志里沒什么例外資訊，但是系統確實是完全卡死了，那有可能硬體出問題了，比如硬碟故障了，檔案系統直接崩了，也有可能是其他硬體故障，這個時候就需要叫上硬體廠商一起來看這個問題了
現場的問題如果通過自己的排查手段暫時沒有排查出來，需要請大佬進一步排查，那么需要記得保存現場的日志資訊，記錄出問題的時間點
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/171670.html
標籤：python