[linux command]top+ps+vmstat+iostat+cpuinfo

ps進程查看命令

使用該命令能夠肯定有哪些進程正在運行和運行的狀態、進程是否結束、進程有沒有僵死、哪些進程佔用了過多 的資源等等。總之大部分信息都是能夠經過執行該命令獲得的。

-A 顯示全部進程（等價於-e）(utility)
-a 顯示一個終端的全部進程，除了會話引線
-N 忽略選擇。
-d 顯示全部進程，但省略全部的會話引線(utility)
-x 顯示沒有控制終端的進程，同時顯示各個命令的具體路徑。dx不可合用。（utility）
-p pid 進程使用cpu的時間
-u uid or username 選擇有效的用戶id或者是用戶名
-g gid or groupname 顯示組的全部進程。
U username 顯示該用戶下的全部進程，且顯示各個命令的詳細路徑。如:ps U zhang;(utility)
-f 所有列出，一般和其餘選項聯用。如：ps -fa or ps -fx and so on.
-l 長格式（有F,wchan,C 等字段）
-j 做業格式
-o 用戶自定義格式輸出，如設定顯示字段爲 stat（狀態）, ppid（進程父id）, pid(進程id)，cmd（命令）。
v 以虛擬存儲器格式顯示
s 以信號格式顯示    -m 顯示全部的線程
-H 顯示進程的層次(和其它的命令合用，如：ps -Ha)（utility）
e 命令以後顯示環境（如：ps -d e; ps -a e）(utility)
h 不顯示第一行

r 顯示運行中的進程;

ww 避免詳細參數被截斷;

咱們經常使用的選項是組合是 aux 或 lax，還有參數 f 的應用。

二、ps aux 或 lax 輸出的解釋

USER  PID PPID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND

USER 進程的屬主;

PID 進程的ID;

PPID 父進程;

%CPU 進程佔用的CPU百分比;

%MEM 佔用內存的百分比;

NI 進程的NICE值，數值大，表示較少佔用CPU時間;

VSZ 進程虛擬大小;

RSS 駐留中頁的數量;

TTY 終端ID

STAT狀態碼：

< 優先級高的進程

N 優先級較低的進程

L 有些頁被鎖進內存;

s 進程的領導者(在它之下有子進程);

l 多進程的(使用 CLONE_THREAD, 相似 NPTL pthreads);

+ 位於後臺的進程組;

WCHAN 正在等待的進程資源;

START 啓動進程的時間;

TIME 進程消耗CPU的時間;

STAT: 

D 不可中斷 uninterruptible sleep (usually IO) 

R 運行 runnable (on run queue) 

S 中斷 sleeping 

T 中止 traced or stopped

Z 僵死 a defunct("zombie") process

如何殺死僵死進程？

ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'

-o：定義輸出格式，stat狀態、ppid父進程id，pid進程id，cmd命令

kill子進程，若是失敗則kill 父進程

kill -HUP 12339（父進程）

top實時動態地查看系統的總體運行狀況

top命令一個綜合了多方信息監測系統性能和運行信息的實用工具。經過top命令所提供的互動式界面，用熱鍵能夠管理。

top - 09:44:56[當前系統時間], 16 days[系統已經運行了16天], 1 user[個用戶當前登陸], load average: 9.59, 4.75, 1.92[系統負載，即任務隊列的平均長度]

Tasks: 145 total[總進程數], 2 running[正在運行的進程數], 143 sleeping[睡眠的進程數], 0 stopped[中止的進程數], 0 zombie[凍結進程數],

Cpu(s): 99.8%us[用戶空間佔用CPU百分比], 0.1%sy[內核空間佔用CPU百分比], 0.0%ni[用戶進程空間內改變過優先級的進程佔用CPU百分比], 0.2%id[空閒CPU百分比], 0.0%wa[等待輸入輸出的CPU時間百分比], 0.0%hi[], 0.0%st[],

Mem: 4147888k total[物理內存總量], 2493092k used[使用的物理內存總量], 1654796k free[空閒內存總量], 158188k buffers[用做內核緩存的內存量]

Swap:  5144568k total[交換區總量], 56k used[使用的交換區總量], 5144512k free[空閒交換區總量], 2013180k cached[緩衝的交換區總量],

統計信息區域的下方顯示了各個進程的詳細信息。首先來認識一下各列的含義。

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

序號列名含義
PID    進程id
PPID    父進程id
RUSER    Realusername
UID    進程全部者的用戶id
USER    進程全部者的用戶名
GROUP    進程全部者的組名
TTY    啓動進程的終端名。不是從終端啓動的進程則顯示爲?
PR    優先級
NInice     值。負值表示高優先級，正值表示低優先級
P    最後使用的CPU，僅在多CPU環境下有意義
%CPU    上次更新到如今的CPU時間佔用百分比
TIME    進程使用的CPU時間總計，單位秒
TIME+    進程使用的CPU時間總計，單位1/100秒
%MEM    進程使用的物理內存百分比
VIRT    進程使用的虛擬內存總量，單位kb。VIRT=SWAP+RES
SWAP    進程使用的虛擬內存中，被換出的大小，單位kb。
RES    進程使用的、未被換出的物理內存大小，單位kb。RES=CODE+DATA
CODE    可執行代碼佔用的物理內存大小，單位kb
DATA    可執行代碼之外的部分(數據段+棧)佔用的物理內存大小，單位kb
SHR    共享內存大小，單位kb
nFLT    頁面錯誤次數
nDRT    最後一次寫入到如今，被修改過的頁面數。

top 也是個挺不錯的程序觀察工具！但不一樣於 ps 是靜態的結果輸出， top 這個程序能夠持續的監測 (monitor) 整個系統的程序工做狀態，例如上面的範例一所示啊！ 在預設的狀況下，每次更新程序資源的時間爲5 秒，不過，可使用 -d 來進行修改。 top 主要分爲兩個畫面，上面的畫面爲整個系統的資源使用狀態，基本上總共有六行， 顯示的內容依序是： • 第一行：顯示系統已啓動的時間、目前上線人數、系統總體的負載(load)。 比較須要注意的是系統的負載，三個數據分別表明1,5,10 分鐘的平均負載。 通常來講，這個負載值應該不太可能超過1 纔對，除非您的系統很忙碌。 若是持續高於5 的話，那麼.....仔細的看看究竟是那個程序在影響總體系統吧！ • 第二行：顯示的是目前的觀察程序數量，比較須要注意的是最後的 zombie 那個數值，若是不是0 ，嘿嘿！好好看看究竟是那個 process 變成疆屍了吧？！ • 第三行：顯示的是CPU 的總體負載，每一個項目可以使用 ? 查閱。須要觀察的是 id (idle) 的數值，通常來講，他應該要接近100% 纔好，表示系統不多資源被使用啊！ ^_^。 • 第四行與第五行：表示目前的物理內存與虛擬內存 (Mem/Swap) 的使用狀況。 • 第六行：這個是當在 top 程序當中輸入指令時，顯示狀態的地方。 例如範例四就是一個簡單的使用例子。 至於 top 底下的畫面，則是每一個 process 使用的資源狀況。比較須要注意的是： •PID ：每一個 process 的ID 啦！ •USER：該 process 所屬的使用者； •PR ：Priority 的簡寫，程序的優先執行順序，越小越早被執行； •NI ：Nice 的簡寫，與 Priority 有關，也是越小越早被執行； • %CPU：CPU 的使用率； • %MEM：內存的使用率； •TIME+：CPU 使用時間的累加； 通常來講，若是鳥哥想要找出最損耗CPU 資源的那個程序時，大多使用的就是 top 這支程序啦！而後強制以CPU 使用資源來排序 (在 top 當中按下P 便可)， 就能夠很快的知道啦！ ^_^。多多愛用這個好用的東西喔！

Load 負載

Load ：對計算機幹活多少的度量,簡單的說是進程隊列的長度。（The system Load is a measure of the amount of work that a compute system is doing）

Load Average 就是一段時間（1分鐘、5分鐘、15分鐘）內平均Load。

【Load查看指令】
w

uptime

procinfo

top

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

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

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

vmstat查看系統負載

查看系統負載vmstat
$vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd     free   buff        cache    si   so    bi    bo   in     cs  us sy id wa
16  0      0 335916  56216 2657880    0    0     8     8  455  400 90  1  9  0

##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輸出來分析。

istat查看磁盤負載

查看磁盤負載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。

cat /proc/cpuinfo

CPU嘛，重點了解的就是幾顆,幾核，是否支持超線程？(何爲物理CPU,邏輯CPU，超線程？）

processor：3 系統中邏輯處理核的編號。
對於單核處理器，則可認爲是其CPU編號，對於多核處理器則能夠是物理核、或者使用超線程技術虛擬的邏輯核
physical id:0 物理封裝的惟一標識符
siblings ：16 一個物理封裝中邏輯處理器的數量
core id:3 一個物理封裝中每一個內核的id
cpu cores：8 一個物理封裝中的內核數量

1.擁有相同physical id的全部邏輯處理器共享同一個物理插座。每一個physical id表明一個惟一的物理封裝，即一顆CPU.

2.Siblings表示位於一個物理封裝的CPU上邏輯CPU的個數。

3.每一個core id 均表明一個惟一的處理器內核，全部帶有相同core id 的邏輯CPU均位於同一處理器內核上。4.若是有一個以上邏輯CPU有用相同的core id和physical id ，則說明系統支持超線程（HT）技術。

5.若是有兩個或兩個以上的邏輯CPU擁有相同的physical id ，可是core id不一樣，則說明這是一個多內核處理器，cpu cores字段也能夠表示是否支持多內核

1.邏輯CPU個數:# cat /proc/cpuinfo | grep 「processor」 | wc –l

2.物理CPU個數：# cat /proc/cpuinfo | grep 「physical id」 | sort | uniq | wc –l

3.每一個物理cpu中core的個數:# cat /proc/cpuinfo | grep 「cpu cores」 | wc –l

4.是否支持超線程？若是兩個邏輯CPU具備相同的「core id」，那麼說明超線程是打開的。

5.每一個物理CPU中邏輯CPU的個數: # cat /proc/cpuinfo | grep 「siblings」