Linux 伺服器半夜負載飆高，我們一般按這個順序往下查

凌晨兩點，客戶的運維群在喊：產線看板刷不出來了。系統跑在一臺 Linux 伺服器上，監控面板裡那個負載數字已經飆到四十多。這種電話我們接過不止一次，趕到現場，有時候機器是真忙，有時候是它在空轉。這兩種情況處置方向完全相反，判斷錯了，重啟也白搭。

一、先分清是"真忙"還是"卡住了"

很多人一看負載高，就以為 CPU 忙不過來，其實不是一回事。Linux 的負載值把正在跑和排隊等資源的任務都算進去，一個程序卡在磁碟讀寫上不動，負載照樣往上漲，可 CPU 閒得很。所以第一眼要看的不是 CPU 使用率，是那幾個數字在持續往上爬，還是已經橫住了。

如果負載長時間居高不下、CPU 使用率卻很低，麻煩多半出在磁碟或者鎖上。反過來 CPU 被打滿、負載也跟著漲，那才是真有東西在死算。這個判斷花不了兩分鐘，方向卻能差出很遠。

二、按固定順序往下查，別跳步

我們的排查順序基本是固定的。先用 uptime 看負載走勢，再用 top 挑出吃資源最猛的幾個程序，接著 free 看記憶體和 swap 有沒有被打穿，然後 iostat 看磁碟的讀寫等待，最後 ss 看連線數是不是異常。

這五步走完，絕大多數問題自己就現形了。順序不能亂，最忌諱一上來就重啟，等於把現場毀了，問題下次還會原樣再來。遇到過一家工廠，伺服器反覆卡死，前幾次都是重啟了事，等摩傑斯接手才發現，是日誌檔案把一個分割槽寫滿了，寫日誌的程序一直失敗重試，把負載生生拖了起來。刪掉舊日誌、把輪轉配好，這個毛病再沒犯過。

三、工廠伺服器上最常見的幾個真兇

跑在工廠裡的伺服器，負載異常的原因翻來覆去就那麼幾樣。最常見的是磁碟寫滿，尤其是日誌目錄和資料庫的資料目錄，一旦分割槽滿了，不少程序會進入奇怪的重試狀態，越試越忙。其次是資料庫慢查詢，一條沒走索引的 SQL 就能把 CPU 拉滿，白天業務一多就爆。再就是記憶體不夠引起的 swap 抖動，機器看著沒事，實際一直拿硬碟當記憶體用，慢得離譜。

還有一類容易被忽視：定時任務撞車。備份、對帳、報表這些活，常常被排在同一個凌晨時段，幾件事一起擠，磁碟和 CPU 瞬間就被頂上去了。把時間錯開，往往就能消掉一大半的夜間告警。

四、平時做對幾件事，半夜就不用爬起來

給客戶部署系統時，我們有幾個標準動作。日誌必須配輪轉、設上限，絕不讓它無限長大；磁碟、記憶體、負載都接上監控，超閾值提前發告警，別等業務報錯才知道出事；定時任務排開時間，別都堆在同一個點上。

這些預防做到位，能砍掉大半的緊急故障，剩下的才是真正需要連夜處理的意外。摩傑斯從 2012 年在崑山成立起，PMS9、PMS5 的後端就一直跑在 Linux 上，十四年下來，蘇州、江蘇一帶幾百家制造客戶的現場伺服器都經過我們的手，這類排查是日常。崑山、蘇州一帶的工廠，伺服器半夜出問題、一時找不到人看的，可以找摩傑斯一起看。

總結：

負載飆高的第一反應不該是重啟，而是先分清機器是真忙還是在空轉，再按負載、CPU、記憶體、IO、網路這個順序一步步看下去。工廠伺服器的常見病根就那麼幾樣——磁碟寫滿、慢查詢、swap 抖動、定時任務撞車。把日誌輪轉、監控告警、任務錯峰這幾件事做在前面，很多半夜的電話就不會來。

相關閱讀：《工廠 IT 服務總覽》把這幾類問題都歸了類；同一主題下還有《產線系統分鐘級拉起》、《14 年 Linux 伺服器運維實錄》。