聊聊服務器的負載

負載能夠說是一個服務器是否正常的風向標，當接入的軟件運行緩慢的時候，相信大部分人排查線上服務器第一件事就是要看下負載的高低？經過uptime命令能夠直觀的看到系統一、五、15分鐘內的平均負載值，本文簡稱爲負載。那麼關於負載就有一些有意思的話題了。如什麼是負載，如何斷定負載的高低？那些緣由致使負載升高？下面結合個人一些工做經驗簡單聊一聊。

什麼是負載？

在我最先接觸負載一詞的時候，大腦裏的印象就是衡量服務器的繁忙程度，所以服務器的負載不能過高，高了的話服務器就忙不過來了。我對負載這樣的認識一直大概保持了一年半，後來仍是由於有個原 因，因而去man了下uptime。

關於負載的解釋，uptime上有算是較爲詳細的說明：

System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in uninterruptable state is waiting for some I/O access, eg waiting for disk. The averages are taken over the three time intervals. Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.

根據以上的描述，負載的概念就清晰起來了，首先負載是什麼？ 負載是一個平均進程數。那麼，是全部狀態下的進程數嗎？不是的，對進程的狀態有要求，就是進程的狀態須要處於 runnable state(可運行狀態) 和 uninterrupttable state（不可中斷狀態）。

ok，如今的重點來到了這兩種狀態的進程的理解上，何爲 runnable 狀態，上面也給出了清晰的解釋，就是要麼進程正在使用cpu，要麼正在等待着使用cpu。對這句解釋稍做補充，在一個進程的生命週期中，會有不一樣狀態，處於runnable狀態的進程表明着一切資源準備就緒了（cpu資源除外），那麼就會有兩種狀況，一種是已經得到了cpu資源的，那麼就表明着他正在使用cpu資源進行運行，另一種就是他在排隊等待cpu資源。（進程調度器會爲使用cpu資源的進程維護一個隊列）由於linux是多用戶多進程系統，進程數量通常遠大於cpu數量，所以cpu的資源是珍貴的，使用須要申請和排隊。

何爲uninterruptable 狀態？，就是進程正在等待一些IO的請求，諸如磁盤IO/網絡IO。說實在的，對於這個理解我還只能停留在表面。uninterruptable和 interruptable都是進程的sleep狀態。咱們能夠理解爲進程在睡覺（進程要繼續運行的條件和資源不充分，所以他們要睡覺），進入這兩種狀態下，他們會當即釋放掉cpu資源，不一樣點在於，處於interruptable是一種淺睡，任何的風吹草動（信號）都會驚醒他，而後他就會醒來接着幹活。那麼uninterruptable 就是一種沉睡，只有他等到的東西等來了他才醒來。

總結來講，負載數值便是處於runnable state 和uninterruptable state 的進程數。能夠大體理解爲系統正在處理的進程數。

如何判斷負載的高低？

記得畢業後剛入職幾個月的時候，適逢雙十一，上面分了幾臺小的服務器，讓盯梢負載。而後，我問旭哥說多高負載算高，旭哥說超過1就很高了。因此，今後我就記住了，負載高於1就高了。直到有一次一個持有相同概念的同事被另一個同事鄙視後，我偷偷弄明白了負載後，負載高於1就過載的說法就不攻自破了。

關於負載過1就過載的說法在只有一個cpu的狀況下是能夠理解的，由於一個cpu同一時刻只能處理一個進程，因此恰好是100%的滿負荷運行。可是在一個四核的機器上，無異於其餘三個cpu在空閒着。因此看負載是否過載，要有一個前提，那就是須要明確有幾個cpu，若是負載數長時間高於cpu數，那麼就能夠判斷爲過載。

cat /proc/cpuinfo

以上命令能夠查看cpu的個數。但這並非說，咱們都要線上的機器都要滿負荷的去跑，確定是要有必定的餘量的，至於餘多少，能夠根據本身業務的訪問狀況決定。

那些緣由致使負載升高？

有了對負載本質的瞭解，就不難分析出負載較高的狀況了？致使負載升高的緣由無非有兩個緣由，一個是處於 runnable state 的進程不斷增多，另外一個是處於 uninterruptable state的進程不斷增多。runnable state 增多通常是cpu資源不夠，而uninterruptable state增多大部分時間是磁盤IO成爲瓶頸。

cpu資源不夠，爲了方便理解，咱們能夠假設機器只有一個cpu，而每一個進程處理須要1s，可是每1s就會2個進程須要處理，此時每1過1s就會累積一個進程處理不掉，那麼負載天然就不斷的增長 IO成爲瓶頸，有的時候cpu利用率不是很高，可是負載依然會很高，好比大量的讀請求，致使磁盤io成爲瓶頸，此時進程在等待磁盤IO的同時是不可中斷的狀態，所以仍然會參與負載值的計算，所以負載會變高

我的遇到的一些致使負載升高的緣由

本人從事電商ERP系統開發，服務器中安裝有mysql服務器，所以通常狀況下，出問題大部分是mysql中的一些問題。

1. 大量數據請求時，包括搜索時全表掃描、以及大量的導出數據等。這種狀況下通常大量的讀請求讓IO成爲瓶頸，致使其餘進程也處理緩慢，所以隨着時間的增長負載就會升高
2. 事務未提交，通常一些業務處理系統，耦合關係強，如訂單的出庫和庫存的關係，通常是須要原子性操做，這個時候通常會使用事務來進行控制，可是不幸出現事務未提交的狀況，會致使大量資源被鎖，其餘請求處於長時間等待的狀況，這種狀況也會致使負載升高
3. 死鎖，mysql的死鎖檢測以及回滾都會有必定的時間，加之事務對資源的獨佔，出現死鎖會出現短暫的擁堵現象，同時負載的短期內上升，不事後面繼續會降低。可是死鎖很頻繁的狀況下，負載也會一直較高
4. 內存不足時，mysql服務器是至關耗費內存的，若是內存不足致使交換分區長時間使用的話，也會讓機器負載升高
5. 其餘致使的一些IO問題，如磁盤損壞以及磁盤空間不足