我通常會(huì)嚴(yán)格保持此博客的技術(shù)性，將觀察、意見等內(nèi)容保持在最低限度。但是，這篇將介紹剛進(jìn)入系統(tǒng)管理/SRE/系統(tǒng)工程師/sysops/devops-ops(無論你想稱自己是什么)角色的常見的基礎(chǔ)知識(shí)。

[[276333]]

請(qǐng)跟我來!

“我的網(wǎng)站很慢!”

我只是隨機(jī)選擇了本文的問題類型，這也可以應(yīng)用于任何與系統(tǒng)管理員相關(guān)的故障排除。我并不是要炫耀那些可以發(fā)現(xiàn)最多的信息的最聰明的“金句”。它也不是一個(gè)詳盡的、一步步指導(dǎo)的、并在最后一個(gè)方框中導(dǎo)向“利潤(rùn)”一詞的“流程圖”。

我會(huì)通過一些例子展示常規(guī)的方法。

示例場(chǎng)景僅用于說明本文目的。它們有時(shí)會(huì)做一些不適用于所有情況的假設(shè)，而且肯定會(huì)有很多讀者在某些時(shí)候說“哦，但我覺得你會(huì)發(fā)現(xiàn)……”。

但那可能會(huì)讓我們錯(cuò)失重點(diǎn)。

十多年來，我一直在從事于支持工作，或在支持機(jī)構(gòu)工作，有一件事讓我一次又一次地感到震驚，這促使我寫下了這篇文章。

有許多技術(shù)人員在遇到問題時(shí)的本能反應(yīng)，就是不管三七二十一去嘗試可能的解決方案。

“我的網(wǎng)站很慢，所以”，

• 我將嘗試增大 MaxClients/MaxRequestWorkers/worker_connections
• 我將嘗試提升 innodb_buffer_pool_size/effective_cache_size
• 我打算嘗試啟用 mod_gzip(遺憾的是，這是真實(shí)的故事)

“我曾經(jīng)看過這個(gè)問題，它是因?yàn)槟撤N原因造成的 —— 所以我估計(jì)還是這個(gè)原因，它應(yīng)該能解決這個(gè)問題。”

這浪費(fèi)了很多時(shí)間，并會(huì)讓你在黑暗中盲目亂撞，胡亂鼓搗。

你的 InnoDB 的緩沖池也許達(dá)到 100% 的利用率，但這可能只是因?yàn)橛腥诉\(yùn)行了一段時(shí)間的一次性大型報(bào)告導(dǎo)致的。如果沒有排除這種情況，那你就是在浪費(fèi)時(shí)間。

開始之前

在這里，我應(yīng)該說明一下，雖然這些建議同樣適用于許多角色，但我是從一般的支持系統(tǒng)管理員的角度來撰寫的。在一個(gè)成熟的內(nèi)部組織中，或與規(guī)模較大的、規(guī)范管理的或“企業(yè)級(jí)”客戶合作時(shí)，你通常會(huì)對(duì)一切都進(jìn)行檢測(cè)、測(cè)量、繪制、整理(甚至不是文字)，并發(fā)出警報(bào)。那么你的方法也往往會(huì)有所不同。讓我們?cè)谶@里先忽略這種情況。

如果你沒有這種東西，那就隨意了。

澄清問題

首先確定實(shí)際上是什么問題。“慢”可以是多種形式的。是收到第一個(gè)字節(jié)的時(shí)間嗎?從糟糕的 Javascript 加載和每頁加載要拉取 15 MB 的靜態(tài)內(nèi)容，這是一個(gè)完全不同類型的問題。是慢，還是比通常慢?這是兩個(gè)非常不同的解決方案!

在你著手做某事之前，確保你知道實(shí)際報(bào)告和遇到的問題。找到問題的根源通常很困難，但即便找不到也必須找到問題本身。

否則，這相當(dāng)于系統(tǒng)管理員帶著一把刀去參加槍戰(zhàn)。

唾手可得

首次登錄可疑服務(wù)器時(shí)，你可以查找一些常見的嫌疑對(duì)象。事實(shí)上，你應(yīng)該這樣做!每當(dāng)我登錄到服務(wù)器時(shí)，我都會(huì)發(fā)出一些命令來快速檢查一些事情：我們是否發(fā)生了頁交換(free / vmstat)，磁盤是否繁忙(top / iostat / iotop)，是否有丟包(netstat / proc/net/dev)，是否處于連接數(shù)過多的狀態(tài)(netstat)，有什么東西占用了 CPU(top)，誰在這個(gè)服務(wù)器上(w / who)，syslog 和 dmesg 中是否有引人注目的消息?

如果你從 RAID 控制器得到 2000 條抱怨直寫式緩存沒有生效的消息，那么繼續(xù)進(jìn)行是沒有意義的。

這用不了半分鐘。如果什么都沒有引起你的注意 —— 那么繼續(xù)。

重現(xiàn)問題

如果某處確實(shí)存在問題，并且找不到唾手可得的信息。

那么采取所有步驟來嘗試重現(xiàn)問題。當(dāng)你可以重現(xiàn)該問題時(shí)，你就可以觀察它。當(dāng)你能觀察到時(shí)，你就可以解決。如果在第一步中尚未顯現(xiàn)出或覆蓋了問題所在，詢問報(bào)告問題的人需要采取哪些確切步驟來重現(xiàn)問題。

對(duì)于由太陽耀斑或只能運(yùn)行在 OS/2 上的客戶端引起的問題，重現(xiàn)并不總是可行的。但你的第一個(gè)停靠港應(yīng)該是至少嘗試一下!在一開始，你所知道的是“某人認(rèn)為他們的網(wǎng)站很慢”。對(duì)于那些人，他們可能還在用他們的 GPRS 手機(jī)，也可能正在安裝 Windows 更新。你在這里挖掘得再深也是浪費(fèi)時(shí)間。

嘗試重現(xiàn)!

檢查日志

我對(duì)于有必要包括這一點(diǎn)感到很難過。但是我曾經(jīng)看到有人在運(yùn)行 tail /var/log/... 之后幾分鐘就不看了。大多數(shù) *NIX 工具都特別喜歡記錄日志。任何明顯的錯(cuò)誤都會(huì)在大多數(shù)應(yīng)用程序日志中顯得非常突出。檢查一下。

縮小范圍

如果沒有明顯的問題，但你可以重現(xiàn)所報(bào)告的問題，那也很棒。所以，你現(xiàn)在知道網(wǎng)站是慢的。現(xiàn)在你已經(jīng)把范圍縮小到：瀏覽器的渲染/錯(cuò)誤、應(yīng)用程序代碼、DNS 基礎(chǔ)設(shè)施、路由器、防火墻、網(wǎng)卡(所有的)、以太網(wǎng)電纜、負(fù)載均衡器、數(shù)據(jù)庫、緩存層、會(huì)話存儲(chǔ)、Web 服務(wù)器軟件、應(yīng)用程序服務(wù)器、內(nèi)存、CPU、RAID 卡、磁盤等等。

根據(jù)設(shè)置添加一些其他可能的罪魁禍?zhǔn)住Ｋ鼈円部赡苁?SAN，也不要忘記硬件 WAF!以及…… 你明白我的意思。

如果問題是接收到第一個(gè)字節(jié)的時(shí)間，你當(dāng)然會(huì)開始對(duì) Web 服務(wù)器去應(yīng)用上已知的修復(fù)程序，就是它響應(yīng)緩慢，你也覺得幾乎就是它，對(duì)吧?但是你錯(cuò)了!

你要回去嘗試重現(xiàn)這個(gè)問題。只是這一次，你要試圖消除盡可能多的潛在問題來源。

你可以非常輕松地消除絕大多數(shù)可能的罪魁禍?zhǔn)祝耗隳軓姆?wù)器本地重現(xiàn)問題嗎?恭喜，你剛剛節(jié)省了自己必須嘗試修復(fù) BGP 路由的時(shí)間。

如果不能，請(qǐng)嘗試使用同一網(wǎng)絡(luò)上的其他計(jì)算機(jī)。如果可以的話，至少你可以將防火墻移到你的嫌疑人名單上，(但是要注意一下那個(gè)交換機(jī)!)

是所有的連接都很慢嗎?雖然服務(wù)器是 Web 服務(wù)器，但并不意味著你不應(yīng)該嘗試使用其他類型的服務(wù)進(jìn)行重現(xiàn)問題。netcat 在這些場(chǎng)景中非常有用(但是你的 SSH 連接可能會(huì)一直有延遲，這可以作為線索)!如果這也很慢，你至少知道你很可能遇到了網(wǎng)絡(luò)問題，可以忽略掉整個(gè) Web 軟件及其所有組件的問題。用這個(gè)知識(shí)(我不收 200 美元)再次從頂部開始，按你的方式由內(nèi)到外地進(jìn)行!

即使你可以在本地復(fù)現(xiàn) —— 仍然有很多“因素”留下。讓我們排除一些變量。你能用普通文件重現(xiàn)它嗎?如果 i_am_a_1kb_file.html 很慢，你就知道它不是數(shù)據(jù)庫、緩存層或 OS 以外的任何東西和 Web 服務(wù)器本身的問題。

你能用一個(gè)需要解釋或執(zhí)行的 hello_world.(py|php|js|rb..) 文件重現(xiàn)問題嗎?如果可以的話，你已經(jīng)大大縮小了范圍，你可以專注于少數(shù)事情。如果 hello_world 可以馬上工作，你仍然學(xué)到了很多東西!你知道了沒有任何明顯的資源限制、任何滿的隊(duì)列或在任何地方卡住的 IPC 調(diào)用，所以這是應(yīng)用程序正在做的事情或它正在與之通信的事情。

所有頁面都慢嗎?或者只是從第三方加載“實(shí)時(shí)分?jǐn)?shù)數(shù)據(jù)”的頁面慢?

這可以歸結(jié)為：你仍然可以重現(xiàn)這個(gè)問題所涉及的最少量的“因素”是什么?

我們的示例是一個(gè)緩慢的網(wǎng)站，但這同樣適用于幾乎所有問題。郵件投遞?你能在本地投遞嗎?能發(fā)給自己?jiǎn)?能發(fā)給<常見的服務(wù)提供者>嗎?使用小的、純文本的消息進(jìn)行測(cè)試。嘗試直到遇到 2MB 擁堵時(shí)。使用 STARTTLS 和不使用 STARTTLS 呢?按你的方式由內(nèi)到外地進(jìn)行!

這些步驟中的每一步都只需要幾秒鐘，遠(yuǎn)遠(yuǎn)快于實(shí)施大多數(shù)“可能的”修復(fù)方案。

隔離觀察

到目前為止，當(dāng)你去除特定組件時(shí)無法重現(xiàn)問題時(shí)，你可能已經(jīng)偶然發(fā)現(xiàn)了問題所在。

但如果你還沒有，或者你仍然不知道為什么：一旦你找到了一種方法來重現(xiàn)問題，你和問題之間的“東西”(某個(gè)技術(shù)術(shù)語)最少，那么就該開始隔離和觀察了。

請(qǐng)記住，許多服務(wù)可以在前臺(tái)運(yùn)行和/或啟用調(diào)試。對(duì)于某些類別的問題，執(zhí)行此操作通常非常有幫助。

這也是你的傳統(tǒng)武器庫發(fā)揮作用的地方。strace、lsof、netstat、GDB、iotop、valgrind、語言分析器(cProfile、xdebug、ruby-prof ……)那些類型的工具。

一旦你走到這一步，你就很少能擺脫剖析器或調(diào)試器了。

strace 通常是一個(gè)非常好的起點(diǎn)。

你可能會(huì)注意到應(yīng)用程序停留在某個(gè)連接到端口 3306 的套接字文件描述符上的特定 read()調(diào)用上。你會(huì)知道該怎么做。

轉(zhuǎn)到 MySQL 并再次從頂部開始。顯而易見：“等待某某鎖”、死鎖、max_connections ……進(jìn)而：是所有查詢?還是只寫請(qǐng)求?只有某些表?還是只有某些存儲(chǔ)引擎?等等……

你可能會(huì)注意到調(diào)用外部 API 資源的 connect() 需要五秒鐘才能完成，甚至超時(shí)。你會(huì)知道該怎么做。

你可能會(huì)注意到，在同一對(duì)文件中有 1000 個(gè)調(diào)用 fstat() 和 open() 作為循環(huán)依賴的一部分。你會(huì)知道該怎么做。

它可能不是那些特別的東西，但我保證，你會(huì)發(fā)現(xiàn)一些東西。

如果你只是從這一部分學(xué)到一點(diǎn)，那也不錯(cuò);學(xué)習(xí)使用 strace 吧!真的學(xué)習(xí)它，閱讀整個(gè)手冊(cè)頁。甚至不要跳過歷史部分。man 每個(gè)你還不知道它做了什么的系統(tǒng)調(diào)用。98% 的故障排除會(huì)話以 strace 而終結(jié)。