linux性能分析

⑴ linux中查看虛擬內存和cpu佔用率的命令是什麼

top，free，cat/proc/meminfo，cat/proc/cpuinfo。

[root@centerlisdbproc]#dmidecode|grep-A16"MemoryDevice"|more[objectObject]。

查看內存使用情況：cat/proc/meminfo，查看CPU使用情況：cat /proc/cpuinfo。

在系統維護的過程中，隨時可能有需要查看 CPU 使用率，並根據相應信息分析系統狀況的需要。在 CentOS 中，可以通過 top 命令來查看 CPU 使用狀況。

運行 top 命令後，CPU 使用狀態會以全屏的方式顯示，並且會處在對話的模式 -- 用基於 top 的命令，可以控制顯示方式等等。退出 top 的命令為 q （在 top 運行中敲 q 鍵一次）。

top命令是Linux下常用的性能分析工具，能夠實時顯示系統中各個進程的資源佔用狀況，類似於Windows的任務管理器。

可以直接使用top命令後，查看%MEM的內容。可以選擇按進程查看或者按用戶查看，如想查看oracle用戶的進程內存使用情況的話可以使用如下的命令：$ top -u oracle。

(1)linux性能分析擴展閱讀：

一、查看內存佔用：

1、free

# free -m。

以MB為單位顯示內存使用情況。

# free -h。

以GB為單位顯示內存使用情況。

# free -t。

以總和的形式查詢內存的使用信息。

# free -s 5。

周期性的查詢內存使用信息。

每5秒執行一次命令。

二、查看CPU使用情況：

1、top。

top後鍵入P看一下誰佔用最大。

# top -d 5。

周期性的查詢CPU使用信息。

每5秒刷新一次。

2、ps auxw（查看本機的進程所佔cpu和mem的百分比情況）。

使用"ps auxw" 可以查看到本機的進程所佔cpu和mem的百分比情況。

# ps auxw | head -1

%CPU 進程的cpu佔用率。

%MEM 進程的內存佔用率。

3、查看本機所有進程的CPU佔比之和。

# cat cpu_per.sh

三、查看cpu信息（信息記錄在/proc/cpuinfo中）

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

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

⑵ 怎樣分析linux的性能指標

LR

監控

UNIX/Linux

系統方法

一、准備工作：

1.

可以通過兩種方法驗證伺服器上是否配置

rstatd

守護程序：

①使用

rup

命令，它用於報告計算機的各種統計信息，其中就包括

rstatd

的配置信息。使用命

令

rup

10.130.61.203,

此處

10.130.61.203

是要監視的

linux/Unix

伺服器的

IP

，如果該命令返回相關的

統計信息。則表示已經配置並且激活了

rstatd

守護進程；若未返回有意義的統計信息，或者出現一

條錯誤報告，則表示

rstatd

守護進程尚未被配置或有問題。

②使用

find

命令

#find / -name rpc.rstatd,

該命令用於查找系統中是否存在

rpc.rstatd

文件，如果沒有，說明系統沒

有安裝

rstatd

守護程序。

2

．

linux

需要下載

3

個包：

（

1

）

rpc.rstatd-4.0.1.tar.gz

（

2

）

rsh-0.17-14.i386.rpm

（

3

）

rsh-server-0.17-14.i386.rpm

3

．下載並安裝

rstatd

如果伺服器上沒有安裝

rstatd

程序（一般來說

LINUX

都沒有安裝）

，需要下載一個包才有這個服

務

,

包

名

字

是

rpc.rstatd-4.0.1.tar.gz.

這

是

一

個

源

碼

,

需

要

編

譯

,

下

載

並

安

裝

rstatd

（

可

以

在

http://sourceforge.net/projects/rstatd

這個地址下載）下載後，開始安裝，安裝步驟如下：

tar -xzvf rpc.rstatd-4.0.1.tar.gz

cd rpc.rstatd-4.0.1/

./configure

—配置操作

make

—進行編譯

make install

—開始安裝

rpc.rstatd

—啟動

rstatd

進程

「

rpcinfo -p

」命令來查看當前系統是否已經啟動了

rstatd

守護進程

只要保證

Linux

機器上的進程里有

rstatd

和

xinetd

這二個服務就可以用

LR

去監視了，通過以下

兩點可以檢查是否啟動：

1

）檢查是否啟動

: rsh server

監聽的

TCP

是

514

。

[root@mg04 root]# netstat -an |grep 514

tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN

如果能看到

514

在監聽說明

rsh

伺服器已經啟動。

2

）檢查是否啟動

: rstatd

輸入命令

: rpcinfo -p

如果能看到類似如下信息：

程序版本協議埠

100001

5

udp

937

rstatd

100001

4

udp

937

rstatd

100001

3

udp

937

rstatd

100001

2

udp

937

rstatd

100001

1

udp

937

rstatd

那就說明

rstatd

服務啟動了

,(

當然這里也可以用

ps ax

代替

)

4

．安裝

rsh

和

rsh-server

兩個服務包方法

a.

卸載

rsh

# rpm

–

q

rsh----------

查看版本號

# rpm

-e

版本號

---------

卸載該版本。

b

．安裝

# rpm

–

ivh rsh-0.17-14.i386.rpm rsh-server-0.17-14.i386.rpm

在啟動

rpc.rstatd

時，

會報錯

「

Cannot register service: RPC: Unable to receive; errno = Ction refused

」

。

解決方法如下：

# /etc/init.d/portmap start

# /etc/init.d/nfs start

然後再次啟動

rpc.rstatd

就好了。

5

．安裝

xinetd

方法：

①查看

xinetd

服務：

[root@localhost ~]# rpm -q xinetd

xinetd-2.3.14-10.el5

②安裝

xinetd

服務：

[root@localhost ~]# yum install xinetd

如果安裝不起

xinetd

服務，執行下列操作命令後再次執行

yum install xinetd

命令進行安裝：

yum clean packages

清除緩存目錄下的軟體包

yum clean headers

清除緩存目錄下的

headers

yum clean oldheaders

清除緩存目錄下舊的

headers

yum clean, yum clean all (= yum clean packages; yum clean oldheaders)

清除緩存目錄下的軟體包

及舊的

headers

。

6

．啟動

xinetd

服務：

在有的系統中，通過如下命令重啟：

# service xinetd reload

# /sbin/service xinetd rstart

在

suse linux

中如下操作：

cd /etc/init.d/xinetd restart

2

）

安裝完成後配置

rstatd

目標守護進程

xinetd,

它的主配置文件是

/etc/xinetd.conf ,

它裡面內容是

一些如下的基本信息：

#

# xinetd.conf

#

# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.

# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.

#

defaults

{

log_type

= FILE /var/log/xinetd.log

log_on_success = HOST EXIT DURATION

log_on_failure = HOST ATTEMPT

#

only_from

= localhost

instances

= 30

cps

= 50 10

#

# The specification of an interface is interesting, if we are on a firewall.

# For example, if you only want to provide services from an internal

# network interface, you may specify your internal interfaces IP-Address.

#

#

interface

= 127.0.0.1

}

includedir /etc/xinetd.d

我們這里需要修改的是

/etc/xinetd.d/

下的三個

conf

文件

rlogin

,rsh,rexec

這三個配置文件

,

打這

三個文件里的

disable = yes

都改成

disable = no ( disabled

用在默認的

{}

中禁止服務

)

或是把

# default:

off

都設置成

on

這個的意思就是在

xinetd

啟動的時候默認都啟動上面的三個服務

!

說明：我自己在配置時，沒有

disable = yes

這項，我就將

# default: off

改為：

default: on

，重啟後

(cd /etc/init.d/./xinetd restart

）通過

netstat -an |grep 514

查看，沒有返回。然後，我就手動在三個文

件中最後一行加入

disable

=

no

，再重啟

xinetd

，再使用

netstat

-an

|grep

514

查看，得到

tcp

0

0

0.0.0.0:514 0.0.0.0:* LISTEN

結果，表明

rsh

伺服器已經啟動。

看到網上有的地方說使用如下命令：

# service xinetd reload

# /sbin/service xinetd rstart

不知道是在什麼系統用的。

二、監控

linux

資源：

在

controller

中，將

System resource Graphs

中的

Unix resources

拖到右側的監控區域中，並單擊

滑鼠右鍵選擇「

Add

Measurements

」

,

在彈出的對話框中輸入被監控的

linux

系統的

IP

地址，然後選

擇需要監控的性能指標，並點擊「確定」

，出現如下結果：

Monitor name :UNIX Resources. Cannot initialize the monitoring on 10.10.15.62.

Error while creating the RPC client. Ensure that the machine can be connected and that it runs the

rstat daemon (use rpcinfo utility for this verification).

Detailed error: RPC: Failed to create RPC client.

RPC-TCP: Failed to establish RPC server address.

RPC-TCP: Failed to communicate with the portmapper on host '10.10.15.62'.

RPC: RPC call failed.

RPC-TCP: recv()/recvfrom() failed.

RPC-TCP: Timeout reached. (entry point: CFactory::Initialize). [MsgId: MMSG-47190]

檢查原因，發現是

Linux

系統中的防火牆開啟了並且阻擋了

LoadRunner

監控

Linux

系統的資源，

因此要將防火牆關閉。

關閉防火牆：

[root@localhost ~]# /etc/init.d/iptables stop;

三、監控

UNIX

lr

監控

UNIX

，

UNIX

先啟動一

rstatd

服務

以下是在

IBM AIX

系統中啟動

rstatd

服務的方法：

1

．使用

telnet

以

root

用戶的身份登錄入

AIX

系統

2

．在命令行提示符下輸入：

vi /etc/inetd.conf

3

．查找

rstatd

，找到

#rstatd

sunrpc_udp

udp

wait

root /usr/sbin/rpc.rstatd rstatd 100001 1-3

4

、將

#

去掉

5

、

:wq

保存修改結果

6

、命令提示符下輸入：

refresh

–

s inetd

重新啟動服務。

這樣使用

loadrunner

就可以監視

AIX

系統的性能情況了。

註：在

HP UNIX

系統上編輯完

inetd.conf

後，重啟

inetd

服務需要輸入

inetd -c

UNIX

上也可以用

rup

命令查看

rstatd

程序是否被配置並激活

若

rstatd

程序已經運行，

重啟時，

先查看進程

ps -ef |grep inet

，

然後殺掉進程，

再

refresh

–

s inetd

進行重啟。

⑶ 如何用九條命令在一分鍾內檢查Linux伺服器性能

一、uptime命令

這個命令可以快速查看機器的負載情況。在Linux系統中，這些數據表示等待CPU資源的進程和阻塞在不可中斷IO進程（進程狀態為D）的數量。這些數據可以讓我們對系統資源使用有一個宏觀的了解。

命令的輸出分別表示1分鍾、5分鍾、15分鍾的平均負載情況。通過這三個數據，可以了解伺服器負載是在趨於緊張還是趨於緩解。如果1分鍾平均負載很高，而15分鍾平均負載很低，說明伺服器正在命令高負載情況，需要進一步排查CPU資源都消耗在了哪裡。反之，如果15分鍾平均負載很高，1分鍾平均負載較低，則有可能是CPU資源緊張時刻已經過去。

上面例子中的輸出，可以看見最近1分鍾的平均負載非常高，且遠高於最近15分鍾負載，因此我們需要繼續排查當前系統中有什麼進程消耗了大量的資源。可以通過下文將會介紹的vmstat、mpstat等命令進一步排查。

二、dmesg命令

該命令會輸出系統日誌的最後10行。示例中的輸出，可以看見一次內核的oom kill和一次TCP丟包。這些日誌可以幫助排查性能問題。千萬不要忘了這一步。

三、vmstat命令

vmstat(8) 命令，每行會輸出一些系統核心指標，這些指標可以讓我們更詳細的了解系統狀態。後面跟的參數1，表示每秒輸出一次統計信息，表頭提示了每一列的含義，這幾介紹一些和性能調優相關的列：

r：等待在CPU資源的進程數。這個數據比平均負載更加能夠體現CPU負載情況，數據中不包含等待IO的進程。如果這個數值大於機器CPU核數，那麼機器的CPU資源已經飽和。

free：系統可用內存數（以千位元組為單位），如果剩餘內存不足，也會導致系統性能問題。下文介紹到的free命令，可以更詳細的了解系統內存的使用情況。

si，so：交換區寫入和讀取的數量。如果這個數據不為0，說明系統已經在使用交換區（swap），機器物理內存已經不足。

us, sy, id, wa, st：這些都代表了CPU時間的消耗，它們分別表示用戶時間（user）、系統（內核）時間（sys）、空閑時間（idle）、IO等待時間（wait）和被偷走的時間（stolen，一般被其他虛擬機消耗）。

上述這些CPU時間，可以讓我們很快了解CPU是否出於繁忙狀態。一般情況下，如果用戶時間和系統時間相加非常大，CPU出於忙於執行指令。如果IO等待時間很長，那麼系統的瓶頸可能在磁碟IO。

示例命令的輸出可以看見，大量CPU時間消耗在用戶態，也就是用戶應用程序消耗了CPU時間。這不一定是性能問題，需要結合r隊列，一起分析。

四、mpstat命令

該命令可以顯示每個CPU的佔用情況，如果有一個CPU佔用率特別高，那麼有可能是一個單線程應用程序引起的。

五、pidstat命令

pidstat命令輸出進程的CPU佔用率，該命令會持續輸出，並且不會覆蓋之前的數據，可以方便觀察系統動態。如上的輸出，可以看見兩個JAVA進程佔用了將近1600%的CPU時間，既消耗了大約16個CPU核心的運算資源。

六、iostat命令

r/s, w/s, rkB/s, wkB/s：分別表示每秒讀寫次數和每秒讀寫數據量（千位元組）。讀寫量過大，可能會引起性能問題。

await：IO操作的平均等待時間，單位是毫秒。這是應用程序在和磁碟交互時，需要消耗的時間，包括IO等待和實際操作的耗時。如果這個數值過大，可能是硬體設備遇到了瓶頸或者出現故障。

avgqu-sz：向設備發出的請求平均數量。如果這個數值大於1，可能是硬體設備已經飽和（部分前端硬體設備支持並行寫入）。

%util：設備利用率。這個數值表示設備的繁忙程度，經驗值是如果超過60，可能會影響IO性能（可以參照IO操作平均等待時間）。如果到達100%，說明硬體設備已經飽和。

如果顯示的是邏輯設備的數據，那麼設備利用率不代表後端實際的硬體設備已經飽和。值得注意的是，即使IO性能不理想，也不一定意味這應用程序性能會不好，可以利用諸如預讀取、寫緩存等策略提升應用性能。

七、free命令

free命令可以查看系統內存的使用情況，-m參數表示按照兆位元組展示。最後兩列分別表示用於IO緩存的內存數，和用於文件系統頁緩存的內存數。需要注意的是，第二行-/+ buffers/cache，看上去緩存佔用了大量內存空間。

這是Linux系統的內存使用策略，盡可能的利用內存，如果應用程序需要內存，這部分內存會立即被回收並分配給應用程序。因此，這部分內存一般也被當成是可用內存。

如果可用內存非常少，系統可能會動用交換區（如果配置了的話），這樣會增加IO開銷（可以在iostat命令中提現），降低系統性能。

八、sar命令

sar命令在這里可以查看網路設備的吞吐率。在排查性能問題時，可以通過網路設備的吞吐量，判斷網路設備是否已經飽和。如示例輸出中，eth0網卡設備，吞吐率大概在22 Mbytes/s，既176 Mbits/sec，沒有達到1Gbit/sec的硬體上限。

sar命令在這里用於查看TCP連接狀態，其中包括：

active/s：每秒本地發起的TCP連接數，既通過connect調用創建的TCP連接；

passive/s：每秒遠程發起的TCP連接數，即通過accept調用創建的TCP連接；

retrans/s：每秒TCP重傳數量；

TCP連接數可以用來判斷性能問題是否由於建立了過多的連接，進一步可以判斷是主動發起的連接，還是被動接受的連接。TCP重傳可能是因為網路環境惡劣，或者伺服器壓

九、top命令

top命令包含了前面好幾個命令的檢查的內容。比如系統負載情況（uptime）、系統內存使用情況（free）、系統CPU使用情況（vmstat）等。因此通過這個命令，可以相對全面的查看系統負載的來源。同時，top命令支持排序，可以按照不同的列排序，方便查找出諸如內存佔用最多的進程、CPU佔用率最高的進程等。

但是，top命令相對於前面一些命令，輸出是一個瞬間值，如果不持續盯著，可能會錯過一些線索。這時可能需要暫停top命令刷新，來記錄和比對數據。

⑷ linux 性能優化-- cpu 切換以及cpu過高

本文先介紹了cpu上下文切換的基礎知識，以及上下文切換的類型（進程，線程等切換）。然後介紹了如何查看cpu切換次數的工具和指標的解釋。同時對日常分析種cpu過高的情況下如何分析和定位的方法做了一定的介紹，使用一個簡單的案例進行分析，先用top，pidstat等工具找出佔用過高的進程id，然後通過分析到底是用戶態cpu過高，還是內核態cpu過高，並用perf 定位到具體的調用函數。（來自極客時間課程學習筆記）

1、多任務競爭CPU，cpu變換任務的時候進行CPU上下文切換(context switch)。CPU執行任務有4種方式：進程、線程、或者硬體通過觸發信號導致中斷的調用。

2、當切換任務的時候，需要記錄任務當前的狀態和獲取下一任務的信息和地址(指針)，這就是上下文的內容。因此，上下文是指某一時間點CPU寄存器(CPU register)和程序計數器(PC)的內容, 廣義上還包括內存中進程的虛擬地址映射信息.

3、上下文切換的過程：

4、根據任務的執行形式，相應的下上文切換，有進程上下文切換、線程上下文切換、以及中斷上下文切換三類。

5、進程和線程的區別：
進程是資源分配和執行的基本單位；線程是任務調度和運行的基本單位。線程沒有資源，進程給指針提供虛擬內存、棧、變數等共享資源，而線程可以共享進程的資源。

6、進程上下文切換：是指從一個進程切換到另一個進程。

(1)進程運行態為內核運行態和進程運行態。內核空間態資源包括內核的堆棧、寄存器等；用戶空間態資源包括虛擬內存、棧、變數、正文、數據等

(2)系統調用(軟中斷)在內核態完成的，需要進行2次CPU上下文切換(用戶空間-->內核空間-->用戶空間)，不涉及用戶態資源，也不會切換進程。

(3)進程是由內核來管理和調度的，進程的切換只能發生在內核態。所以，進程的上下文不僅包括了用戶空間的資源，也包括內核空間資源。

(4)進程的上下文切換過程：

(5)、下列將會觸發進程上下文切換的場景：

7、線程上下文切換：

8、中斷上下文切換
快速響應硬體的事件，中斷處理會打斷進程的正常調度和執行。同一CPU內，硬體中斷優先順序高於進程。切換過程類似於系統調用的時候，不涉及到用戶運行態資源。但大量的中斷上下文切換同樣可能引發性能問題。

重點關注信息：

系統的就緒隊列過長，也就是正在運行和等待 CPU 的進程數過多，導致了大量的上下文切換，而上下文切換又導致了系統 CPU 的佔用率升高。

這個結果中有兩列內容是我們的重點關注對象。一個是 cswch ，表示每秒自願上下文切換（voluntary context switches）的次數，另一個則是 nvcswch ，表示每秒非自願上下文切換（non voluntary context switches）的次數。

linux的中斷使用情況可以從 /proc/interrupts 這個只讀文件中讀取。/proc 實際上是 Linux 的一個虛擬文件系統，用於內核空間與用戶空間之間的通信。/proc/interrupts 就是這種通信機制的一部分，提供了一個只讀的中斷使用情況。

重調度中斷（RES），這個中斷類型表示，喚醒空閑狀態的 CPU 來調度新的任務運行。這是多處理器系統（SMP）中，調度器用來分散任務到不同 CPU 的機制，通常也被稱為處理器間中斷（Inter-Processor Interrupts，IPI）。

這個數值其實取決於系統本身的 CPU 性能。如果系統的上下文切換次數比較穩定，那麼從數百到一萬以內，都應該算是正常的。但當上下文切換次數超過一萬次，或者切換次數出現數量級的增長時，就很可能已經出現了性能問題。這時，需要根據上下文切換的類型，再做具體分析。

比方說：

首先通過uptime查看系統負載，然後使用mpstat結合pidstat來初步判斷到底是cpu計算量大還是進程爭搶過大或者是io過多，接著使用vmstat分析切換次數，以及切換類型，來進一步判斷到底是io過多導致問題還是進程爭搶激烈導致問題。

CPU 使用率相關的重要指標：

性能分析工具給出的都是間隔一段時間的平均 CPU 使用率，所以要注意間隔時間的設置，特別是用多個工具對比分析時，你一定要保證它們用的是相同的間隔時間。比如，對比一下 top 和 ps 這兩個工具報告的 CPU 使用率，默認的結果很可能不一樣，因為 top 默認使用 3 秒時間間隔，而 ps 使用的卻是進程的整個生命周期。

top 和 ps 是最常用的性能分析工具：

這個輸出結果中，第三行 %Cpu 就是系統的 CPU 使用率，top 默認顯示的是所有 CPU 的平均值，這個時候你只需要按下數字 1 ，就可以切換到每個 CPU 的使用率了。繼續往下看，空白行之後是進程的實時信息，每個進程都有一個 %CPU 列，表示進程的 CPU 使用率。它是用戶態和內核態 CPU 使用率的總和，包括進程用戶空間使用的 CPU、通過系統調用執行的內核空間 CPU 、以及在就緒隊列等待運行的 CPU。在虛擬化環境中，它還包括了運行虛擬機佔用的 CPU。

預先安裝 stress 和 sysstat 包，如 apt install stress sysstat。

stress 是一個 Linux 系統壓力測試工具，這里我們用作異常進程模擬平均負載升高的場景。而 sysstat 包含了常用的 Linux 性能工具，用來監控和分析系統的性能。我們的案例會用到這個包的兩個命令 mpstat 和 pidstat。

下面的 pidstat 命令，就間隔 1 秒展示了進程的 5 組 CPU 使用率，

包括：

perf 是 Linux 2.6.31 以後內置的性能分析工具。它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。

第一種常見用法是 perf top，類似於 top，它能夠實時顯示佔用 CPU 時鍾最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示：

輸出結果中，第一行包含三個數據，分別是采樣數（Samples）如2K、事件類型（event）如cpu-clock:pppH和事件總數量（Event count）如：371909314。

第二種常見用法，也就是 perf record 和 perf report。 perf top 雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者後續的分析。而 perf record 則提供了保存數據的功能，保存後的數據，需要你用 perf report 解析展示。

1.啟動docker 運行進程：

2.ab工具測試伺服器性能
ab（apache bench）是一個常用的 HTTP 服務性能測試工具，這里用來模擬 Ngnix 的客戶端。

3.分析過程

CPU 使用率是最直觀和最常用的系統性能指標，在排查性能問題時，通常會關注的第一個指標。所以更要熟悉它的含義，尤其要弄清楚:

這幾種不同 CPU 的使用率。比如說：

碰到 CPU 使用率升高的問題，你可以藉助 top、pidstat 等工具，確認引發 CPU 性能問題的來源；再使用 perf 等工具，排查出引起性能問題的具體函數.

⑸ 怎樣分析linux的性能指標

一、處理器參數
這是一個很簡單的參數，它直觀的描述了每個CPU的利用率。在xSeries架構中，如果CPU的利用率長時間的超過80％，就可能是出現了處理器的瓶頸。
Runable processes
這個值描述了正在准備被執行的進程，在一個持續時間里這個值不應該超過物理CPU數量的10倍，否則CPU方面就可能存在瓶頸。
Blocked
描述了那些因為等待I/O操作結束而不能被執行的進程，Blocked可能指出你正面臨I/O瓶頸。
User time
描述了處理用戶進程的百分比，包括nice time。如果User time的值很高，說明系統性能用在處理實際的工作。
System time
描述了CPU花費在處理內核操作包括IRQ和軟體中斷上面的百分比。如果system time很高說明系統可能存在網路或者驅動堆棧方面的瓶頸。一個系統通常只花費很少的時間去處理內核的操作。
Idle time
描述了CPU空閑的百分比。
Nice time
描述了CPU花費在處理re-nicing進程的百分比。
Context switch
系統中線程之間進行交換的數量。
Waiting
CPU花費在等待I/O操作上的總時間，與blocked相似，一個系統不應該花費太多的時間在等待I/O操作上，否則你應該進一步檢測I/O子系統是否存在瓶頸。
Interrupts
Interrupts值包括硬Interrupts和軟Interrupts，硬Interrupts會對系統性能帶
來更多的不利影響。高的Interrupts值指出系統可能存在一個軟體的瓶頸，可能是內核或者驅動程序。注意Interrupts值中包括CPU時鍾導
致的中斷（現代的xServer系統每秒1000個Interrupts值）。
二、內存參數
Free memory
相比其他操作系統，Linux空閑內存的值不應該做為一個性能參考的重要指標，因為就像我們之前提到過的，Linux內核會分配大量沒有被使用的內存作為文件系統的緩存，所以這個值通常都比較小。
Swap usage
這個值描述了已經被使用的swap空間。Swap
usage只表示了Linux管理內存的有效性。對識別內存瓶頸來說，Swap In/Out才是一個比較又意義的依據，如果Swap
In/Out的值長期保持在每秒200到300個頁面通常就表示系統可能存在內存的瓶頸。
Buffer and cache
這個值描述了為文件系統和塊設備分配的緩存。注意在Red Hat Enterprise Linux
3和更早一些的版本中，大部分空閑內存會被分配作為緩存使用。在Red Hat Enterprise Linux
4以後的版本中,你可以通過修改/proc/sys/vm中的page_cache_tuning來調整空閑內存中作為緩存的數量。
Slabs
描述了內核使用的內存空間，注意內核的頁面是不能被交換到磁碟上的。
Active versus inactive memory
提供了關於系統內存的active內存信息，Inactive內存是被kswapd守護進程交換到磁碟上的空間。
三、網路參數
Packets received and sent
這個參數表示了一個指定網卡接收和發送的數據包的數量。
Bytes received and sent
這個參數表示了一個指定網卡接收和發送的數據包的位元組數。
Collisions per second
這個值提供了發生在指定網卡上的網路沖突的數量。持續的出現這個值代表在網路架構上出現了瓶頸，而不是在伺服器端出現的問題。在正常配置的網路中沖突是非常少見的，除非用戶的網路環境都是由hub組成。
Packets dropped
這個值表示了被內核丟掉的數據包數量，可能是因為防火牆或者是網路緩存的缺乏。
Overruns
Overruns表達了超出網路介面緩存的次數，這個參數應該和packets dropped值聯繫到一起來判斷是否存在在網路緩存或者網路隊列過長方面的瓶頸。
Errors
這個值記錄了標志為失敗的幀的數量。這個可能由錯誤的網路配置或者部分網線損壞導致，在銅口千兆乙太網環境中部分網線的損害是影響性能的一個重要因素。
四、塊設備參數
Iowait
CPU等待I/O操作所花費的時間。這個值持續很高通常可能是I/O瓶頸所導致的。
Average queue length
I/O請求的數量，通常一個磁碟隊列值為2到3為最佳情況，更高的值說明系統可能存在I/O瓶頸。
Average wait
響應一個I/O操作的平均時間。Average wait包括實際I/O操作的時間和在I/O隊列里等待的時間。
Transfers per second
描述每秒執行多少次I/O操作（包括讀和寫）。Transfers per second的值與kBytes per second結合起來可以幫助你估計系統的平均傳輸塊大小，這個傳輸塊大小通常和磁碟子系統的條帶化大小相符合可以獲得最好的性能。
Blocks read/write per second
這個值表達了每秒讀寫的blocks數量，在2.6內核中blocks是1024bytes，在早些的內核版本中blocks可以是不同的大小，從512bytes到4kb。
Kilobytes per second read/write
按照kb為單位表示讀寫塊設備的實際數據的數量。

⑹ linux系統怎麼對JAVA應用程序進行性能分析

• 分析CPU佔用的方法和手段：

1. top命令：可以查看實時的CPU使用情況。

2. ps -ef命令：可以查看雹凳纖進程以及進程中線程的當前CPU使用情況以及屬於當前狀態的采樣數據。

3. jstack：Java提供的命令。可以查看某個進程的當前線程棧運行情況。根據這個命令的輸出可以定位某個進程的所有線程的當前運行狀態、運行代碼，以及是否死鎖等等粗寬。

4. pstack：Linux命令。可以查看某個進程的當前線程棧運行情況

• 分析內存性能的方法和技巧：

1.top命令：可以查看實時的內存使用情況。

2.jmap -histo:live [pid]，然後分析具體的對象源仿數目和佔用內存大小，從而定位代碼。

jmap -mp:live,format=b,file=xxx.xxx [pid]，然後利用MAT工具分析是否存在內存泄漏等等。