系统性能监控
http://blog.csdn.net/ithomer/article/details/6129177
top進(jìn)入視圖
top視圖 01
【top視圖 01】是剛進(jìn)入top的基本視圖，我們來結(jié)合這個視圖講解各個數(shù)據(jù)的含義。
第一行：
10:01:23 — 當(dāng)前系統(tǒng)時間
126 days, 14:29 — 系統(tǒng)已經(jīng)運(yùn)行了126天14小時29分鐘（在這期間沒有重啟過）
2 users — 當(dāng)前有2個用戶登錄系統(tǒng)
load average: 1.15, 1.42, 1.44 — load average后面的三個數(shù)分別是1分鐘、5分鐘、15分鐘的負(fù)載情況。
load average數(shù)據(jù)是每隔5秒鐘檢查一次活躍的進(jìn)程數(shù)，然后按特定算法計算出的數(shù)值。如果這個數(shù)除以邏輯CPU的數(shù)量，結(jié)果高于5的時候就表明系統(tǒng)在超負(fù)荷運(yùn)轉(zhuǎn)了。
第二行：
Tasks — 任務(wù)（進(jìn)程），系統(tǒng)現(xiàn)在共有183個進(jìn)程，其中處于運(yùn)行中的有1個，182個在休眠（sleep），stoped狀態(tài)的有0個，zombie狀態(tài)（僵尸）的有0個。
第三行：cpu狀態(tài)
6.7% us — 用戶空間占用CPU的百分比。
0.4% sy — 內(nèi)核空間占用CPU的百分比。
0.0% ni — 改變過優(yōu)先級的進(jìn)程占用CPU的百分比
92.9% id — 空閑CPU百分比
0.0% wa — IO等待占用CPU的百分比
0.0% hi — 硬中斷（Hardware IRQ）占用CPU的百分比
0.0% si — 軟中斷（Software Interrupts）占用CPU的百分比
在這里CPU的使用比率和windows概念不同，如果你不理解用戶空間和內(nèi)核空間，需要充充電了。
第四行：內(nèi)存狀態(tài)
8306544k total — 物理內(nèi)存總量（8GB）
7775876k used — 使用中的內(nèi)存總量（7.7GB）
530668k free — 空閑內(nèi)存總量（530M）
79236k buffers — 緩存的內(nèi)存量 （79M）
第五行：swap交換分區(qū)
2031608k total — 交換區(qū)總量（2GB）
2556k used — 使用的交換區(qū)總量（2.5M）
2029052k free — 空閑交換區(qū)總量（2GB）
4231276k cached — 緩沖的交換區(qū)總量（4GB）
這里要說明的是不能用windows的內(nèi)存概念理解這些數(shù)據(jù)，如果按windows的方式此臺服務(wù)器“危矣”：8G的內(nèi)存總量只剩下530M的可用內(nèi)存。Linux的內(nèi)存管理有其特殊性，復(fù)雜點需要一本書來說明，這里只是簡單說點和我們傳統(tǒng)概念（windows）的不同。
第四行中使用中的內(nèi)存總量（used）指的是現(xiàn)在系統(tǒng)內(nèi)核控制的內(nèi)存數(shù)，空閑內(nèi)存總量（free）是內(nèi)核還未納入其管控范圍的數(shù)量。納入內(nèi)核管理的內(nèi)存不見得都在使用中，還包括過去使用過的現(xiàn)在可以被重復(fù)利用的內(nèi)存，內(nèi)核并不把這些可被重新使用的內(nèi)存交還到free中去，因此在linux上free內(nèi)存會越來越少，但不用為此擔(dān)心。
如果出于習(xí)慣去計算可用內(nèi)存數(shù)，這里有個近似的計算公式：第四行的free + 第四行的buffers + 第五行的cached，按這個公式此臺服務(wù)器的可用內(nèi)存：530668+79236+4231276 = 4.7GB。
Mem: ?65981420k total, 58765916k used, ?7215504k free, ? ?73828k buffers
? ? ? ?Swap: ?8393952k total, ?5999084k used, ?2394868k free, 24735212k cached
也可以用free查看內(nèi)存剩余：
? ? ? ? ? ? ?total ? ? ? used ? ? ? free ? ? shared ? ?buffers ? ? cached
Mem: ? ? ?65981420 ? 58916032 ? ?7065388 ? ? ? ? ?0 ? ? ?75036 ? 24772128
-/+ buffers/cache: ? 34068868 ? 31912552
Swap: ? ? ?8393952 ? ?5999084 ? ?2394868
?31912552 =?7065388 +?75036 + ? 24772128
對于內(nèi)存監(jiān)控，在top里我們要時刻監(jiān)控第五行swap交換分區(qū)的used，如果這個數(shù)值在不斷的變化，說明內(nèi)核在不斷進(jìn)行內(nèi)存和swap的數(shù)據(jù)交換，這是真正的內(nèi)存不夠用了。
第六行是空行
第七行以下：各進(jìn)程（任務(wù)）的狀態(tài)監(jiān)控
PID — 進(jìn)程id
USER — 進(jìn)程所有者
PR — 進(jìn)程優(yōu)先級
NI — nice值。負(fù)值表示高優(yōu)先級，正值表示低優(yōu)先級
VIRT — 進(jìn)程使用的虛擬內(nèi)存總量，單位kb。VIRT=SWAP+RES
RES — 進(jìn)程使用的、未被換出的物理內(nèi)存大小，單位kb。RES=CODE+DATA
SHR — 共享內(nèi)存大小，單位kb
S — 進(jìn)程狀態(tài)。D=不可中斷的睡眠狀態(tài) R=運(yùn)行 S=睡眠 T=跟蹤/停止 Z=僵尸進(jìn)程
%CPU — 上次更新到現(xiàn)在的CPU時間占用百分比
%MEM — 進(jìn)程使用的物理內(nèi)存百分比
TIME+ — 進(jìn)程使用的CPU時間總計，單位1/100秒
COMMAND — 進(jìn)程名稱（命令名/命令行）
多U多核CPU監(jiān)控
在top基本視圖中，按鍵盤數(shù)字“1”，可監(jiān)控每個邏輯CPU的狀況：
top視圖 02
觀察上圖，服務(wù)器有16個邏輯CPU，實際上是4個物理CPU。
cat /proc/cpuinfo可以看到實際的物理cpu數(shù)目
us??--??User CPU time
??????????The time the CPU has spent running users' processes that are not niced.
??????????非nice過的用戶程序所占用的百分比。
sy??--??System CPU time
??????????The time the CPU has spent running the kernel and its processes.
??????????kernel和系統(tǒng)調(diào)用所占用的百分比。
ni??--??Nice CPU time
??????????The time the CPU has spent running users' proccess that have been niced.
??????????被nice過的用戶程序所占百分比。
wa??--??iowait
??????????Amount of time the CPU has been waiting for I/O to complete.
??????????等待IO操作時所占百分比。
hi??--??Hardware IRQ
??????????The amount of time the CPU has been servicing hardware interrupts.
??????????處理硬件中斷所用百分比。
si??--??Software Interrupts
??????????The amount of time the CPU has been servicing software interrupts.
??????????處理軟件中斷所用百分比。
st??--??Steal Time
??????????The amount of CPU 'stolen' from this virtual machine by the hypervisor for other tasks (such as running??another??vir鈥?
??????????tual machine).
id表示cpu空閑率，越高越好
us用戶使用cpu時間
wa是等待IO操作的比率，越低越好
?使用vmstat查看CPU狀況：
使用top查看cpu狀態(tài)時，可以看到CPU在哪些狀態(tài)下占用較多。以及哪些Process占用較多CPU。
而使用vmstat查看，在CPU實用方面，則有其它信息可看。
$vmstat 1????//每隔1s 輸出一次結(jié)果
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
?r??b???swpd???free???buff??cache???si???so????bi????bo???in???cs?us sy id wa st
?
CPU項目下的：us sy id wa st與top下的相似。
procs下則有幾項有新意：
r:in?run?queue
b:blocked?for?resources?I/O,?paging?etc
如果r 的值持續(xù)較大，且連續(xù)超過CPU Core的數(shù)量，則表明CPU資源嚴(yán)重不足，有很多process在等待CPU, CPU計算能力已經(jīng)成為瓶頸。
?
?
?
2. 查看其它IO負(fù)載：
當(dāng)使用top或者vmstat發(fā)現(xiàn)CPU wa時間多時。 vmstat中發(fā)現(xiàn)b列一直比較大的話（超過CPU Core）。則表明IO性能不佳。
進(jìn)程字段排序
默認(rèn)進(jìn)入top時，各進(jìn)程是按照CPU的占用量來排序的，在【top視圖 01】中進(jìn)程ID為14210的java進(jìn)程排在第一（cpu占用100%），進(jìn)程ID為14183的java進(jìn)程排在第二（cpu占用12%）。可通過鍵盤指令來改變排序字段，比如想監(jiān)控哪個進(jìn)程占用MEM最多，我一般的使用方法如下：
1. 敲擊鍵盤“b”（打開/關(guān)閉加亮效果），top的視圖變化如下：
top視圖 03
我們發(fā)現(xiàn)進(jìn)程id為10704的“top”進(jìn)程被加亮了，top進(jìn)程就是視圖第二行顯示的唯一的運(yùn)行態(tài)（runing）的那個進(jìn)程，可以通過敲擊“y”鍵關(guān)閉或打開運(yùn)行態(tài)進(jìn)程的加亮效果。
2. 敲擊鍵盤“x”（打開/關(guān)閉排序列的加亮效果），top的視圖變化如下：
top視圖 04
可以看到，top默認(rèn)的排序列是“%CPU”。
3. 通過”shift + >”或”shift + <”可以向右或左改變排序列，下圖是按一次”shift + >”的效果圖：
top視圖 05
視圖現(xiàn)在已經(jīng)按照%MEM來排序了。
改變進(jìn)程顯示字段
1. 敲擊“f”鍵，top進(jìn)入另一個視圖，在這里可以編排基本視圖中的顯示字段：
top視圖 06
這里列出了所有可在top基本視圖中顯示的進(jìn)程字段，有”*”并且標(biāo)注為大寫字母的字段是可顯示的，沒有”*”并且是小寫字母的字段是不顯示的。如果要在基本視圖中顯示“CODE”和“DATA”兩個字段，可以通過敲擊“r”和“s”鍵：
top視圖 07
2. “回車”返回基本視圖，可以看到多了“CODE”和“DATA”兩個字段：
top視圖 08
top命令的補(bǔ)充
top命令是Linux上進(jìn)行系統(tǒng)監(jiān)控的首選命令，但有時候卻達(dá)不到我們的要求，比如當(dāng)前這臺服務(wù)器，top監(jiān)控有很大的局限性。這臺服務(wù)器運(yùn)行著websphere集群，有兩個節(jié)點服務(wù)，就是【top視圖 01】中的老大、老二兩個java進(jìn)程，top命令的監(jiān)控最小單位是進(jìn)程，所以看不到我關(guān)心的java線程數(shù)和客戶連接數(shù)，而這兩個指標(biāo)是java的web服務(wù)非常重要的指標(biāo)，通常我用ps和netstate兩個命令來補(bǔ)充top的不足。
監(jiān)控java線程數(shù)：
ps -eLf | grep java | wc -l
監(jiān)控網(wǎng)絡(luò)客戶連接數(shù)：
netstat -n | grep tcp | grep 偵聽端口 | wc -l
上面兩個命令，可改動grep的參數(shù)，來達(dá)到更細(xì)致的監(jiān)控要求。
在Linux系統(tǒng)“一切都是文件”的思想貫徹指導(dǎo)下，所有進(jìn)程的運(yùn)行狀態(tài)都可以用文件來獲取。系統(tǒng)根目錄/proc中，每一個數(shù)字子目錄的名字都是運(yùn)行中的進(jìn)程的PID，進(jìn)入任一個進(jìn)程目錄，可通過其中文件或目錄來觀察進(jìn)程的各項運(yùn)行指標(biāo)，例如task目錄就是用來描述進(jìn)程中線程的，因此也可以通過下面的方法獲取某進(jìn)程中運(yùn)行中的線程數(shù)量（PID指的是進(jìn)程ID）：
ls /proc/PID/task | wc -l
在linux中還有一個命令pmap，來輸出進(jìn)程內(nèi)存的狀況，可以用來分析線程堆棧：
pmap PID
?
負(fù)載均值在 uptime 或者 top 命令中可以看到，它們可能會顯示成這個樣子：
load average: 0.09, 0.05, 0.01
很多人會這樣理解負(fù)載均值：三個數(shù)分別代表不同時間段的系統(tǒng)平均負(fù)載（一分鐘、五 分鐘、以及十五分鐘），它們的數(shù)字當(dāng)然是越小越好。數(shù)字越高，說明服務(wù)器的負(fù)載越 大，這也可能是服務(wù)器出現(xiàn)某種問題的信號。
而事實不完全如此，是什么因素構(gòu)成了負(fù)載均值的大小，以及如何區(qū)分它們目前的狀況是 “好”還是“糟糕”？什么時候應(yīng)該注意哪些不正常的數(shù)值？
回答這些問題之前，首先需要了解下這些數(shù)值背后的些知識。我們先用最簡單的例子說明， 一臺只配備一塊單核處理器的服務(wù)器。
行車過橋
一只單核的處理器可以形象得比喻成一條單車道。設(shè)想下，你現(xiàn)在需要收取這條道路的過橋 費(fèi) - 忙于處理那些將要過橋的車輛。你首先當(dāng)然需要了解些信息，例如車輛的載重、以及還有多少車輛正在等待過橋。如果前面沒有車輛在等待，那么你可以告訴后面的司機(jī)通過。 如果車輛眾多，那么需要告知他們可能需要稍等一會。
因此，需要些特定的代號表示目前的車流情況，例如：
0.00 表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的，總而言之很通暢，過往的車輛可以絲毫不用等待的通過。
1.00 表示剛好是在這座橋的承受范圍內(nèi)。 這種情況不算糟糕，只是車流會有些堵，不過這種情況可能會造成交通越來越慢。
超過 1.00，那么說明這座橋已經(jīng)超出負(fù)荷，交通嚴(yán)重的擁堵。 那么情況有多糟糕？ 例如 2.00 的情況說明車流已經(jīng)超出了橋所能承受的一倍，那么將有多余過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了，說明這座橋基本上已經(jīng)快承受不了，還有超出橋負(fù)載兩倍多的車輛正在等待。
上面的情況和處理器的負(fù)載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程 的實際時間。Unix?系統(tǒng)定義的進(jìn)程運(yùn)行時長為所有處理器內(nèi)核的處理時間加上線程 在隊列中等待的時間。
和收過橋費(fèi)的管理員一樣，你當(dāng)然希望你的汽車（操作）不會被焦急的等待。所以，理想狀態(tài) 下，都希望負(fù)載平均值小于 1.00 。當(dāng)然不排除部分峰值會超過 1.00，但長此以往保持這 個狀態(tài)，就說明會有問題，這時候你應(yīng)該會很焦急。
“所以你說的理想負(fù)荷為 1.00 ？”
嗯，這種情況其實并不完全正確。負(fù)荷 1.00 說明系統(tǒng)已經(jīng)沒有剩余的資源了。在實際情況中 ，有經(jīng)驗的系統(tǒng)管理員都會將這條線劃在 0.70：
“需要進(jìn)行調(diào)查法則”： 如果長期你的系統(tǒng)負(fù)載在 0.70 上下，那么你需要在事情變得更糟糕之前，花些時間了解其原因。
“現(xiàn)在就要修復(fù)法則”：1.00 。 如果你的服務(wù)器系統(tǒng)負(fù)載長期徘徊于 1.00，那么就應(yīng)該馬上解決這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。
“凌晨三點半鍛煉身體法則”：5.00。 如果你的服務(wù)器負(fù)載超過了 5.00 這個數(shù)字，那么你將失去你的睡眠，還得在會議中說明這情況發(fā)生的原因，總之千萬不要讓它發(fā)生。
那么多個處理器呢？我的均值是 3.00，但是系統(tǒng)運(yùn)行正常！
哇喔，你有四個處理器的主機(jī)？那么它的負(fù)載均值在 3.00 是很正常的。
在多處理器系統(tǒng)中，負(fù)載均值是基于內(nèi)核的數(shù)量決定的。以 100% 負(fù)載計算，1.00 表示單個處理器，而 2.00 則說明有兩個雙處理器，那么 4.00 就說明主機(jī)具有四個處理器。
回到我們上面有關(guān)車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道 1.00 情況中，說明這橋梁已經(jīng)被車塞滿了。而在雙處理器系統(tǒng)中，這意味著多出了一倍的 負(fù)載，也就是說還有 50% 的剩余系統(tǒng)資源 - 因為還有另外條車道可以通行。
所以，單處理器已經(jīng)在負(fù)載的情況下，雙處理器的負(fù)載滿額的情況是 2.00，它還有一倍的資源可以利用。
多核與多處理器
先脫離下主題，我們來討論下多核心處理器與多處理器的區(qū)別。從性能的角度上理解，一臺主 機(jī)擁有多核心的處理器與另臺擁有同樣數(shù)目的處理性能基本上可以認(rèn)為是相差無幾。當(dāng)然實際 情況會復(fù)雜得多，不同數(shù)量的緩存、處理器的頻率等因素都可能造成性能的差異。
但即便這些因素造成的實際性能稍有不同，其實系統(tǒng)還是以處理器的核心數(shù)量計算負(fù)載均值 。這使我們有了兩個新的法則：
“有多少核心即為有多少負(fù)荷”法則： 在多核處理中，你的系統(tǒng)均值不應(yīng)該高于處理器核心的總數(shù)量。
“核心的核心”法則： 核心分布在分別幾個單個物理處理中并不重要，其實兩顆四核的處理器 等于 四個雙核處理器 等于 八個單處理器。所以，它應(yīng)該有八個處理器內(nèi)核。
審視我們自己
讓我們再來看看 uptime 的輸出
~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
這是個雙核處理器，從結(jié)果也說明有很多的空閑資源。實際情況是即便它的峰值會到 1.7，我也從來沒有考慮過它的負(fù)載問題。
那么，怎么會有三個數(shù)字的確讓人困擾。我們知道，0.65、0.42、0.36 分別說明上一分鐘、最后五分鐘以及最后十五分鐘的系統(tǒng)負(fù)載均值。那么這又帶來了一個問題：
我們以哪個數(shù)字為準(zhǔn)？一分鐘？五分鐘？還是十五分鐘？
其實對于這些數(shù)字我們已經(jīng)談?wù)摿撕芏?#xff0c;我認(rèn)為你應(yīng)該著眼于五分鐘或者十五分鐘的平均數(shù) 值。坦白講，如果前一分鐘的負(fù)載情況是 1.00，那么仍可以說明認(rèn)定服務(wù)器情況還是正常的。 但是如果十五分鐘的數(shù)值仍然保持在 1.00，那么就值得注意了（根據(jù)我的經(jīng)驗，這時候你應(yīng)該增加的處理器數(shù)量了）。
總結(jié)
- 上一篇： android Activity布局初步
- 下一篇： io监控