程序員不可不知的Linux性能工具

前言

在實際開發中，有時候會收到一些服務的監控報警，好比CPU飆高，內存飆高等，這個時候，咱們會登陸到服務器上進行排查。本篇博客將涵蓋這方面的知識：Linux性能工具。

一次線上問題排查模擬

背景：服務在平穩運行一段時間後，CPU忽然飆高。

經過top命令，能夠確認下，究竟是哪一個進程致使CPU飆高了（也許是誤報呢？）。

能夠看到圖中PID是2816的進程，CPU使用率很是高。

使用top -Hp 2816來對進程下的線程進行觀察。圖中能夠發現，2825這個線程CPU很是高。

這裏利用Python很是方便的把十進制的線程ID轉化成了16進制，爲何要這麼作呢？

由於在接下來的線程DUMP文件中使用的就是16進制的NID。

在實際中，咱們應該利用jstack pid多DUMP幾回，由於線程存在狀態轉換，所以屢次DUMP有利於抓取到線程更多的信息。

圖中，你能夠觀察到，一個線程獲得了鎖，在運行，遲遲沒有釋放，而另外一個線程一直在等待這個鎖。至此，就能夠到去查看代碼去分析爲何鎖遲遲不釋放的緣由了。

性能監測工具top詳解

上文的案例中，就使用到了top，而在實際中，top的信息量是很大的，這裏詳細分析下。

第一行：

涉及到2個時間，一個是系統時間，一個是機器運行的時間。【咱們應該重點關注的是機器運行的時間，Why? 有時候，重啓機器能帶來不少問題，你懂的！】

多少用戶登陸了系統？【經過who/w/history能夠查到更多信息】

3個load值是什麼含義？

分別表明的是1MIN,5MIN,15MIN機器的負載狀況，如何肯定負載的大小呢？須要和CPU的核數相結合來看，好比該機器是4核CPU，那麼若是load值超過了4，就意味着負載很大了！【在top下按下1能夠觀察出CPU的個數】

上述信息，其實也能夠經過uptime命令來獲取。

第二行：

主要是總共有多少個任務，重點應該關注的是殭屍狀態的任務數。

第三行：

主要是CPU的一些信息。

US/SY，說的就是用戶進程和系統進程使用CPU的佔比。

NI，即NICE，表示被調整過線程優先級的進程佔比，這個比例正常不該該很大。

ID，表示空閒；WA表示資源等待的時間，好比在瞬時大流量下，服務打了不少日誌的話，那麼這個值就會飆高，由於這會很消耗資源的。

HI，硬中斷，通常就是外設引發的，若是HI飆高的話，那麼意味着外設在硬件層面出現了問題。SI表示軟中斷。

ST，即steel，若是該主機是虛擬的話會有這個ST信息，也便是該虛擬機從宿主機獲取CPU的時間片的百分佔比。

第四和第五行：

這裏主要說2個概念性的東西：buffer 和 cache。

buffer主要是什麼呢？應該是待處理的數據，主要是處理2個系統之間速度不匹配的問題。而cache，通常應該是結果數據的緩存，好比從DB加載一些信息供查詢用。

SWAP分區，就是想利用硬盤的作一部分緩存，若是SWAP交換很是頻繁的話，就是說內存不夠用！

列表說明：

PID 進程ID、USER 用戶、PR 優先級、VIRT 虛擬內存、RES 駐留內存、SHR 共享內存

這裏須要指出的是，RES表示的是該進程實際佔用的內存，而並非申請的內存大小。也就是說當前進程所佔用的內存物理大小是 RES-SHR。