高併發&效能優化(二)------系統監控工具使用

流年的夏天發表於2020-08-25

上一篇主要從總體介紹了高併發&效能優化的相關思路和方法,本篇主要介紹系統監控工具。

   

CPU檢視工具】

------top命令(效能)

進入top命令後,按1即可看到每核CPU的執行指標與詳細指標:

我們們依次說明下紅框裡面的引數:

Load Average

一段時間內系統的平均負載,這個一段時間一般取1分鐘、5分鐘、15分鐘

us

使用者態所佔用的 CPU 百分比,即引用程式所耗費的 CPU

sy

核心態所佔用的 CPU 百分比,可配合 vmstat 命令,檢視上下文切換是否頻繁

ni

高優先順序應用所佔用的 CPU 百分比

id

空閒 CPU 百分比

wa

等待 I/O 裝置所佔用的 CPU 百分比,經常使用它來判斷 I/O 問題,過高輸入輸出裝置可能存在非常明顯的瓶頸

hi

硬中斷所佔用的 CPU 百分比

si

軟中斷所佔用的 CPU 百分比

st

虛擬機器等待宿主機 CPU 的時間佔比,在一些超售的雲伺服器上,經常發生

   

?硬中斷&軟中斷

硬中斷是由與系統相連的外設(網路卡,硬碟等)產生的,如當網路卡收到一個資料包。

軟中斷是正在執行的應用產生的,通常指的是一些對於I/O的操作,軟中斷可放到中斷之後執行。

   

一般情況下,我們會比較關心id(空閒 CPU 百分比),可以從整體上大致看出CPU真實利用率

   

------uptime(負載)

其實,在top裡面,已經可以看出平均負載的具體數值。

但是我們也有另外一種方式,分別顯示最近 1min5min15min 的數值:

   

一般負載達到1*CPU核數,我們可以認為系統負載達到了極限。

   

------vmstatCPU 繁忙程度)

檢視CPU的繁忙程度,可以通過vmstat檢視:

圖中紅框需要特別關注一下:

r

執行佇列

正在執行的佇列長度,一般體現任務總量

b

阻塞佇列

等待資源的任務佇列,如果系統負載有問題,可以專注一下b列(Uninterruptible Sleep),指的是等待I/O,可能讀寫盤操作比較多。

cs

每秒鐘上下文切換(Context Switch

如果上下文切換過於頻繁,就需要考慮是否是程式或者執行緒數開的過多

si/so

  

顯示了交換分割槽的一些使用情況,交換分割槽對效能的影響比較大,需要格外關注

   

如果我們想進一步檢視固定程式的上下文切換數量,可以通過以下命令檢視:

   

【記憶體檢視工具】

首先,我們從作業系統層面看一下記憶體的基本結構:

先簡單解釋下上面幾個名詞:

------邏輯記憶體

當我們寫了一個程式,然後去檢視它的底層彙編實現的時候,看到的記憶體地址,其實不是真正的實體記憶體地址,叫邏輯記憶體,邏輯記憶體是通過MMU對映到真實的實體記憶體地址上的。

   

------MMU

記憶體管理單元

虛擬地址和實體地址的對映關係儲存在頁表中,頁表是分級的64位系統一般都是3~5級。

在硬體上會有一個叫做頁表基地址暫存器,它儲存PGD頁表的首地址

MMU就是根據頁表基地址暫存器從PGD頁表一路查到PTE,最終找到實體地址(PTE頁表中儲存實體地址)

   

------TLB

translation lookaside buffer地址轉換後援緩衝器(快表)

TLB其實就是一塊快取記憶體,快取虛擬地址和其對映的實體地址,避免了每次都需要一級一級查詢頁表獲取實體地址。

   

------虛擬記憶體

邏輯地址可以對映到兩個記憶體段上:實體記憶體和虛擬記憶體

虛擬記憶體就是實體記憶體不夠用的時候把一些很少訪問的記憶體資料轉存到硬碟上,然後把這部分記憶體騰出來分配給其它應用。

   

------top

瞭解了基本概念之後,我們再來了解一下top在記憶體檢視中的應用:

紅框中的三個引數是記憶體相關的:

VIRT

虛擬記憶體,一般比較大

RES

代表了程式實際佔用的記憶體,平常在做監控時,主要監控的也是這個數值;
需要著重注意。

SHR

共享記憶體,一塊記憶體空間可以被多個應用檢視,裡面是一些可以複用的內容。

   

I/O

I/O 裝置可能是計算機裡速度最慢的元件了,它指的不僅僅是硬碟,還包括外圍的所有裝置。

I/O裝置和記憶體之間的速度差是非常大的,如何去緩解這個問題呢?

緩衝!緩衝區是現在解決速度差的唯一方法,不論是cpu->記憶體,還是記憶體->硬碟。

   

首先,我們回顧一下之前說過的"top"和"vmstat",裡面有一個引數,叫"wa",它是最能體現I/O的繁忙程度了。如果你的應用有大量寫入檔案的操作(比如日誌),I/O wait就可能會非常高。

   

------iostat

當然,檢視I/O也有一個很好的工具,就是iostat,可以通過sysstat安裝。

我們來大概瞭解一下主要引數:

%util

通常情況下,要先check這個數值;
這個數字超過 80%,就證明 I/O 的負荷已經非常嚴重了

Device

會列舉你所有的硬碟

avgqu-sz

平均請求佇列的長度

await

響應時間包含了佇列時間和服務時間,它有一個經驗值。
通常情況下應該是小於 5ms 的,如果這個值超過了 10ms,則證明等待的時間過長了。

svctm

表示操作 I/O 的平均服務時間
svctm
await 是強相關的,如果它們比較接近,則表示 I/O 幾乎沒有等待,裝置的效能很好;
但如果 await svctm 的值高出很多,則證明 I/O 的佇列等待時間太長,進而系統上執行的應用程式將變慢。

   

------零拷貝

說到I/O了,我們再衍生一下,講一個通常的優化手段。

   

比如,我們在java裡面進行一個簡單的檔案拷貝,在核心的支援下,零拷貝少了一個步驟,那就是核心快取向使用者空間的拷貝,這樣既節省了記憶體,也節省了 CPU 的排程時間,讓效率更高。

   

本篇先到這裡,下一篇,我們們介紹效能測試工具。

相關文章