服務器性能監控tips

 

 

 

1、tops

第一行

當前時間/已運行時間/登陸用戶數/最近 5 10 15分鐘平均負載（平均進程數 cat /proc/loadavg）

 

除了前3個數字表示平均進程數量外，後面的1個分數，分母表示系統進程總數，分子表示正在運行的進程數；最後一個數字表示最近運行的進程ID。

系統平均負載-進階解釋

只是上面那一句話的解釋，基本等於沒解釋。寫這篇文章的原因就是由於看到了一篇老外寫的關於Load Average的文章，以爲解釋的很好，因此纔打算摘取一部分用本身的話翻譯一下。

@scoutapp Thanks for your article Understanding Linux CPU Load, I just translate and share it to Chinese audiences.

爲了更好地理解系統負載，咱們用交通流量來作類比。

一、單核CPU - 單車道 - 數字在0.00-1.00之間正常

路況管理員會告知司機，若是前面比較擁堵，那司機就要等待，若是前面一路暢通，那麼司機就能夠駕車直接開過。

具體來講：

0.00-1.00 之間的數字表示此時路況很是良好，沒有擁堵，車輛能夠毫無阻礙地經過。

1.00 表示道路還算正常，但有可能會惡化並形成擁堵。此時系統已經沒有多餘的資源了，管理員須要進行優化。

1.00-*** 表示路況不太好了，若是到達2.00表示有橋上車輛一倍數目的車輛正在等待。這種狀況你必須進行檢查了。

二、多核CPU - 多車道 - 數字/CPU核數 在0.00-1.00之間正常

多核CPU的話，滿負荷狀態的數字爲 "1.00 * CPU核數"，即雙核CPU爲2.00，四核CPU爲4.00。

三、安全的系統平均負載

做者認爲單核負載在0.7如下是安全的，超過0.7就須要進行優化了。

四、應該看哪個數字，1分鐘，5分鐘仍是15分鐘？

做者認爲看5分鐘和15分鐘的比較好，即後面2個數字。

五、怎樣知道個人CPU是幾核呢？

使用如下命令能夠直接得到CPU核心數目

grep 'model name' /proc/cpuinfo | wc -l

解釋：2核CPU，過去一分鐘1.25/2，過載62.5%；過去5分鐘，CPU不過載，過去15分鐘，0.74/2=37%的CPU空閒。看 5分鐘和15分鐘的比較準確

誤解：load average
在load average高的狀況下分析系統瓶頸

1.3：如何判斷系統是否已經Over Load？
對通常的系統來講，根據cpu數量去判斷。若是平均負載始終在1.2一下，而你有2顆cup的機器。那麼基本不會出現cpu不夠用的狀況。也就是Load平均要小於Cpu的數量
1.4：Load與容量規劃（Capacity Planning）
通常是會根據15分鐘那個load 平均值爲首先。

1.5：Load誤解：
1：系統load高必定是性能有問題。
真相：Load高也許是由於在進行cpu密集型的計算
2：系統Load高必定是CPU能力問題或數量不夠。
真相：Load高只是表明須要運行的隊列累計過多了。但隊列中的任務實際多是耗Cpu的，也多是耗i/0奶子其餘因素的。
3：系統長期Load高，首先增長CPU
真相：Load只是表象，不是實質。增長CPU個別狀況下會臨時看到Load降低，但治標不治本。

2：在Load average 高的狀況下如何鑑別系統瓶頸。
是CPU不足，仍是io不夠快形成或是內存不足？

2.1：查看系統負載vmstat

procs

r 列表示運行和等待cpu時間片的進程數，若是長期大於1，說明cpu不足，須要增長cpu。
b 列表示在等待資源的進程數，好比正在等待I/O、或者內存交換等。
cpu 表示cpu的使用狀態
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，可是若是長期大於50%，須要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這裏us + sy的參考值爲80%，若是us+sy 大於 80%說明可能存在CPU不足。
wa 列顯示了IO等待所佔用的CPU時間的百分比。這裏wa的參考值爲30%，若是wa超過30%，說明IO等待嚴重，這多是磁盤大量隨機訪問形成的，也可能磁盤或者磁盤訪問控制器的帶寬瓶頸形成的(主要是塊操做)。
id 列顯示了cpu處在空閒狀態的時間百分比
system 顯示採集間隔內發生的中斷數
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
memory
swpd 切換到內存交換區的內存數量(k表示)。若是swpd的值不爲0，或者比較大，好比超過了100m，只要si、so的值長期爲0，系統性能仍是正常
free 當前的空閒頁面列表中內存數量(k表示)
buff 做爲buffer cache的內存數量，通常對塊設備的讀寫才須要緩衝。
cache: 做爲page cache的內存數量，通常做爲文件系統的cache，若是cache較大，說明用到cache的文件較多，若是此時IO中bi比較小，說明文件系統效率比較好。
swap
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
IO
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
這裏咱們設置的bi+bo參考值爲1000，若是超過1000，並且wa值較大應該考慮均衡磁盤負載，能夠結合iostat輸出來分析。

2.2：查看磁盤負載iostat
每隔2秒統計一次磁盤IO信息，直到按Ctrl+C終止程序，-d 選項表示統計磁盤信息， -k 表示以每秒KB的形式顯示，-t 要求打印出時間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤IO負載情況提供了關於自從系統啓動以來的統計信息。隨後的每一次輸出則是每一個間隔之間的平均IO負載情況。

 

# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒進行 merge 的讀操做數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操做數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，由於每扇區大小爲512字節。(須要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(須要計算)
avgrq-sz: 平均每次設備I/O操做的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (由於aveq的單位爲毫秒)。
await: 平均每次設備I/O操做的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操做的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用於 I/O 操做，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (由於use的單位爲毫秒)

若是 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
idle小於70% IO壓力就較大了,通常讀取速度有較多的wait.

同時能夠結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所佔用的CPU時間的百分比,高過30%時IO壓力高)

另外還能夠參考
通常:
svctm < await (由於同時等待的請求的等待時間被重複計算了)，
svctm的大小通常和磁盤性能有關:CPU/內存的負荷也會對其有影響，請求過多也會間接致使 svctm 的增長。
await: await的大小通常取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。
若是 svctm 比較接近 await，說明I/O 幾乎沒有等待時間；
若是 await 遠大於 svctm，說明 I/O隊列太長，應用獲得的響應時間變慢，
若是響應時間超過了用戶能夠允許的範圍，這時能夠考慮更換更快的磁盤，調整內核 elevator算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可做爲衡量系統 I/O 負荷的指標，但因爲 avgqu-sz 是按照單位時間的平均值，因此不能反映瞬間的 I/O 洪水。

別人一個不錯的例子.(I/O 系統 vs. 超市排隊)
舉一個例子，咱們在超市排隊 checkout 時，怎麼決定該去哪一個交款臺呢? 首當是看排的隊人數，5我的總比20人要快吧?除了數人頭，咱們也經常看看前面人購買的東西多少，若是前面有個採購了一星期食品的大媽，那麼能夠考慮換個隊排了。還有就是收銀員的速度了，若是碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5分鐘前還人滿爲患的收款臺，如今已經是人去樓空，這時候交款但是很爽啊，固然，前提是那過去的 5 分鐘裏所作的事情比排隊要有意義(不過我還沒發現什麼事情比排隊還無聊的)。
I/O 系統也和超市排隊有不少相似之處:
r/s+w/s 相似於交款人的總數
平均隊列長度(avgqu-sz)相似於單位時間裏平均排隊人的個數
平均服務時間(svctm)相似於收銀員的收款速度
平均等待時間(await)相似於平均每人的等待時間
平均I/O數據(avgrq-sz)相似於平均每人所買的東西多少
I/O 操做率 (%util)相似於收款臺前有人排隊的時間比例。
咱們能夠根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出代表秒有 28.57 次設備 I/O 操做: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操做佔了主體 (w:r = 27:1)。
平均每次設備 I/O 操做只須要 5ms 就能夠完成，但每一個 I/O 請求卻須要等上 78ms，爲何? 由於發出的 I/O 請求太多 (每秒鐘約 29 個)，假設這些請求是同時發出的，那麼平均等待時間能夠這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + ... + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來代表 I/O 是同時發起的。
每秒發出的 I/O 請求不少 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這代表這 29 個請求的到來並不均勻，大部分時間 I/O 是空閒的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間裏 I/O 系統無事可作，全部 29 個 I/O 請求都在142毫秒以內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8，代表每秒內的I/O請求總共須要等待2232.8ms。因此平均隊列長度應爲 2232.8ms/1000ms = 2.23，而iostat 給出的平均隊列長度 (avgqu-sz) 卻爲 22.35，爲何?! 由於 iostat 中有 bug，avgqu-sz值應爲 2.23，而不是 22.35。

第二行

 

任務：第二行顯示的是任務或者進程的總結。進程能夠處於不一樣的狀態。這裏顯示了所有進程的數量。除此以外，還有正在運行、睡眠、中止、殭屍進程的數量（殭屍是一種進程的狀態）。這些進程歸納信息能夠用't'切換顯示。

 第三行

 CPU狀態

 us, user： 運行(未調整優先級的) 用戶進程的CPU時間

 sy，system: 運行內核進程的CPU時間

 ni，niced：運行已調整優先級的用戶進程的CPU時間

 wa，IO wait: 用於等待IO完成的CPU時間

 id， 空閒CPU百分比

 hi：處理硬件中斷的CPU時間

 si: 處理軟件中斷的CPU時間

 st：這個虛擬機被hypervisor偷去的CPU時間

在top基本視圖中，按鍵盤數字「1」，可監控每一個邏輯CPU的情況：

  

觀察上圖，服務器有4個邏輯CPU，其實是1個物理CPU。

若是不按1，則在top視圖裏面顯示的是全部cpu的平均值。

 

 

第四行

物理內存顯示以下:

1，total：物理內存實際總量
2，used：這塊千萬注意，這裏可不是實際已經使用了的內存哦，這裏是總計分配給緩存（包含buffers 與cache ）使用的數量，但其中可能部分緩存並未實際使用。
3，free：未被分配的內存
4，shared：共享內存
5，buffers：系統分配的，但未被使用的buffer剩餘量。注意這不是總量，而是未分配的量
6，cached：系統分配的，但未被使用的cache 剩餘量。buffer 與cache 的區別見後面。
7，buffers/cache used：這個是buffers和cache的使用量，也就是實際內存的使用量，這個很是重要了，這裏纔是內存的實際使用量哦
8， buffers/cache free：未被使用的buffers 與cache 和未被分配的內存之和，這就是系統當前實際可用內存。千萬注意，這裏是 三者之和，也就是第一排的 free+buffers+cached，可不只僅是未被使用的buffers 與cache的和哦，還要加上free(未分配的和)
9，swap，這個我想你們都理解，交換分區總量，使用量，剩餘量

所有可用內存、已使用內存、空閒內存、緩衝內存。類似地：交換部分顯示的是：所有、已使用、空閒和緩衝交換空間。

Mem: 3881920k total 物理內存總量
3130516k used 使用的物理內存總量
288948 free 空閒內存總量
462456k buffers 用做內核緩存的內存量
Swap: 524284k total 交換區總量
132188k used 使用的交換區總量
392096k free 空閒交換區總量
450648k cached 緩衝的交換區總量。
內存中的內容被換出到交換區，然後又被換入到內存，但使用過的交換區還沒有被覆蓋，
該數值即爲這些內容已存在於內存中的交換區的大小。
相應的內存再次被換出時可沒必要再對交換區寫入。

內存顯示能夠用'm'命令切換。

 

5.字段
在橫向列出的系統屬性和狀態下面，是以列顯示的進程。不一樣的列表明下面要解釋的不一樣屬性。
默認上，top顯示這些關於進程的屬性：
PID 進程ID，進程的惟一標識符
USER 進程全部者的實際用戶名。
PR 進程的調度優先級。這個字段的一些值是'rt'。這意味這這些進程運行在實時態。
NI 進程的nice值（優先級）。越小的值意味着越高的優先級。
VIRT 進程使用的虛擬內存。
RES 駐留內存大小。駐留內存是任務使用的非交換物理內存大小。
SHR 進程使用的共享內存。
S 這個是進程的狀態。它有如下不一樣的值：
D - 不可中斷的睡眠態。
R – 運行態
S – 睡眠態
T – 被跟蹤或已中止
Z – 殭屍態

%CPU
自從上一次更新時到如今任務所使用的CPU時間百分比。
%MEM
進程使用的可用物理內存百分比。
TIME+
任務啓動後到如今所使用的所有CPU時間，精確到百分之一秒。
COMMAND
運行進程所使用的命令。

 

top命令的補充

top命令是Linux上進行系統監控的首選命令，但有時候卻達不到咱們的要求，好比當前這臺服務器，top監控有很大的侷限性。這臺服務器運行着websphere集羣，有兩個節點服務，就是【top視圖 01】中的老大、老二兩個java進程，top命令的監控最小單位是進程，因此看不到我關心的java線程數和客戶鏈接數，而這兩個指標是java的web服務很是重要的指標，一般我用ps和netstate兩個命令來補充top的不足。

 監控java線程數：

ps -eLf | grep java | wc -l

監控網絡客戶鏈接數：

netstat -n | grep tcp | grep 偵聽端口 | wc -l

上面兩個命令，可改動grep的參數，來達到更細緻的監控要求。

在Linux系統「一切都是文件」的思想貫徹指導下，全部進程的運行狀態均可以用文件來獲取。系統根目錄/proc中，每個數字子目錄的名字都是運行中的進程的PID，進入任一個進程目錄，可經過其中文件或目錄來觀察進程的各項運行指標，例如task目錄就是用來描述進程中線程的，所以也能夠經過下面的方法獲取某進程中運行中的線程數量（PID指的是進程ID）：

ls /proc/PID/task | wc -l
在linux中還有一個命令pmap，來輸出進程內存的情況，能夠用來分析線程堆棧：

 pmap PID

你們都熟悉Linux下能夠經過top命令來查看全部進程的內存，CPU等信息。除此以外，還有其餘一些命令，能夠獲得更詳細的信息，例如進程相關

cat /proc/your_PID/status  

經過top或ps -ef | grep '進程名' 獲得進程的PID。該命令能夠提供進程狀態、文件句柄數、內存使用狀況等信息。
內存相關
    vmstat -s -S M  
該能夠查看包含內存每一個項目的報告，經過-S M或-S k能夠指定查看的單位，默認爲kb。結合watch命令就能夠看到動態變化的報告了。

也可用  cat /proc/meminfo  

要看cpu的配置信息可用

cat /proc/cpuinfo  

它能顯示諸如CPU核心數，時鐘頻率、CPU型號等信息。

要查看cpu波動狀況的，尤爲是多核機器上，可以使用

mpstat -P ALL 10 

該命令可間隔10秒鐘採樣一次CPU的使用狀況，每一個核的狀況都會顯示出來，例如，每一個核的idle狀況等。
只需查看均值的，可用
    iostat -c 
IO相關
    iostat -P ALL  
該命令可查看全部設備使用率、讀寫字節數等信息。

另外，htop ，有時間能夠用一下。

 

 

Linux查看物理CPU個數、核數、邏輯CPU個數

# 總核數 = 物理CPU個數 X 每顆物理CPU的核數

# 總邏輯CPU數 = 物理CPU個數 X 每顆物理CPU的核數 X 超線程數

 

# 查看物理CPU個數

cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l

 

# 查看每一個物理CPU中core的個數(即核數)

cat /proc/cpuinfo| grep "cpu cores"| uniq

 

# 查看邏輯CPU的個數

cat /proc/cpuinfo| grep "processor"| wc -l

 

 查看CPU信息（型號）cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c