什么磁盤慢會導致Linux負載飆升

　　Linu_繼承了Uni_以網(wǎng)絡為核心的設計思想，是一個性能穩(wěn)定的多用戶網(wǎng)絡操作系統(tǒng)。有用戶發(fā)現(xiàn)磁盤變慢時候會導致Linu_負載飆升，但是不知道什么原因，這篇文章主要介紹了淺談為什么磁盤慢會導致Linu_負載飆升，小編覺得還是挺不錯的，具有一定借鑒價值，需要的朋友可以參考下

　　一、CPU利用率和負載率的區(qū)別

　　這里要區(qū)別CPU負載和CPU利用率，它們是不同的兩個概念，但它們的信息可以在同一個top命令中進行顯示。CPU利用率顯示的是程序在運行期間實時占用的CPU百分比，這是對一個時間段內(nèi)CPU使用狀況的統(tǒng)計，通過這個指標可以看出在某一個時間段內(nèi)CPU被占用的情況， 如果被占用時間很高，那么就需要考慮CPU是否已經(jīng)處于超負荷運作。而CPU負載顯示的是在一段時間內(nèi)CPU正在處理以及等待CPU處理的進程數(shù)之和的統(tǒng)計信息，也就是CPU使用隊列的長度的統(tǒng)計信息。

　　CPU利用率高并不意味著負載就一定大，可能這個任務是一個CPU密集型的。一樣CPU低利用率的情況下是否會有高Load Average的情況產(chǎn)生呢?理解占有時間和使用時間就可以知道，當CPU分配時間片以后，是否使用完全取決于使用者，因此完全可能出現(xiàn)低利用率高Load Average的情況。另外IO設備也可能導致CPU負載高。

　　由此來看，僅僅從CPU的使用率來判斷CPU是否處于一種超負荷的工作狀態(tài)還是不夠的，必須結合Load Average來全局的看CPU的使用情況。網(wǎng)上有個例子來說明兩者的區(qū)別如下：某公用電話亭，有一個人在打電話，四個人在等待，每人限定使用電話一分鐘，若有人一分鐘之內(nèi)沒有打完電話，只能掛掉電話去排隊，等待下一輪。電話在這里就相當于CPU，而正在或等待打電話的人就相當于任務數(shù)。在電話亭使用過程中，肯定會有人打完電話走掉，有人沒有打完電話而選擇重新排隊，更會有新增的人在這兒排隊，這個人數(shù)的變化就相當于任務數(shù)的增減。為了統(tǒng)計平均負載情況，我們5秒鐘統(tǒng)計一次人數(shù)，并在第1、5、15分鐘的時候對統(tǒng)計情況取平均值，從而形成第1、5、15分鐘的平均負載。有的人拿起電話就打，一直打完1分鐘，而有的人可能前三十秒在找電話號碼，或者在猶豫要不要打，后三十秒才真正在打電話。如果把電話看作CPU，人數(shù)看作任務，我們就說前一個人(任務)的CPU利用率高，后一個人(任務)的CPU利用率低。當然， CPU并不會在前三十秒工作，后三十秒歇著，CPU是一直在工作。只是說，有的程序涉及到大量的計算，所以CPU利用率就高，而有的程序牽涉到計算的部分很少，CPU利用率自然就低。但無論CPU的利用率是高是低，跟后面有多少任務在排隊沒有必然關系。

　　CPU數(shù)量和CPU核心數(shù)(即內(nèi)核數(shù))都會影響到CPU負載，因為任務最終是要分配到CPU核心去處理的。兩塊CPU要比一塊CPU好，雙核要比單核好。因此，我們需要記住，除去CPU性能上的差異，CPU負載是基于內(nèi)核數(shù)來計算的，即“有多少內(nèi)核，即有多少負載”，如單核最好不要超過100%，也就是負載為1.00，如此類推。

　　Linu_里有一個/proc目錄，存放的是當前運行系統(tǒng)的虛擬映射，其中有一個文件為cpuinfo，這個文件里存放著CPU的信息。/proc/cpuinfo文件按邏輯CPU而非真實CPU分段落顯示信息，每個邏輯CPU的信息占用一個段落，第一個邏輯CPU標識從0開始。

　　$ cat /proc/cpuinfo

　　processor : 0

　　vendor_id : GenuineIntel

　　cpu family : 6

　　model : 63

　　model name : Intel(R) _eon(R) CPU E5-2630 v3 @ 2.40GHz

　　stepping : 2

　　microcode : 0_36

　　cpu MHz : 2399.998

　　cache size : 20480 KB

　　physical id : 0

　　siblings : 2

　　core id : 0

　　cpu cores : 2

　　apicid : 0

　　initial apicid : 0

　　fpu : yes

　　fpu_e_ception : yes

　　cpuid level : 15

　　wp : yes

　　flags : fpu vme de pse tsc msr pae mce c_8 apic sep mtrr ......

　　bogomips : 4799.99

　　clflush size : 64

　　cache_alignment : 64

　　address sizes : 42 bits physical, 48 bits virtual

　　power management:

　　要理解該文件中的CPU信息，有幾個相關的概念要知道，如：processor表示邏輯CPU的標識、model name表示真實CPU的型號信息、physical id表示真實CPU和標識、cpu cores表示真實CPU的內(nèi)核數(shù)等等。

　　邏輯CPU的描述：現(xiàn)在的服務器一般都使用了“超線程”(Hyper-Threading，簡稱HT)技術來提高CPU的性能。超線程技術是在一顆CPU同時執(zhí)行多個程序而共同分享一顆CPU內(nèi)的資源，理論上要像兩顆CPU一樣在同一時間執(zhí)行兩個線程。雖然采用超線程技術能同時執(zhí)行兩個線程，但它并不象兩個真正的CPU那樣，每各CPU都具有獨立的資源。當兩個線程都同時需要某一個資源時，其中一個要暫時停止，并讓出資源，直到這些資源閑置后才能繼續(xù)。因此超線程的性能并不等于兩顆CPU的性能。具有超線程技術的CPU還有一些其它方面的限制。

　　二、CPU負載率的計算方式

　　Load average的概念源自UNI_系統(tǒng)，雖然各家的公式不盡相同，但都是用于衡量正在使用CPU的進行數(shù)量和正在等待CPU的進程數(shù)量，一句話就是runable processes的數(shù)量。所以Load average可以作為CPU瓶頸的參考指標，如果大于CPU的數(shù)量，說明CPU可能不夠用了。

　　但是，在Linu_上有點差異!

　　Linu_上的load average除了包括正在使用CPU的進程數(shù)量和正在等待CPU的進程數(shù)量之外，還包括uninterruptible sleep的進程數(shù)量。通常等待IO設備、等待網(wǎng)絡的時候，進程會處于uninterruptible sleep狀態(tài)。Linu_設計者的邏輯是，uninterruptible sleep應該都是很短暫的，很快就會恢復運行，所以被等同于runnable。然而uninterruptible sleep即使再短暫也是sleep，何況現(xiàn)實世界中uninterruptible sleep未必很短暫，大量的、或長時間的uninterruptible sleep通常意味著IO設備遇到了瓶頸。眾所周知，sleep狀態(tài)的進程是不需要CPU的，即使所有的CPU都空閑，正在sleep的進程也是運行不了的，所以sleep進程的數(shù)量絕對不適合用作衡量CPU負載的指標，Linu_把uninterruptible sleep進程算進load average的做法直接顛覆了load average的本來意義。所以在Linu_系統(tǒng)上，load average這個指標基本失去了作用，因為你不知道它代表什么意思，當看到load average很高的時候，你不知道是runnable進程太多還是uninterruptible sleep進程太多，也就無法判斷是CPU不夠用還是IO設備有瓶頸。

　　從另一個方面來說，也就可以解釋為什么磁盤慢時(大量磁盤使用時)，CPU負載會飆高了。基本上我碰到CPU負載高的情況就兩種情況：CPU本身處理太多任務，再加上軟中斷和上下文切換太頻繁導致負載高;再就是磁盤太慢導致了不可中斷睡眠太多導致CPU負載高。

　　補充：Linu_基本命令

　　①ls 意為list 列出當前文件夾中的文件

　　-l 顯示文件的屬性 可用ll來表示

　?、赼lias 別名 看看是否有別名的文件

　　③cd dir 跳躍目錄 -P選項 將路徑中的鏈接文件替換成鏈接指向的文件路徑

　?、躳wd 查看當前工作的文件夾名 使用-P的選項，會直接進入到其中，相當于cd

　　相關閱讀：Linu_shell腳本不執(zhí)行問題實例分析

　　shell腳本不執(zhí)行問題：某天研發(fā)某同事找我說幫他看看他寫的shell腳本，死活不執(zhí)行，報錯。我看了下，腳本很簡單，也沒有常規(guī)性的錯誤，報“:badinterpreter:Nosuchfileordirectory”錯?？催@錯，我就問他是不是在windows下編寫的腳本，然后在上傳到linu_服務器的……果然。原因：在DOS/windows里，文本文件的換行符為rn，而在_i_系統(tǒng)里則為n，所以DOS/Windows里編輯過的文本文件到了_i_里，每一行都多了個^M。解決：

　　1)重新在linu_下編寫腳本;

　　2)vi:%s/r//g:%s/^M//g(^M輸入用Ctrl+v,Ctrl+m)附：sh-_腳本文件名，可以單步執(zhí)行并回顯結果，有助于排查復雜腳本問題。

什么磁盤慢會導致Linu_負載飆升相關文章：

1.linu_的進入磁盤命令

2.linu_系統(tǒng)硬盤安裝教程

3.Linu_系統(tǒng)管理命令大全

4.linu_如何查看cpu負載

5.Linu_磁盤空間怎么清理