top命令是看當前進程的cpu和內存等的占用情況

參數解析

top - 20:54:37 up 228 days, 11:03, 3 users, load average: 0.54, 0.33, 0.32

Tasks: 266 total, 1 running, 265 sleeping, 0 stopped, 0 zombie

%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65806688 total, 3267880 free, 51877252 used, 10661556 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 12528752 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

對上面第三行的解釋：

us(user cpu time)：用戶態使用的cpu時間比。該值較高時，說明用戶進程消耗的 CPU 時間比較多，比如，如果該值長期超過 50%，則需要對程序算法或代碼等進行優化。

sy(system cpu time)：系統態使用的cpu時間比。

ni(user nice cpu time)：用做nice加權的進程分配的用戶態cpu時間比

id(idle cpu time)：空閑的cpu時間比。如果該值持續為0，同時sy是us的兩倍，則通常說明系統則面臨著 CPU 資源的短缺。

wa(io wait cpu time)：cpu等待磁盤寫入完成時間。該值較高時，說明IO等待比較嚴重，這可能磁盤大量作隨機訪問造成的，也可能是磁盤性能出現了瓶頸。

hi(hardware irq)：硬中斷消耗時間

si(software irq)：軟中斷消耗時間

st(steal time)：虛擬機偷取時間

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4048 hadoop 20 0 24.9g 1.5g 11372 S 2.7 2.4 1168:24 java

10359 root 20 0 122712 19332 2612 S 2.3 0.0 12:48.32 flux_app

6006 hadoop 20 0 14.7g 1.8g 10964 S 2.0 2.8 5915:47 presto-server

5735 root 20 0 2767844 621184 9808 S 0.7 0.9 3197:27 360entclient

以上圖來說幾個重要的參數情況

PID 進程號

USER 運行用戶

VIRT 進程使用的虛擬內存總量

RES 物理內存用量

SHR 共享內存用量

%CPU 該進程自最近一次刷新以來所占用的CPU時間和總時間的百分比

%CPU顯示的是進程占用一個核的百分比，而不是整個cpu(12核)的百分比，有時候可能大于100，那是因為該進程啟用了多線程占用了多個核心，所以有時候我們看該值得時候會超過100%，但不會超過總核數*100

(%CPU>100的情況 這里顯示的所有的cpu加起來的使用率，說明你的CPU是多核 你運行top后按大鍵盤1看看，可以顯示每個cpu的使用率，top里顯示的是把所有使用率加起來。 )

%MEM 該進程占用的物理內存占總內存的百分比

COMMAND 該進程的命令名稱，如果一行顯示不下，則會進行截取。內存中的進程會有一個完整的命令行

load average 淺析

上述top命令中的load average: 0.54, 0.33, 0.32 表示了load average的一分鐘，五分鐘，十五分鐘的平均CPU負載

所謂的CPU負載指的是一段時間內任務隊列的長度，通俗的講，就是一段時間內一共有多少任務在使用或等待使用CPU。(當前的"負載值除以cpu核數"就是cpu的利用率)

當CPU完全空閑的時候，平均負荷為0(即load average的值為0)；當CPU工作量飽和的時候，平均負荷為1。

這里需要注意的是：

load average這個輸出值，這三個值的大小一般不能大于系統邏輯CPU的個數

比如一臺服務器有4個邏輯CPU，如果load average的三個值長期大于4時，說明CPU很繁忙，負載很高，可能會影響系統性能；

但是偶爾大于4時，倒不用擔心，一般不會影響系統性能。

load average舉例理解

判斷系統負荷是否過重，必須理解load average的真正含義。假設當前我的一臺服務器只有一個CPU，所有的運算都必須由這個CPU來完成。

不妨把這個CPU想象成一座大橋，橋上只有一根車道，所有車輛都必須從這根車道上通過(很顯然，這座橋只能單向通行)。

1)系統負荷為0，意味著大橋上一輛車也沒有。

2)系統負荷為0.5，意味著大橋一半的路段有車。

3)系統負荷為1.0，意味著大橋的所有路段都有車，也就是說大橋已經"滿"了。但是必須注意的是，直到此時大橋還是能順暢通行的。

4)系統負荷為1.7，意味著車輛太多了，大橋已經被占滿了(100%)，后面等著上橋的車輛為橋面車輛的70%。

以此類推，系統負荷2.0，意味著等待上橋的車輛與橋面的車輛一樣多；

系統負荷3.0，意味著等待上橋的車輛是橋面車輛的2倍。

總之，當系統負荷大于1，后面的車輛就必須等待了；系統負荷越大，過橋就必須等得越久。

CPU的系統負荷，基本上等同于上面的類比。大橋的通行能力，就是CPU的最大工作量；橋梁上的車輛，就是一個個等待CPU處理的進程(process)。

如果CPU每分鐘最多處理100個進程，那么：

系統負荷0.2，意味著CPU在這1分鐘里只處理20個進程；

系統負荷1.0，意味著CPU在這1分鐘 里正好處理100個進程；

系統負荷1.7，意味著除了CPU正在處理的100個進程以外，還有70個進程正排隊等著CPU處理。

上面，假設我的這臺服務器只有1個CPU。如果它裝了2個CPU，就意味著服務器的處理能力翻了一倍，能夠同時處理的進程數量也翻了一倍。

還是用大橋來類比，兩個CPU就意味著大橋有兩根車道了，通車能力翻倍了。

所以，2個CPU表明系統負荷可以達到2.0，此時每個CPU都達到100%的工作量。推廣開來，n個CPU的服務器，可接受的系統負荷最大為n。

至于load average是多少才算理想，這個有爭議，各有各的說法

個人比較贊同CPU負載小于等于"內核數乘以0.5-0.7"算是一種理想狀態。

load average返回三個平均值應該參考哪個值

如果只有1分鐘的系統負荷大于1.0，其他兩個時間段都小于1.0，這表明只是暫時現象，問題不大。

如果15分鐘內，平均系統負荷大于1.0(調整CPU核心數之后)，表明問題持續存在，不是暫時現象。

所以應該主要觀察"15分鐘系統負荷"，將它作為服務器正常運行的指標。

除去CPU性能上的差異，CPU負載是基于內核數來計算的。有一個說法是"有多少內核，即有多少負載"。

總結

以上是生活随笔為你收集整理的linux中负载值为多少正常_linux 查看负载和使用情况 top的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。