性能測試分析與性能調優診斷–史上最全的伺服器性能分析監控調優篇
- 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 AndroidAPP的常見性能監控
6.2 AndroidAPP的性能分析
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