Linux 服務器故障排除的前五分鐘 (First 5 Minutes Troubleshooting A Linux Server)

出自 http://freeloda.blog.51cto.com/2033581/1346789php


1、前言html

2、簡介前端

3、具體過程node

  • 儘量搞清楚問題的來龍去脈mysql

  • 有誰在?linux

  • 以前發生了什麼?ios

  • 如今在運行的進程是啥?sql

  • 監聽的網絡服務數據庫

  • CPU和內存使用狀況apache

  • 查看硬件

  • I/O 性能

  • 掛載點和文件系統

  • 內核、中斷和網絡

  • 系統日誌和內核消息

  • 任務計劃

  • 查看具體應用的系統日誌

4、總結

注,測試環境:操做系統 CentOS 6.4 x86_64。


1、前言

原文連接:http://devo.ps/blog/2013/03/06/troubleshooting-5minutes-on-a-yet-unknown-box.html

初版翻譯者:@老碼農的自留地

注,此文章在原文章的基礎上加入一些內容(修改與測試)。


2、簡介

Back when our team was dealing with operations, optimization and scalability at our previous company, we had our fair share of troubleshooting poorly performing applications and infrastructures of various sizes, often large (think CNN or the World Bank). Tight deadlines, 「exotic」 technical stacks and lack of information usually made for memorable experiences.

咱們團隊爲上一家公司承擔運維、優化和擴展工做的時候,咱們碰到了各類不一樣規模的性能不好的系統和基礎設備(大型系統居多,好比CNN或者世界銀行的系統)。要是再遇上修復時間緊、奇葩的技術平臺、缺乏信息和文檔,基本上這過程都會慘痛到讓咱們留下深入的記憶。


3、具體過程

遇到服務器故障,問題出現的緣由不多能夠一下就能找到。咱們基本上都會從如下步驟入手:


1.儘量搞清楚問題的來龍去脈

不要一會兒就扎到服務器前面,你須要先搞明白對這臺服務器有多少已知的狀況,還有故障的具體狀況。否則你很難搞清楚問題出在什麼地方,

必須搞清楚的問題有:

  • 故障的表現是什麼?無響應?報錯?

  • 故障是何時發現的?

  • 故障是否可重現?

  • 有沒有出現的規律(好比每小時出現一次)

  • 最後一次對整個平臺進行更新的內容是什麼(代碼、服務器等)?

  • 故障影響的特定用戶羣是什麼樣的(已登陸的, 退出的, 某個地域的…)?

  • 基礎架構(物理的、邏輯的)的文檔是否能找到?

  • 是否有監控平臺可用?(好比Munin、Zabbix、 Nagios、 New Relic… 什麼均可以)

  • 是否有日誌能夠查看? (好比Loggly、Airbrake、 Graylog…)

最後兩個是最方便的信息來源,不過別抱太大但願,基本上它們都不會有,只能再繼續摸索了。下面咱們繼續……


2.有誰在?

  [root@node1 ~]# w
  [root@node1 ~]# last


用這兩個命令看看都有誰在線,有哪些用戶訪問過。這不是什麼關鍵步驟,不過最好別在其餘用戶正幹活的時候來調試系統。嘿嘿!


3.以前發生了什麼?

1    [root@node1 ~]# history

查 看一下以前服務器上執行過的命令。看一下老是沒錯的,加上前面看的誰登陸過的信息,應該有點用。另外做爲admin要注意,不要利用本身的權限去侵犯別人 的隱私哦。到這裏先提醒一下,等會你可能會須要更新 HISTTIMEFORMAT 環境變量來顯示這些命令被執行的時間。對要否則光看到一堆不知道啥時候執行的命令,一樣會使人抓狂的。命令以下,

1    [root@node1 ~]# export HISTTIMEFORMAT='%F %T '

這樣再次用history命令查看就會顯示命令執行的時間。


4.如今在運行的進程是啥?

12    [root@node1 ~]# pstree –a
      [root@node1 ~]# ps aux


這都是查看現有進程的。 ps aux 的結果比較雜亂, pstree -a 的結果比較簡單明瞭,能夠看到正在運行的進程及相關用戶。其實這兩個工具通常好用,htop這個工具比較好用,前提是你的機器上已安裝好htop工具。有興趣的朋友能夠去用一下,哈哈!


5.監聽的網絡服務

[root@node1 ~]# netstat -ntlp (查看tcp端口)
[root@node1 ~]# netstat -nulp(查看udp端口)
[root@node1 ~]# netstat -nxlp (查看unix)


我 通常都分開運行這三個命令,不想一會兒,列出一大堆全部的服務。netstat -nalp倒也能夠。不過我毫不會用 numeric 選項 (鄙人一點淺薄的見解:IP 地址看起來更方便)。找到全部正在運行的服務,檢查它們是否應該運行。查看各個監聽端口,在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是同樣的。若是服務器上有好幾個Java或者Erlang什麼的進程在同時運行,可以按PID分別找到每一個進程就很重要了。一般咱們建議每臺 服務器上運行的服務少一點,必要時能夠增長服務器。若是你看到一臺服務器上有三四十個監聽端口開着,那仍是作個記錄,回頭有空的時候清理一下,從新組織一 下服務器。


6.CPU和內存使用狀況

[root@node1 ~]# free -m
[root@node1 ~]# uptime
[root@node1 ~]# top
[root@node1 ~]# htop


注意如下問題:

  • 還有空餘的內存嗎?服務器是否正在內存和硬盤之間進行swap?

  • 還有剩餘的CPU嗎?服務器是幾核的?是否有某些CPU核負載過多了?

  • 服務器最大的負載來自什麼地方? 平均負載是多少?


7.查看硬件

[root@node1 ~]# dmidecode | more
[root@node1 ~]# ethtool eth0


RAID卡、CPU、空餘的內存插槽。根據這些狀況能夠大體瞭解硬件問題的來源和性能改進的辦法。


  • 網卡是否設置好? 是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?


8.I/O 性能

 [root@node1 ~]# iostat -kx 2
[root@node1 ~]# vmstat 2 10
[root@node1 ~]# mpstat 2 10
[root@node1 ~]# dstat --top-io --top-bio


這些命令對於調試後端性能很是有用,

  • 檢查磁盤使用量:服務器硬盤是否已滿?

  • 是否開啓了swap交換模式 (si/so)?

  • CPU被誰佔用:系統進程?用戶進程?虛擬機?

  • dstat 是個人最愛,用它能夠看到誰在進行 IO: 是否是MySQL吃掉了全部的系統資源?仍是你的PHP進程?


9.掛載點和文件系統

 [root@node1 ~]# mount
 [root@node1 ~]# cat /etc/fstab
 [root@node1 ~]# vgs
 [root@node1 ~]# pvs
 [root@node1 ~]# lvs
 [root@node1 ~]# df –h
 [root@node1 ~]# lsof +D /


經過上面的命令咱們能夠獲得如下信息,

  • 一共掛載了多少文件系統?

  • 有沒有某個服務專用的文件系統? (好比MySQL?)

  • 文件系統的掛載選項是什麼: noatime? default? 有沒有文件系統被從新掛載爲只讀模式了?

  • 磁盤空間是否還有剩餘?

  • 是否有大文件被刪除但沒有清空?

  • 若是磁盤空間有問題,你是否還有空間來擴展一個分區?


10.內核、中斷和網絡

 [root@node1 ~]# sysctl -a | grep *
 [root@node1 ~]# cat /proc/interrupts
 [root@node1 ~]# cat /proc/net/ip_conntrack
 [root@node1 ~]# netstat -an
 [root@node1 ~]# ss –s


你的中斷請求是不是均衡地分配給CPU處理,仍是會有某個CPU的核由於大量的網絡中斷請求或者RAID請求而過載了?


  • SWAP交換的設置是什麼?對於工做站來講swappinness 設爲 60 就很好, 不過對於服務器就太糟了:你最好永遠不要讓服務器作SWAP交換,否則對磁盤的讀寫會鎖死SWAP進程。

  • conntrack_max 是否設的足夠大,能應付你服務器的流量?

  • 在不一樣狀態下(TIME_WAIT, …)TCP鏈接時間的設置是怎樣的?

  • 若是要顯示全部存在的鏈接,netstat 會比較慢, 你能夠先用 ss 看一下整體狀況。

你還能夠看一下Linux TCP tuning瞭解網絡性能調優的一些要點。


11.系統日誌和內核消息

[root@node1 ~]# dmesg
[root@node1 ~]# less /var/log/messages
[root@node1 ~]# less /var/log/secure
[root@node1 ~]# less /var/log/auth


經過上面的命令咱們會獲得如下信息,

  • 查看錯誤和警告消息,好比看看是否是不少關於鏈接數過多致使?

  • 看看是否有硬件錯誤或文件系統錯誤?

  • 分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。


12.任務計劃

 [root@node1 ~]# for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done


是否有某個定時任務運行過於頻繁?


  • 是否有些用戶提交了隱藏的定時任務?

  • 在出現故障的時候,是否正好有某個備份任務在執行?


13.查看具體應用的系統日誌

這裏邊可分析的東西就多了,不過恐怕你做爲運維人員是沒功夫去仔細研究它的。關注那些明顯的問題,好比在一個典型的LAMP(Linux+Apache+Mysql+PHP)應用環境裏:

  • Apache & Nginx; 查找訪問和錯誤日誌, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。

  • MySQL; 在mysql.log找錯誤消息,看看有沒有結構損壞的表, 是否有innodb修復進程在運行,是否有disk/index/query 問題.

  • PHP-FPM; 若是設定了 php-slow 日誌, 直接找錯誤信息 (php, mysql, memcache, …),若是沒設定,趕忙設定。

  • Varnish; 在varnishlog 和 varnishstat 裏, 檢查 hit/miss比. 看看配置信息裏是否遺漏了什麼規則,使最終用戶能夠直接***你的後端?

  • HA-Proxy; 後端的情況如何?健康情況檢查是否成功?是前端仍是後端的隊列大小達到最大值了?


4、總結

通過這5分鐘以後,你應該對以下狀況比較清楚了:

  • 在服務器上運行的都是些啥?

  • 這個故障看起來是和 IO/硬件/網絡 或者 系統配置 (有問題的代碼、系統內核調優, …)相關。

  • 這個故障是否有你熟悉的一些特徵?好比對數據庫索引使用不當,或者太多的apache後臺進程。

  • 你甚至有可能找到真正的故障源頭。就算尚未找到,搞清楚了上面這些狀況以後,你如今也具有了深挖下去的條件。繼續努力吧!

最後,但願你們有所收穫吧^_^……

相關文章
相關標籤/搜索