性能測試分析與性能調優診斷–史上最全的服務器性能分析監控調優篇
- 2019 年 10 月 7 日
- 筆記
一個系統或者網站在功能開發完成後一般最終都需要部署到服務器上運行,那麼服務器的性能監控和分析就顯得非常重要了,選用什麼配置的服務器、如何對服務器進行調優、如何從服務器監控中發現程序的性能問題、
如何判斷服務器的瓶頸在哪裡等 就成為了服務器性能監控和分析時重點需要去解決的問題了。
1 服務器的性能監控和分析
1.1 Linux服務器的性能指標監控和分析
1.1.1 通過vmstat深挖服務器的性能問題
1.1.2 如何通過mpstat 分析服務器的性能指標
1.1.3 從lsof中能看到什麼
1.1.4 如何通過free看懂內存的真實使用
1.1.5 網絡流量如何監控
1.1.6 nmon對Linux服務器的整體性能監控
1.2 Windows服務器的性能指標監控和分析
1.2.1 Windows性能監視器
1.2.2 Windows性能監視器下的性能分析
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。
1.1 Linux服務器的性能指標監控和分析
1.1.1 通過vmstat深挖服務器的性能問題
vmstat差不多是性能測試時在linux服務器上執行最多的命令,使用該命令往往能輔助我們進行很多的性能問題定位。
我們先來看一下執行vmstat 命令後,獲取到的服務器的資源使用的監控數據有哪些。
我們在執行vmstat 的時候,後面加了兩個參數,其中參數1代表每隔1秒獲取一次服務器的資源使用數據,10代表總共獲取10次。
指標 |
含義 |
r |
r是第一列的監控數據,代表了目前實際在運行的指令隊列(也就是有多少任務需要CPU來進行執行),從數據來看,這台服務器目前CPU的資源比較空閑,如果發現這個數據超過了服務器CPU的核數,就可能會出現CPU瓶頸了(在判斷時,還需要結合CPU使用的百分比一起來看,也就是上圖中最後5列的數據指標),一般該數據超出了CPU核數的3個時,就比較高了,超出了5個就很高了,如果都已經超過了10時,那就很不正常了,服務器的狀態就很危險了。如果運行隊列超過CPU核數過多,表示CPU很繁忙,通常會造成CPU的使用率很高。 |
b |
b是第二列的監控數據,表示目前因為等待資源而阻塞運行的指令個數,比如因為等待I/O、內存交換、CPU等資源而造成了阻塞,該值如果過高了的話,就需要檢查服務器上I/O、內存,CPU等資源是不是出現了瓶頸。 |
swpd |
swpd是第三列的監控數據,表示虛擬內存(swap)已使用的大小(swap指的是服務器的物理運行內存不夠用的時候,會把物理內存中的部分空間釋放出來,以供需要運行的程序去使用,而那些釋放出來的空間可能來自一些很長時間沒有什麼操作的程序,這些被釋放的空間會被臨時保存到Swap中,等到那些程序要運行時,再從Swap分區中恢復保存的數據到內存中,swap分區一般使用的都是磁盤的空間,磁盤的I/O讀寫一般會比物理內存慢很多,如果存在大量的swap讀寫交換,將會非常影響程序運行的性能),也就是切換到內存交換區的內存數量(單位為k),此處需要注意,並不是swpd的值大於0,就是服務器的物理內存已經不夠用了,通常還需要結合si和so這兩個數據指標來一起分析,如果si和so 還維持在0左右,那服務器的物理內存還是夠用的。 |
free |
free是第四列的監控數據,表示空閑的物理內存的大小,就是還有多少物理內存沒有被使用(單位為k),這個free的數據是不包含buff和cache這兩列的數據值在內的。 |
buff |
buff 是第五列的監控數據,表示作為Linux/Unix系統的緩存的內存大小(單位為k),一般對塊設備的讀寫才需要緩衝,一般內存很大的服務器,這個值一般都會比較大,操作系統也會自動根據服務器的物理內存去調整緩衝區的內存使用大小,以提高讀寫的速度。 |
cache |
cache是第6列的監控數據,表示用來給已經打開的文件做緩衝的內存大小,cache直接用來記憶我們打開的文件,把空閑的物理內存的一部分拿來做文件和目錄的緩存,是為了提高程序執行的性能,當程序使用內存時,buffer/cached會很快地被使用,當空閑的物理內存不足時(即free的內存不足),這些緩存的內存便可以釋放出來。 |
si |
si是第7列的監控數據,表示每秒從磁盤(虛擬內存swap)讀入到內存的大小,如果這個值長期大於0,那物理運行內存可能已經是不夠用了。 |
so |
so是第8列的監控數據,表示每秒寫入磁盤(虛擬內存swap)的內存大小,so剛好和si相反,si一般是將磁盤空間調入內存,so一般是將內存數據調入磁盤。 |
bi |
bi是第9列的監控數據,表示塊設備每秒讀取的塊數量(從磁盤讀取數據,這個值一般表示每秒讀取了磁盤的多少個block),這裡的塊設備(block)是指系統上所有的磁盤和其他塊設備,默認塊大小是1024byte。 |
bo |
bo是第10列的監控數據,表示塊設備每秒寫入的塊數量(往磁盤寫入數據,這個值一般表示每秒有多少個block寫入了磁盤)。通常情況下,隨機磁盤讀寫的時候,bi和bo這2個值越大(如超出1024k),能看到CPU在IO等待的值也會越大。 |
in |
in是第11列的監控數據,表示 每秒CPU的中斷次數,包括時鐘中斷。 |
cs |
cs是第12列的監控數據,表示 CPU每秒上下文切換次數,例如我們調用系統函數,就要進行上下文切換,線程的切換,也要進程上下文切換,這個值要越小越好,太大了,要考慮調低線程或者進程的數目,例如在apache和nginx這種web服務器中,我們一般做性能測試時會進行幾千並發甚至幾萬並發的測試,選擇web服務器的進程可以由進程或者線程的峰值一直下調,壓測,直到cs到一個比較小的值,這個進程和線程數就是比較合適的值了。系統調用也是,每次調用系統函數,我們的代碼就會進入內核空間,導致上下文切換,這個是很耗資源,也要盡量避免頻繁調用系統函數。上下文切換次數過多表示你的CPU大部分浪費在上下文切換,導致CPU干正經事的時間少了,CPU沒有充分利用,是不可取的。系統運行時,如果觀察到in和cs 這兩個指標非常高,那就需要對系統進行性能調優了。 |
us |
us(user time)是第13列的監控數據,表示用戶模式CPU使用時間的百分比,該值一般越高,說明CPU被正常利用的越好,筆者曾經在給一個機器學習算法(密集型CPU應用)做壓力測試時,us的值可以接近100,那說明CPU已經充分被算法服務使用了。 |
sy |
sy是第14列的監控數據,表示系統內核進程執行時間百分比(system time),sy的值高時,說明系統內核消耗的CPU資源多,這並不是一個服務器性能好的表現,通常in、cs、io的頻繁操作等過高,都會引起sy的指標過高,這個時候我們應該要去定位原因了。 |
id |
id是第15列的監控數據,表示空閑 CPU時間的佔比,一般來說,id + us + sy = 100,一般可以認為id是空閑CPU使用率,us是用戶CPU使用率,sy是系統CPU使用率。 |
wa |
wa是第16列的監控數據,表示I/O等待時間百分比,wa的值高時,說明IO等待比較嚴重,這可能由於磁盤大量作隨機訪問造成,也有可能磁盤出現瓶頸(塊操作) |
st |
st是第17列的監控數據,表示CPU等待虛擬機調度的時間佔比,這個指標一般在虛擬機中才會有,物理機中,該值一般維持為0,我們都知道虛擬機中的CPU一般是物理機CPU的虛擬核,一台物理機一般會有多個虛擬機同時在運行,那麼此時虛擬機之間就會存在CPU的爭搶情況,比如某台虛擬機上運行着佔用CPU很高的密集型計算,就會導致其他的虛擬機上的CPU需要一直等待密集型計算的虛擬機上CPU的釋放,st就是等待時間佔CPU時間的佔比,該值如果一直持續很高,那麼表示虛擬服務器需要長期等待CPU,運行在該服務器的應用程序的性能會受到直接的影響,筆者曾經在壓測時發現,該值越高,也會引起sy的值變高(因為操作系統內核需要不斷的去調度CPU)。 |
vmstat還可以支持其他的參數使用,我們可以通過執行vmstat –help 命令查看到它支持的其他參數
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html
l -a, –active 顯示活躍和非活躍的內存
l -f, –forks 顯示操作系統從啟動至今的fork數量,fork一般指的就是啟動過的進程數量,linux操作系統用fork()函數來創建進程。
l -m, –slabs 顯示slab的相關信息,slab是linux內核中按照對象大小進行分配的內存分配器,通過slab的信息可以來查看各個內核模塊佔用的內存空間,可以通過cat /proc/meminfo |grep Slab 命令查看Slab佔用的總內存大小,如果佔用的內存過大,那麼可能是內核模塊出現了內存泄漏了。
l -n, –one-header 這個參數表示只顯示頭部第一行的信息
l -s, –stats event counter statistics 顯示內存相關的統計信息及多種系統操作活動發生數量統計,比如CPU時鐘中斷的次數,CPU上下文切換的次數等。
l -d, –disk disk statistics 顯示每一塊磁盤I/O相關的明細信息
l -D, –disk-sum 顯示磁盤I/O相關的匯總信息,-D 顯示的信息是對-d參數顯示的每個磁盤塊的信息的匯總。
l -p, –partition <dev> partition specific statistics 顯示磁盤中某個分區的I/O讀寫信息。例如執行vmstat -p /dev/sda1 可以顯示/dev/sda1這個分區的I/O讀寫的相關的信息。
l -S, –unit <char> define display unit 使用指定單位顯示。參數有 k 、K 、m 、M ,分別代表1000、1024、1000000、1048576位元組(byte)。默認單位為K(1024 bytes)
l -w, –wide wide output 這個參數用於調整命令輸出結果的顯示方式,輸出的結果和單獨執行vmstat命令得到的結果是完全一樣,只是在輸出時,會以更寬的寬度來展示數據。
l -t, –timestamp show timestamp 在vmstat命令輸出的數據的基礎上,增加每次獲取數據時的當前時間戳的輸出顯示
l -V, –version output version information and exit 輸出vmstat命令得版本信息
1.1.2 如何通過mpstat 分析服務器的性能指標
linux中的mpstat 命令也是在性能測試時經常用來監控服務器整體性能指標的一種方式,mpstat命令和上面我們講到的vmstat命令非常類似,我們來看一下執行vmstat 命令後,獲取到的服務器的資源使用的監控數據。
我們在執行mpstat的時候,後面同樣加了兩個參數,其中參數1代表每隔1秒獲取一次服務器的資源使用數據,10代表總共獲取10次,這點和vmstat的使用很類似。
l %usr 表示的是用戶模式下CPU使用時間的百分比,和vmstat中得到的us數據基本一致
l %nice 表示CPU在進程優先級調度下CPU佔用時間的百分比,在操作系統中,進程的運行是可以設置優先級的,linux操作系統也是一樣,優先級越高的,獲取到CPU運行的機會越高。這個值一般的時候都會是0.00,但是一旦我們在程序運行時,修改過默認優先級時,%nice就會產生佔用時間的百分比,在linux中,執行top或者ps命令時,通常會輸出PRI/PR、NI、%ni/%nice這三個指標。
- PRI:表示進程執行的優先級,值越小,優先級就越高,會越早獲得CPU的執行權。
- NI:表示進程的Nice值,表示進程可被執行的優先級的修正數值,PRI值越小會越早被CPU執行,在加入Nice值後,將會使得PRI的值發生變化,新的PRI值=老的PRI值+Nice值,那麼可以看出PRI的排序是和Nice密切相關的,Nice值越小,那麼PRI值就會越小,就會越早被CPU執行,在Linux操作系統中如果Nice值相同時進程uid為root進程的執行優先級會更高。通常情況下,子進程會繼承父進程的Nice值,在操作系統啟動時init進程會被賦予0,其它進程(其它的進程基本都是init進程開闢的子進程)會自動繼承這個Nice值。
- %ni/%nice:可以形象的表示為改變過優先級的進程的佔用CPU的百分比,即可以理解為Nice值影響了內核分配給進程的cpu時間片的多少。
l %sys表示系統內核進程執行時間百分比(system time),該值越高時,說明系統內核消耗的CPU資源越多,和vmstat命令中的sy數據基本一致。
l %iowait表示I/O等待時間百分比,該值越高時,說明IO等待越嚴重,和vmstat命令中的wa數據基本一致。
l %irq表示用於處理系統中斷的 CPU 百分比,和vmstat命令中的in數據的含義類似,in越高,那麼%irq也會越高。
l %soft表示用於軟件中斷的 CPU 百分比。
l %steal 表示CPU等待虛擬機調度的時間佔比,這個指標一般在虛擬機中才會有,物理機中該值一般維持為0,和vmstat命令中的st數據基本一致。
l %guest表示運行vCPU(虛擬處理器)時所消耗的cpu時間百分比
l %gnice表示運行降級虛擬程序所使用的CPU佔比
l %idle表示空閑 CPU時間的佔比,和vmstat命令中的id數據基本一致。
我們上面通過執行mpstat 1 10 獲取到的是服務器中所有的CPU核數的匯總數據,所以可以看到在顯示時,CPU列顯示的為all,如果我們需要查看服務器中么某一個CPU核的資源使用情況,可以在執行mpstat命令時,加上-P 這個參數,比如執行mpstat -P 0 1 10 命令可以獲取到服務器中CPU核編號為0的CPU核的資源的使用情況(CPU核的編號是從0開始,比如圖中我們的服務器有2個CPU核那麼CPU核的編號就是0和1)。
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html
1.1.3 從lsof中能看到什麼
lsof 是對Linux操作系統中對文件進行監控的一個常用命令,使用該命令可以列出當前系統打開了哪些文件,系統中某個進程打開了哪些文件等。
我們直接執行lsof即可以顯示當前操作系統打開了哪些文件,lsof命令必須運行在root用戶下,這是因為lsof命令執行時需要訪問核心內存和內核文件,如下圖所示,我們直接執行lsof命令後得到的結果。
l 第1列展示的為進程的名稱,圖中顯示的進程名稱為nginx。
l 第2列展示的為進程的id編號(也就是Linux操作系統中常說的PID)
l 第3列展示的為進程的所有者,也就是這個進程是運行在哪個Linux用戶下的,可以看到圖中的進程基本都是運行在root用戶下,這是因為我在啟動nginx時,就是在root用戶下來啟動的
l 第4列展示的為文件描述符(File Descriptor number),常見的類型如下
文件描述符簡稱 |
英文全稱 |
中文解釋 |
cwd |
current working directory |
當前工作的目錄 |
mem |
memory-mapped file |
代表把磁盤文件映射到內存中 |
txt |
program text |
進程運行的程序文件,包括編譯後的代碼文件以及產生的數據文件等,圖中的nginx命令文件就屬於txt類型。 |
rtd |
root directory |
代表root目錄 |
pd |
parent directory |
父目錄 |
DEL |
a Linux map file that has been deleted |
代表已經刪除的Linux映射文件 |
數字+字符,如0u、1w、2w等 |
|
0:表示標準輸出 1:表示標準輸入 2:表示標準錯誤 u:表示該文件被打開並處於讀取/寫入模式 r:表示該文件被打開並處於只讀模式 w:表示該文件被打開並處於只寫入模式 |
l 第5列展示的為打開的文件類型,常見的類型如下
類型 |
英文全稱 |
解釋 |
DIR |
directory |
代表了一個文件目錄 |
CHR |
character special file |
特殊字符文件 |
LINK |
symbolic link file |
鏈接文件 |
IPv4 |
IPv4 socket |
IPv4 套接字文件 |
IPv6 |
IPv6 network file |
打開了一個IPV6的網絡文件 |
REG |
regular file |
普通文件 |
FIFO |
FIFO special file |
先進先出的隊列文件 |
unix |
UNIX domain socket |
unix下的域套接字,也稱inter-process communication socket,也就是常說的IPC scoket(進程間的通信scoket),在開發中經常會被使用的一種通訊方式。 |
MPB |
multiplexed block file |
多路復用的塊文件 |
MPC |
multiplexed character file |
多路復用的字符文件 |
inet |
an Internet domain socket |
Intent 域套接字 |
l 第6列展示的是使用character special、block special表示的設備號
l 第7列展示的是文件的大小(前提是文件有效)
l 第8列展示的是操作系統本地文件的node number或者協議類型(在網絡通訊的情況下會展示通訊協議類型,比如如下nginx的LISTEN監聽進程就是一個TCP協議)
l 第9列展示的是文件的絕對路徑或者網絡通訊鏈接的地址、端口、狀態或者掛載點等。
lsof 還可以支持其他的參數使用,常見的使用如下:
l lsof –c 查看某個進程名稱當前打開了哪些文件,例如執行lsof –c nginx命令可以查看nginx進程當前打開了哪些文件
l lsof –p 查看某個進程id 當前打開了哪些文件,例如執行lsof –p 1 命令可以查看進程id為1的進程當前打開了哪些文件
l lsof –i 查看IPv4、IPv6下打開的文件,此時看到的大部分都是網絡的鏈接通訊,會包括服務端的LISTEN監聽或者客戶端和服務端的網絡通訊。
在lsof –i後加上 :(冒號) 端口號時,可以定位到某個端口下的IPv4、IPv6模式打開的文件和該端口下的網絡鏈接通訊,例如執行lsof –i:80命令可以查看一下80端口下的網絡鏈接通訊情況
從這個展示的通訊情況可以看到,80端口下起了兩個LISTEN監聽進程,分別是在root用戶下和nobody用戶下,並且可以看到ip為192.168.1.100的電腦和80端口進行了TCP通訊鏈接,TCP通訊鏈接的狀態為
ESTABLISHED,並且鏈接時佔用了服務器上的53151和53152 這兩個端口。
TCP通訊鏈接是在做性能測試時經常需要關注的,尤其是在高並發的情況下如何優化TCP鏈接數和TCP鏈接的快速釋放,是性能調優的一個關注點。鏈接的常用狀態如下
狀態 |
解釋 |
LISTEN |
監聽狀態,這個一般應用程序啟動時,會啟動監聽,比如nginx程序啟動後,就會產生監聽進程,一般的時候,監聽進程的端口都是可以自己進行設置,以防止端口衝突 |
ESTABLISHED |
鏈接已經正常建立,表示客戶端和服務端正在通訊中。 |
CLOSE_WAIT |
客戶端主動關閉連接或者網絡異常導致連接中斷,此時這次鏈接下服務端的狀態會變成CLOSE_WAIT,需要服務端來主動進行關閉該鏈接。 |
TIME_WAIT |
服務端主動斷開鏈接,收到客戶端確認後鏈接狀態變為TIME_WAIT,但是服務端並不會馬上徹底關閉該鏈接,只是修改了狀態。TCP協議規定TIME_WAIT狀態會一直持續2MSL的時間才會徹底關閉,以防止之前鏈接中的網絡數據包因為網絡延遲等原因延遲出現。處於TIME_WAIT狀態的連接佔用的資源不會被內核釋放,所以性能測試中如果服務端出現了大量的TIME_WAIT狀態的鏈接就需要分析原因了,一般不建議服務端主動去斷開鏈接。 |
SYN_SENT |
表示請求正在鏈接中,當客戶端要訪問服務器上的服務時,一般都需要發送一個同步信號給服務端的端口,在此時鏈接的狀態就為SYN_SENT,一般SYN_SENT狀態的時間都是非常短,除非是在非常高的並發調用下,不然一般SYN_SENT狀態的鏈接都非常少。 |
不管是什麼狀態下的TCP鏈接,都會佔用服務器的大量資源,而且每個鏈接都會佔用一個端口,Linux服務器的TCP和UDP的端口總數是有限制的(0-65535),超過這個範圍就沒有端口可以用了,程序會無法啟動,鏈接也會無法進行。所以如果服務端出現了大量的CLOSE_WAIT和TIME_WAIT的鏈接時,就需要去及時去查找原因和進行優化。CLOSE_WAIT狀態一般大部分的時候,都是自己寫的代碼或者程序出現了明顯的問題造成。
針對如果出現了大量的TIME_WAIT狀態的鏈接,可以從服務器端進行一些優化以讓服務器快速的釋放TIME_WAIT狀態的鏈接佔用的資源。優化的方式如下
使用vim /etc/sysctl.conf來編輯sysctl.conf文件以優化Linux操作系統的文件內核參數設置,加入如下配置:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time=600
net.ipv4.tcp_max_tw_buckets = 5000
fs.file-max = 900000
net.ipv4.tcp_max_syn_backlog = 2000
net.core.somaxconn = 2048
net.ipv4.tcp_synack_retries = 1
net.ipv4.ip_local_port_range =1000 65535
net.core.rmem_max = 2187154
net.core.wmem_max = 2187154
net.core.rmem_default = 250000
net.core.wmem_default = 250000
然後執行sysctl –p命令可以內核讓參數立即生效,這種調優一般在nginx、apache 這種web服務器上會經常用到。
- net.ipv4.tcp_syncookies = 1 表示開啟syn cookies,當出現syn等待隊列溢出時啟用cookies來處理,默認情況下是關閉狀態。客戶端向linux服務器建立TCP通訊鏈接時會首先發送SYN包,發送完後客戶端會等待服務端回復SYN+ACK,服務器在給客戶端回復SYN+ACK後,服務器端會將此時處於SYN_RECV狀態的連接保存到半鏈接隊列中以等待客戶端繼續發送ACK請求給服務器端直到最終鏈接完全建立,在出現大量的並發請求時這個半鏈接隊列中可能會緩存了大量的SYN_RECV狀態的鏈接從而導致隊列溢出,隊列的長度可以通過內核參數net.ipv4.tcp_max_syn_backlog進行設置,在開啟cookies後服務端就不需要將SYN_RECV狀態的半狀態鏈接保存到隊列中,而是在回復SYN+ACK時將鏈接信息保存到ISN中返回給客戶端,當客戶端進行ACK請求時通過ISN來獲取鏈接信息以完成最終的TCP通訊鏈接。
- net.ipv4.tcp_tw_reuse = 1 表示開啟鏈接重用,即允許操作系統將TIME-WAIT socket的鏈接重新用於新的tcp鏈接請求,默認為關閉狀態。
- net.ipv4.tcp_tw_recycle = 1 表示開啟操作系統中TIME-WAIT socket鏈接的快速回收,默認為關閉狀態。
- net.ipv4.tcp_fin_timeout = 30 設置服務器主動關閉鏈接時,scoket鏈接保持等待狀態的最大時間。
- net.ipv4.tcp_keepalive_time = 600 表示請求在開啟keepalive(現在一般客戶端的http請求都是開啟了keepalive選項)時TCP發送keepalive消息的時間間隔,默認是7200秒,在設置短一些後可以更快的去清理掉無效的請求。
- net.ipv4.tcp_max_tw_buckets = 5000 表示鏈接為TIME_WAIT狀態時linux操作系統允許其接收的套接字數量的最大值,過多的TIME_WAIT套接字會使Web服務器變慢
- fs.file-max = 900000 表示linux操作系統可以同時打開的最大句柄數,在web服務器中,這個參數有時候會直接限制了web服務器可以支持的最大鏈接數,需要注意的是這個參數是對整個操作系統生效的。而ulimit –n 可以用來查看進程能夠打開的最大句柄數,在句柄數不夠時一般會出現類似” Too many open files”的報錯。在Centos7中可以使用cat /proc/sys/fs/file-max 命令來查看操作系統可以能夠打開的最大句柄數。
-
使用vi /etc/security/limits.conf 編輯limits.conf配置文件,可以修改進程能夠打開的最大句柄數,在limits.conf增加如下配置即可
soft nofile 65535
hard nofile 65535
-
- net.ipv4.tcp_max_syn_backlog 表示服務器能接受SYN同步包的最大客戶端連接數,也就是上面說的半連接的最大數量,默認值為128
- net.core.somaxconn = 2048 表示服務器能處理的最大客戶端連接數,這裡的連接指的是能同時完成連接建立的最大數量,默認值為128
- net.ipv4.tcp_synack_retries = 1 表示服務器在發送SYN+ACK回復後,在未繼續收到客戶端的ACK請求時服務器端重新嘗試發送SYN+ACK回復的重試次數
- net.ipv4.ip_local_port_range =2048 65535 修改可以用於和客戶端建立連接的端口範圍,默認為32768到61000,修改後,可以避免建立連接時端口不夠用的情況。
- net.core.rmem_max = 2187154 表示linux操作系統內核scoket接收緩衝區的最大大小,單位為位元組
- net.core.wmem_max = 2187154表示linux操作系統內核scoket發送緩衝區的最大大小,單位為位元組
- net.core.rmem_default = 250000 表示linux操作系統內核scoket接收緩衝區的默認大小,單位為位元組
- net.core.wmem_default = 250000表示linux操作系統內核scoket發送緩衝區的默認大小,單位為位元組
-
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
-
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html
l lsof +d 列出指定目錄下被使用的文件,例如執行lsof +d /usr/lib/locale/ 命令查看/usr/lib/locale/ 目錄下有哪些文件被打開使用了
l lsof +D 和上面+d 參數的作用類似,也是列出指定目錄下被使用的文件,不同的是+D會以遞歸的形式列出,也就是會列出指定目錄下所有子目錄下被使用的文件,而-d 參數只會列出當前指定目錄下被使用的文件,
而不會繼續去列出子目錄下被使用的文件,例如執行lsof +D /usr/lib/ 命令查看/usr/lib/ 目錄以及子目錄下有哪些文件被打開使用了
l lsof 後面可以直接指定一個全路徑的文件以列出該文件正在被哪些進程所使用,例如執行lsof /usr/lib/modules/3.10.0-862.el7.x86_64/modules.symbols.bin 命令可以查看到modules.symbols.bin文件目前正在被那個
進程使用
l lsof –i:@ip 可以列出某個指定ip上的所有網絡連接通訊,例如執行lsof [email protected] 命令可以查看到192.168.1.221這個ip上的所有的網絡連接通訊
l lsof –i 網絡協議 可以列出某個指定協議下的網絡連接信息
lsof –i tcp 命令可以列出tcp下所有的網絡連接信息
- lsof -i tcp:80 命令可以列出tcp下80端口所有的網絡連接信息
- lsof –i udp 命令可以列出udp下所有的網絡連接信息
- lsof -i udp:323 命令可以列出udp下323端口所有的網絡連接信息
1.1.4 如何通過free看懂內存的真實使用
free命令是linux操作系統中對內存進行查看和監控的一個常用命令,我們可以直接執行free命令來看下可以獲取到操作系統內存使用的哪些數據
默認直接執行free 獲取到的內存數據的單位都是k,Mem這一行展示的是物理內存的使用情況,Swap這一行展示的是內存交換區(通常也叫虛擬內存)的整體使用情況。
l total列展示的為系統總的可用物理內存和交換區的大小,單位為k
l used列展示的為已經被使用的物理內存和交換區的大小,單位為k
l free列展示的為還有多少物理內存和交換區沒有被使用,單位為k
l shared 列展示的為共享區佔用的物理內存大小,單位為k
l buff/cache 列展示的為被緩衝區和page高速緩存合計使用的物理內存大小,單位為k
- buff在操作系統中指的是緩衝區,是負責磁盤塊設備的讀寫緩衝,會直接佔用物理內存。
- cache 指的是操作系統中的 page cache(也就是通常所說的高速緩存),高速緩存是linux內核實現的磁盤緩存,可以減少內核對磁盤的I/O讀寫操作,會將磁盤中的數據緩存到物理內存中,這樣對磁盤的訪問就會變為對物理內存的訪問,從而大大提高了讀寫速度。cache 有一點類似應用程序中使用redis來做緩存一樣,把一些經常需要訪問的數據存儲到內存中來提高訪問的速度。
l available 列展示的為還可以被使用的物理內存的大小,單位為k。通常情況下,available 的值等於free+ buff/cache ,linux內核為了提高磁盤讀寫的速度會使用一部分物理內存去緩存經常被使用的磁盤數據,所以buffer 和 cache對於Linux操作系統的內核來說都屬於已經被使用的內存,而free列展示的是真實未被任何地方使用的物理內存,但是如果物理內存已經不夠用並且應用程序恰巧又需要使用內存時內核就會從 buffer 和 cache 中回收內存來滿足應用程序的使用,也就是說buffer 和 cache佔用的內存是可以被內核釋放的。
1.1.5 網絡流量如何監控
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。
在linux中,可以使用iftop命令來對服務器網卡的網絡流量進行監控,iftop並不是linux操作系統中本身就有的工具,需要單獨進行安裝,可以從http://www.ex-parrot.com/~pdw/iftop/ 網站中下載iftop工具。
下載完成後,首先執行./configure 命令進行安裝前的自動安裝配置檢查
[root@localhost iftop-1.0pre4]# ./configure
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking target system type… x86_64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /usr/bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking whether gcc understands -c and -o together… yes
checking for style of include used by make… GNU
checking dependency style of gcc… gcc3
checking how to run the C preprocessor… gcc -E
checking for grep that handles long lines and -e… /usr/bin/grep
checking for egrep… /usr/bin/grep -E
checking for ANSI C header files… yes
checking for sys/types.h… yes
checking for sys/stat.h… yes
checking for stdlib.h… yes
checking for string.h… yes
checking for memory.h… yes
checking for strings.h… yes
checking for inttypes.h… yes
checking for stdint.h… yes
checking for unistd.h… yes
checking sgtty.h usability… yes
checking sgtty.h presence… yes
checking for sgtty.h… yes
checking sys/ioctl.h usability… yes
checking sys/ioctl.h presence… yes
checking for sys/ioctl.h… yes
checking sys/time.h usability… yes
checking sys/time.h presence… yes
checking for sys/time.h… yes
checking sys/sockio.h usability… no
checking sys/sockio.h presence… no
checking for sys/sockio.h… no
checking termio.h usability… yes
checking termio.h presence… yes
checking for termio.h… yes
checking termios.h usability… yes
checking termios.h presence… yes
checking for termios.h… yes
checking for unistd.h… (cached) yes
checking for an ANSI C-conforming const… yes
checking for size_t… yes
checking whether time.h and sys/time.h may both be included… yes
checking sys/dlpi.h usability… no
checking sys/dlpi.h presence… no
checking for sys/dlpi.h… no
checking for regcomp… yes
checking for select… yes
checking for strdup… yes
checking for strerror… yes
checking for strspn… yes
checking for library containing socket… none required
checking for library containing log… -lm
checking for gethostbyname… yes
checking for library containing inet_aton… none required
checking for library containing inet_pton… none required
checking for inet_aton… yes
checking for inet_pton… yes
checking size of u_int8_t… unknown type
checking size of u_int16_t… unknown type
checking size of u_int32_t… unknown type
checking for stdint.h… (cached) yes
checking for library containing getnameinfo… none required
checking for library containing gethostbyaddr_r… none required
checking how to call gethostbyaddr_r… 8 args, int return
checking gethostbyaddr_r usability… yes
checking where to find pcap.h… /include
checking for pcap_open_live in -lpcap… yes
checking pcap.h usability… yes
checking pcap.h presence… yes
checking for pcap.h… yes
checking for a curses library containing mvchgat… -lcurses
checking POSIX threads compilation… CFLAGS= and LIBS=-lpthread
checking POSIX threads usability… yes
checking if we need to enable promiscuous mode by default… no
checking that generated files are newer than configure… done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating config.h
config.status: executing depfiles commands
configure: WARNING:
******************************************************************************
This is a pre-release version. Pre-releases are subject to limited
announcements, and therefore limited circulation, as a means of testing
the more widely circulated final releases.
Please do not be surprised if this release is broken, and if it is broken, do
not assume that someone else has spotted it. Instead, please drop a note on
the mailing list, or a brief email to me on [email protected]
Thank you for taking the time to be the testing phase of this development
process.
Paul Warren
******************************************************************************
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html
配置安裝檢查通過後,執行make && make install 命令對源碼先進行編譯,然後進行安裝
[root@localhost iftop-1.0pre4]# make && make install
make all-recursive
make[1]: Entering directory `/home/iftop/iftop-1.0pre4′
Making all in config
make[2]: Entering directory `/home/iftop/iftop-1.0pre4/config’
make[2]: Nothing to be done for `all’.
make[2]: Leaving directory `/home/iftop/iftop-1.0pre4/config’
make[2]: Entering directory `/home/iftop/iftop-1.0pre4′
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT addr_hash.o -MD -MP -MF .deps/addr_hash.Tpo -c -o addr_hash.o addr_hash.c
mv -f .deps/addr_hash.Tpo .deps/addr_hash.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT edline.o -MD -MP -MF .deps/edline.Tpo -c -o edline.o edline.c
mv -f .deps/edline.Tpo .deps/edline.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT hash.o -MD -MP -MF .deps/hash.Tpo -c -o hash.o hash.c
mv -f .deps/hash.Tpo .deps/hash.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT iftop.o -MD -MP -MF .deps/iftop.Tpo -c -o iftop.o iftop.c
mv -f .deps/iftop.Tpo .deps/iftop.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT ns_hash.o -MD -MP -MF .deps/ns_hash.Tpo -c -o ns_hash.o ns_hash.c
mv -f .deps/ns_hash.Tpo .deps/ns_hash.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT options.o -MD -MP -MF .deps/options.Tpo -c -o options.o options.c
mv -f .deps/options.Tpo .deps/options.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT resolver.o -MD -MP -MF .deps/resolver.Tpo -c -o resolver.o resolver.c
mv -f .deps/resolver.Tpo .deps/resolver.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT screenfilter.o -MD -MP -MF .deps/screenfilter.Tpo -c -o screenfilter.o screenfilter.c
mv -f .deps/screenfilter.Tpo .deps/screenfilter.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT serv_hash.o -MD -MP -MF .deps/serv_hash.Tpo -c -o serv_hash.o serv_hash.c
mv -f .deps/serv_hash.Tpo .deps/serv_hash.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT sorted_list.o -MD -MP -MF .deps/sorted_list.Tpo -c -o sorted_list.o sorted_list.c
mv -f .deps/sorted_list.Tpo .deps/sorted_list.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT threadprof.o -MD -MP -MF .deps/threadprof.Tpo -c -o threadprof.o threadprof.c
mv -f .deps/threadprof.Tpo .deps/threadprof.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT ui_common.o -MD -MP -MF .deps/ui_common.Tpo -c -o ui_common.o ui_common.c
mv -f .deps/ui_common.Tpo .deps/ui_common.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT ui.o -MD -MP -MF .deps/ui.Tpo -c -o ui.o ui.c
mv -f .deps/ui.Tpo .deps/ui.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT tui.o -MD -MP -MF .deps/tui.Tpo -c -o tui.o tui.c
mv -f .deps/tui.Tpo .deps/tui.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT addrs_ioctl.o -MD -MP -MF .deps/addrs_ioctl.Tpo -c -o addrs_ioctl.o addrs_ioctl.c
mv -f .deps/addrs_ioctl.Tpo .deps/addrs_ioctl.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT addrs_dlpi.o -MD -MP -MF .deps/addrs_dlpi.Tpo -c -o addrs_dlpi.o addrs_dlpi.c
mv -f .deps/addrs_dlpi.Tpo .deps/addrs_dlpi.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT dlcommon.o -MD -MP -MF .deps/dlcommon.Tpo -c -o dlcommon.o dlcommon.c
mv -f .deps/dlcommon.Tpo .deps/dlcommon.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT stringmap.o -MD -MP -MF .deps/stringmap.Tpo -c -o stringmap.o stringmap.c
mv -f .deps/stringmap.Tpo .deps/stringmap.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT cfgfile.o -MD -MP -MF .deps/cfgfile.Tpo -c -o cfgfile.o cfgfile.c
mv -f .deps/cfgfile.Tpo .deps/cfgfile.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT vector.o -MD -MP -MF .deps/vector.Tpo -c -o vector.o vector.c
mv -f .deps/vector.Tpo .deps/vector.Po
gcc -g -O2 -o iftop addr_hash.o edline.o hash.o iftop.o ns_hash.o options.o resolver.o screenfilter.o serv_hash.o sorted_list.o threadprof.o ui_common.o ui.o tui.o util.o addrs_ioctl.o addrs_dlpi.o dlcommon.o stringmap.o cfgfile.o vector.o -lpcap -lm -lcurses -lpthread
make[2]: Leaving directory `/home/iftop/iftop-1.0pre4′
make[1]: Leaving directory `/home/iftop/iftop-1.0pre4′
Making install in config
make[1]: Entering directory `/home/iftop/iftop-1.0pre4/config’
make[2]: Entering directory `/home/iftop/iftop-1.0pre4/config’
make[2]: Nothing to be done for `install-exec-am’.
make[2]: Nothing to be done for `install-data-am’.
make[2]: Leaving directory `/home/iftop/iftop-1.0pre4/config’
make[1]: Leaving directory `/home/iftop/iftop-1.0pre4/config’
make[1]: Entering directory `/home/iftop/iftop-1.0pre4′
make[2]: Entering directory `/home/iftop/iftop-1.0pre4′
/usr/bin/mkdir -p ‘/usr/local/sbin’
/usr/bin/install -c iftop ‘/usr/local/sbin’
/usr/bin/mkdir -p ‘/usr/local/share/man/man8’
/usr/bin/install -c -m 644 iftop.8 ‘/usr/local/share/man/man8’
make[2]: Leaving directory `/home/iftop/iftop-1.0pre4′
make[1]: Leaving directory `/home/iftop/iftop-1.0pre4′
命令執行完成後,可以看到iftop已經被安裝到/usr/local/sbin目錄下了
完成iftop的安裝後,就可以直接執行iftop命令了,命令執行後可以看到如下圖的網絡流量使用信息
l 代表了網絡流量的流轉方向
l TX:表示發送的總流量
l RX:表示接收的總流量
l TOTAL:表示總流量
l peak:表示每秒流量的峰值
l rates:分別表示過去 2s 10s 40s 的平均流量
iftop 命令還可以支持添加其它參數的使用
iftop –i 指定網卡名 可以用來監控指定網卡的網絡流量信息,例如執行iftop -i ens33命令可以監控ens33這塊網卡的網絡流量使用
iftop –P 可以在網絡流量信息中展示host信息和對應的端口信息,如下圖所示
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。
1.1.6 nmon對Linux服務器的整體性能監控
nmon 是一個監控aix和linux服務器性能的免費工具,nmon可以監控的數據主要包括:CPU 使用信息、內存使用信息,內核統計信息、運行隊列信息、磁盤 I/O 速度、傳輸和讀/寫比率、網絡 I/O 速度、傳輸和讀/寫比
率、消耗資源最多的進程,虛擬內存使用信息等,配合nmon_analyser一起可以nmon的監控數據轉換為excel形式的報表,nmon也不是操作系統自帶的監控工具,需要單獨進行安裝,可以從、
https://sourceforge.net/projects/nmon/網站中下載nmon進行安裝使用。
安裝完成後,執行nmon 命令後,可以進入nmon的監控選項視圖
- 鍵盤按下c後,可以實時監控到服務器CPU中每一個CPU核的使用信息
- 鍵盤按下l後,可以實時監控CPU的整體使用信息,此時展示的不再是單個CPU核的使用信息,而是所有CPU核整體的平均使用信息,如下圖所示
- 鍵盤按下m後,可以實時監控到服務器的物理內存和虛擬內存的使用信息
- 鍵盤按下k後,可以實時監控到服務器的內核信息
內核監控中可以看到操作系統內核中的運行隊列(RunQueue)大小、每秒CPU上下文(ContextSwitch)切換的次數、每秒CPU的中斷(Interrupts)次數,每秒調用Forks的次數(Linux操作系統創建新的進程一般都是調用fork函數進行創建,從中可以看到每秒創建了多少新的進程)以及CPU的使用信息等。
- 鍵盤按下d後,可以實時監控到服務器的磁盤I/O的讀寫信息
- 鍵盤按下j後,可以實時監控到服務器的文件系統的相關信息
- 鍵盤按下n後,可以實時監控到服務器網卡流量的相關信息
- 鍵盤按下t後,可以實時監控top process的相關資源使用信息
1.2 Windows服務器的性能指標監控和分析
1.2.1 Windows性能監視器
Windows服務器在安裝完Windows操作系統後,操作系統中默認就自帶了性能監控工具,這個自帶的性能監控工具通過訪問操作系統的控制面板->所有控制面板項->管理工具->性能監視器就能打開自帶的這個性能監控工
具,也可以通過在命令行中運行Perfmon.msc命令來打開自帶的性能監控工具,打開後的界面如下圖所示。
在Windows2003服務器操作系統中,這個性能監控工具是直接叫性能,如下圖所示
在Windows2003中,打開性能監控工具的界面如下圖所示,界面展示略有不同,但是包含的功能基本一致。
針對Processor、Process、Memory、TCP/UDP/IP/ICMP、PhysicalDisk等監控對象,Windows自帶的性能監視器提供了數百個性能計數器可以對這些對象進行監控,計數器可以提供應用程序、Windows服務、操作系統等的相關的性能信息來輔助分析程序性能瓶頸和對系統及應用程序性能進行診斷和調優。
在進入性能監視器界面後,可以通過點擊按鈕來添加對應的計數器,如下圖所示。
常見的計數器如下
l Processor:指的就是Windows服務器的CPU,在添加時會有實例的選擇,每一個實例代表了CPU的每一個核,比如4核的CPU的就會有4個實例,可以根據需要選擇對應的實例,在選擇了Processor後,可以看到該實例下所有和Processor相關的計數器,如下圖
Processor相關的計數器指標說明如下
計數器 |
說明 |
%Processor Time |
CPU執行非閑置進程和線程時間的百分比(可以通俗的理解為CPU處於繁忙使用狀態的時間佔比),該計數器一般可以用來作為CPU的整體利用率指標 |
%User Time |
CPU處於用戶模式下的使用時間佔比,該計數器和Linux下的%usr指標含義類似 |
%Privileged Time |
CPU在特權模式下處理線程所花的時間佔比,該計數器一般可以作為系統服務、操作系統自身模式下耗費的CPU時間佔比,這個指標一般不會太高,如果太高就需要去定位原因,一般的時候%User Time越高,說明CPU被利用的越好。 |
Interrupts/sec |
CPU每秒的中斷次數, 該計數器和Linux下的in指標的含義類似 |
%Interrupt Time |
CPU中斷時間佔比,該計數器和Linux下的%irq指標的含義類似 |
%Idle Time |
CPU空閑時間佔比,該計數器和Linux下的%idle指標的含義類似 |
%DPC Time |
CPU處理網絡傳輸等待的時間佔比 |
l Memory:指的就是Windows服務器的物理內存,在選擇了Memory後,可以看到該實例下所有和Memory相關的計數器,如下圖
Memory相關的計數器指標說明如下
計數器 |
說明 |
Available Bytes |
服務器剩餘的可用物理內存的大小(單位為位元組),如果該值很小說明服務器總的內存可能不夠或者部分應用一直都沒有及時釋放內存, 服務器的可用物理內存是通過將程序釋放的內存、空閑內存、備用內存相加在一起計算出來的。 |
Committed Bytes |
已被提交的虛擬內存位元組數,內存分配時會先在虛擬地址空間上保留一段空間保留一段時間,此時系統還沒有分配真正的物理內存只是分配了一段內存地址,在這一步操作成功後再提交分配的這段內存地址,操作系統接收到提交的內存地址後才會分配真正的物理內存。 |
Page Faults/sec |
每秒缺頁中斷或者頁面錯誤的數量,一般內存中不存在需要訪問的數據導致需要從硬盤讀取可能會導致此指標較高。 |
Reads/sec |
每秒為了解決硬錯誤(一般指引用的頁面在內存中不存在)而從硬盤上讀取頁面的次數 |
Writes/sec |
每秒為了釋放物理內存空間而需要將頁面寫入磁盤的次數 |
Input/sec |
每秒為了解決硬錯誤而從硬盤讀取的頁面數量,一般是指內存引用時頁面不在內存,為解決這種情況而從磁盤讀取的頁面數量。 |
Output/sec |
每秒內存中的頁面發生了修改從而需要寫入磁盤的頁面數量 |
Pages/sec |
每秒為了解決硬錯誤(一般指引用的頁面在內存中不存在)而從硬盤上讀取或寫入硬盤的頁面數量 |
Cathe Bytes |
Windows文件系統的緩存,這塊也是佔用服務器的物理內存,但是在物理內存不夠時是可以釋放的,Windows在釋放內存時一般會使用頁交換的方式進行,頁交換會將固定大小的代碼和數據塊從 物理內存移動到磁盤。 |
Pool Nonpaged Allocs |
在非分頁池中分配空間的調用數,這個計數器是以調用分配空間的次數來衡量的,而不會管每次調用分配的空間量是多少。 一般內核或者設備驅動使用非分頁池來保存可能訪問的數據,一旦加載到該池就始終駐留在物理內存中,並且在訪問的時候又不能出現錯誤,未分頁池不執行換入換出操作,如果一旦發生內存泄漏,將會非常嚴重。與非分頁池對應的就是分頁池(Paged Pool),指的是可以存到操作系統的分頁文件中,允許其佔用的物理內存被重新設置,類似用戶模式的虛擬內存。 |
Pool Nonpaged Bytes |
非分頁池的大小(單位:位元組)。內存池非分頁位元組的計算方式不同於進程池中非分頁位元組,因此它可能不等於進程池非分頁位元組總數。 |
Pool Paged Allocs |
在分頁池中分配空間的調用數。它也是以調用分配空間的次數來衡量的,而不管每次調用分配的空間量是多少。 |
Pool Paged Bytes |
分頁池的大小(單位:位元組)。內存池分頁位元組的計算方式與進程池分頁位元組的計算方式不同,因此它可能不等於進程池分頁位元組總數。 |
Transition Faults/sec |
通過恢復共享頁中被其它進程正在使用的頁、已修改頁列表或待機列表中的頁、或在頁故障時寫入磁盤的頁來解決頁故障的速率。在沒有其他磁盤活動的情況下恢復了這些頁。轉換錯誤按錯誤數計算,因為每個操作中只有一個頁面出錯,所以它也等於出錯的頁面數。 |
Write Copies/sec |
通過從物理內存中的其他位置複製頁來滿足的寫入嘗試導致頁錯誤的速率。這是一種效率很高的共享數據的方式,因為頁面只在寫入時被複制,否則頁面被共享。此計數器只顯示副本數而不考慮每次操作中複製的頁數。 |
System Code Total Bytes |
虛擬內存中當前可分頁給操作系統程序的空間大小(單位:位元組)。它是操作系統使用的物理內存量的量度並且可以在不使用時寫入磁盤。這個值是通過添加ntoskrnl.exe、hal.dll、引導驅動程序和ntldr/osloader加載的文件系統中的位元組來計算的。此計數器不包括必須保留在物理內存中且無法寫入磁盤的操作系統程序。 |
System Driver Total Bytes |
設備驅動程序當前使用的可分頁虛擬內存的大小(單位:位元組),包括物理內存(內存/系統驅動程序駐留空間)和寫入磁盤的代碼和數據。它是內存/系統代碼總位元組數的組成部分 |
l PhysicalDisk:指的就是Windows服務器的磁盤設備,在選擇了PhysicalDisk後,可以看到該實例下所有和PhysicalDisk相關的計數器,如下圖
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html
PhysicalDisk相關的計數器指標說明如下
計數器 |
說明 |
Disk Bytes/sec |
每秒從磁盤I/O讀取和寫入的位元組數 |
Disk Read Bytes/sec |
每秒從磁盤I/O讀取的位元組數,這個計數器是以位元組大小來描述每秒對磁盤的讀取操作。 |
Disk Write Bytes/sec |
每秒寫入磁盤I/O的位元組數,這個計數器是以位元組大小來描述每秒對磁盤的寫入操作。 |
Disk Reads/sec |
對磁盤讀取操作的速率,這個計數器是以每秒對磁盤I/O的讀取次數來描述對磁盤的讀取頻率 |
Disk Writes/sec |
對磁盤寫入操作的速率,這個計數器是以每秒對磁盤I/O的寫入次數來描述對磁盤的寫入頻率 |
Disk Transfers/sec |
每秒對磁盤I/O讀取和寫入的次數 |
%Disk Time |
所選磁盤驅動器正忙於處理讀取或寫入請求所用時間佔比 |
%Disk Read Time |
所選磁盤驅動器正忙於處理讀取請求的時間佔比 |
%Disk Write Time |
所選磁盤驅動器正忙於處理寫入磁盤請求的時間佔比 |
Avg. Disk Queue Length |
所選磁盤在性能監視器性能數據採樣間隔期間需要排隊的平均讀寫請求數 |
Avg. Disk Read Queue Length |
所選磁盤在性能監視器性能數據採樣間隔期間需要排隊的平均讀取請求數 |
Avg. Disk Write Queue Length |
所選磁盤在性能監視器性能數據採樣間隔期間需要排隊的平均寫入請求數 |
Split IO/Sec |
對磁盤I/O的讀寫請求拆分為多個請求的速率。分割I/O可能是由於請求的數據太大,無法容納單個I/O,或者物理磁盤在單個磁盤系統上已經被被分割。 |
l IPv4:指的就是Windows服務器的IPv4網絡請求,在選擇了IPv4後,可以看到該實例下所有和IPv4相關的計數器,如下圖
IPv4相關的計數器指標說明如下
計數器 |
說明 |
Datagrams/sec |
服務器每秒發送和接收到的請求報文數 |
Datagrams Received/sec |
服務器每秒接收到的請求報文數 |
Datagrams Received Header Errors/sec |
服務器每秒接收到的請求報文中header 錯誤的數量 |
Datagrams Received Address Errors/sec |
服務器每秒接收到的請求報文中請求地址錯誤的數量 |
Datagrams Forwarded/sec |
服務器每秒轉發的請求報文數 |
Datagrams Received Unknown Protocol/sec |
服務器每秒接收到無法處理的未知網絡協議的請求報文數 |
Datagrams send/sec |
服務器每秒發送的報文數 |
l Process:指的就是Windows服務器的進程監控,在選擇了Process後,可以看到該實例下所有和Process相關的計數器,如下圖
Process相關的計數器指標說明如下
計數器 |
說明 |
Thread Count |
表示當前正在運行的線程數 |
Virtual Bytes |
表示進程佔用的全部虛擬地址空間大小(單位為位元組),包括進程間的共享地址空間 |
Virtual BytesPeak |
表示進程佔用的全部虛擬地址空間的峰值大小,峰值表示從服務器開始運行一直到現在的時間中曾經使用的最大值。 |
Working Set |
表示進程工作集佔用內存的大小,包含了每個進程下的各個線程引用過的頁面空間以及可能被其他程序共享的內存空間。 |
WorkingSetPeak |
表示進程工作集佔用內存的峰值大小,峰值表示從服務器開始運行一直到現在的時間中曾經使用的最大值。 |
Private Bytes |
表示進程佔用的虛擬地址空間大小(單位為位元組),並且不包括進程間的共享地址空間,可以認為佔用的空間大小是進程私有使用的。 |
Handle Count |
表示進程使用的kernel object handle數量,當程序進入穩定運行狀態的時候, Handle Count數量也應該維持在一個穩定的區間。 如果發現Handle Count在整個程序周期內總體趨勢連續向上,應該考慮程序是否有Handle 泄漏。 |
Pool Paged Bytes |
表示分頁池的使用大小,單位為位元組 |
Pool Nonpaged Bytes |
表示非分頁池的使用大小,單位為位元組 |
1.2.2 Windows性能監視器下的性能分析
l 內存泄漏:Windows服務器下藉助性能監視器的計數器分析內存泄漏問題的一般步驟如下:
如果剩餘的有效物理內存一直在減少並且已提交的虛擬內存一直在增加,那麼此時程序代碼可能存在內存泄漏的風險,但是此時還需要觀察Process計數器中的Private Bytes和Working Set是不是也在持續增加,如果同樣
在持續增加那麼從服務器端監控看存在內存泄漏的可能性就非常大了,此時就需要去看部署在服務器上的程序是不是存在內存不能回收的情況,可以停止壓測,看下內存使用是否會釋放和回落。另外如果觀察到Handle
Count 的使用一直上漲,那麼可能是內核模式進程導致了內存泄露,那麼此時就還需要持續觀察內存分頁池中的Paged Bytes和 Pool Paged Bytes是不是也是在一直上漲。
性能測試分析與性能診斷調優核心思想目錄提綱(計劃2020年上架出版)
1. 性能測試和性能分析的基礎概念…
1.1. 性能測試的基礎概念…
1.1.1 性能測試的分類…
1.1.2 性能測試的場景…
1.2. 常見的性能測試指標…
1.2.1 響應時間…
1.2.2 TPS/QPS. 5
1.2.3 並發用戶…
1.2.4 PV/UV..
1.2.5 點擊率…
1.2.6 吞吐量…
1.2.7 資源開銷…
1.3. 性能測試的基本流程…
1.3.1 性能需求分析…
1.3.2 制定性能測試計劃…
1.3.3 編寫性能測試方案…
1.3.4 編寫性能測試案例…
2 服務器的性能監控和分析…
2.1 Linux服務器的性能指標監控和分析…
2.1.1 通過vmstat深挖服務器的性能問題…
2.1.2 如何通過mpstat 分析服務器的性能指標…
2.1.3 從lsof中能看到什麼…
2.1.4 如何通過free看懂內存的真實使用…
2.1.5 網絡流量如何監控…
2.1.6 nmon對Linux服務器的整體性能監控…
2.2 Windows服務器的性能指標監控和分析…
2.2.1 Windows性能監視器…
2.2.2 Windows性能監視器下的性能分析…
3 web中間件的性能分析…
3.1 nginx的性能分析和調優…
3.1.1 nginx的負載均衡策略…
3.2 apache的性能分析和調優…
4 應用中間件的性能分析…
4.1 tomcat的性能分析和調優…
4.2 jboss的性能分析和調優…
5、java應用服務的性能分析和調優
5.1 jvm的常見監控
5.2 jvm的性能分析與診斷
5.3 jvm的性能調優技巧
6、移動APP的性能分析和監控
6.1 安卓APP的常見性能監控
6.2 安卓APP的性能分析
7、性能測試案例分析
7.1 Loadrunner 對http服務的性能壓測分析
7.2 Loadrunner對 rpc服務的性能壓測分析
7.3 jmeter對http 服務的性能壓測分析
7.4 Jmeter對rpc服務的性能壓測分析
8、性能測試分析與大數據
8.1 流式計算的性能測試與分析
8.2 spark的性能測試與調優
8.3 storm的性能測試與調優
9、數據庫的性能分析
9.1 mysql數據庫的性能監控
9.2 mysql數據庫的性能定位
9.3 sql語句的性能調優
備註:作者的原創文章,轉載須註明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對於轉載了博主的原創文章,不標註出處的,作者將依法追究版權,請尊重作者的成果。
本文作者:張永清 文章選自 作者2020年初即將出版的《性能測試分析與性能診斷調優核心思想》一書。文章鏈接:https://www.cnblogs.com/laoqing/p/11629941.html